Two 9.0 libXfont2 heap overflows and a pickle bomb hiding in your Ansible cache

The memcached cache plugin in community.general for Ansible silently uses Python pickle to serialize data, even though the docs say JSON. Since memcached has no built-in authentication and cache keys are predictable, an attacker who can reach the memcached instance can inject a malicious pickle payload. When Ansible reads the poisoned cache, it deserializes the payload and the attacker gets code execution on your Ansible controller.

Affected estate

Ansible users running the community.general collection with the memcached fact cache plugin, especially when memcached is network-accessible

How to check

Check your ansible.cfg or environment for `fact_caching = community.general.memcached`. Run `ansible-galaxy collection list community.general` to confirm the installed version.

Included because

unauthenticated; RCE on Ansible controller; no user interaction; CVSS 8.1; high blast radius

Action

Update community.general via `ansible-galaxy collection install community.general --upgrade` and lock down memcached network access.

Why it matters

An attacker with network access to memcached can get arbitrary code execution on your Ansible controller, which typically has privileged access to your entire managed fleet.

A bug in libXfont2's font server client lets a malicious or compromised font server send mismatched reply sizes, causing out-of-bounds heap reads and writes on the X server. This is a CVSS 9.0 because the attacker controls both the bounds violation and the data written. Exploitation requires a rogue or compromised font server, so your exposure depends on whether your X server is configured to use remote font services.

Affected estate

Anyone running X.Org or XWayland systems with libXfont2 installed, especially if remote font server connections (xfs) are configured

How to check

Run `rpm -q libXfont2` or `dpkg -l libxfont2` to check the installed version. Inspect xorg.conf for FontPath entries referencing tcp or remote font servers.

Included because

heap read/write with attacker-controlled content; CVSS 9.0; requires compromised font server but no authentication

Action

Update libXfont2 via your package manager and remove any remote font server FontPath entries from your X configuration.

Why it matters

A rogue font server can achieve heap corruption on your X server process, potentially leading to code execution with the privileges of the X server.

Another libXfont2 bug in the same font server client code. A malicious font server can send overlapping glyph bitmap offsets that each pass individual bounds checks, but cumulatively overflow the destination heap buffer with attacker-controlled content. This is a straightforward heap buffer overflow, CVSS 9.0. Like CVE-2026-59679, exploitation requires a rogue or compromised font server.

Affected estate

Anyone running X.Org or XWayland systems with libXfont2 installed, especially if remote font server connections (xfs) are configured

How to check

Run `rpm -q libXfont2` or `dpkg -l libxfont2` to check the installed version. Look for remote FontPath entries in xorg.conf.

Included because

heap overflow with attacker-controlled content; CVSS 9.0; requires compromised font server but no authentication

Action

Update libXfont2 via your package manager. This fix is likely bundled with CVE-2026-59679 in the same package update.

Why it matters

Heap buffer overflow with attacker-controlled content can lead to code execution under the X server's privileges.

A KVM bug on s390 lets a nested guest (a VM running inside a VM) retain access to crypto devices that should have been revoked. When shadowing crypto access control bits from an older format APCB, bits 64 through 255 aren't zeroed out, so stale permissions stick around from previous configurations. This means a nested guest could access crypto hardware it shouldn't have access to anymore.

Affected estate

Anyone running KVM with nested virtualization on IBM s390 systems that use crypto pass-through (APCB/vfio-ap)

How to check

Run `uname -r` to check your kernel version. Confirm you're running s390x with nested KVM guests that have crypto device assignments.

Included because

privilege escalation in nested VM; CVSS 8.8; crypto device exposure; s390-specific but high impact in that environment

Action

Update to the patched kernel version for your distribution and reboot the host.

Why it matters

A nested guest retaining stale crypto device access could read or manipulate sensitive cryptographic operations it should no longer be authorized to touch.