Ansible community.general EUVD-2026-75115

Exploitation requires three concurrent conditions: (1) the Ansible controller must be configured to use the community.general.memcached cache plugin as the fact caching backend - set via 'fact_caching = community.general.memcached' in ansible.cfg, which is a non-default, explicitly operator-chosen configuration; (2) the memcached instance must be reachable by the attacker over the network, meaning it is not restricted to localhost (127.0.0.1) and is not protected by a host or network firewall on port 11211; and (3) the attacker must be able to write to memcached, which requires no credentials since memcached has no native authentication. Cache key prediction requires only knowledge of Ansible inventory host names, which may be discoverable from network enumeration, DNS, or prior access. Exploitation is fully blocked in deployments where memcached is bound to localhost or isolated behind a properly configured firewall. No user interaction from the Ansible operator is required beyond routine playbook execution - the poisoned cache is read automatically.

The CVSS 3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (8.1) is well-calibrated: AC:H reflects the realistic prerequisite that the attacker must reach a memcached instance, which in correctly architected deployments is bound to localhost or a restricted management VLAN rather than the public internet. However, the potential impact is asymmetrically severe - Ansible controllers typically hold SSH private keys, cloud provider credentials, and inventory over entire infrastructure fleets, meaning a single compromised controller can cascade into full environment compromise across all managed nodes. Even a mid-sized infrastructure team in mielec running Red Hat OpenStack or Ceph with a shared management-network memcached instance should treat this as high-priority remediation despite the AC:H qualifier. No EPSS data was present in the provided intelligence, and there is no CISA KEV entry, indicating no confirmed widespread exploitation at time of analysis. The attack pattern itself - injecting malicious pickle payloads into unauthenticated memcached - is well-established and requires no novel technique, lowering the effective bar once network access is achieved. Multi-tenant environments and shared automation platforms represent the highest-risk deployment patterns.

An attacker with access to the management or automation network identifies a memcached instance on port 11211 serving as the Ansible fact cache for a Red Hat OpenStack or Ceph deployment. Using the unauthenticated memcached protocol, the attacker writes a crafted pickle payload - encoding a reverse shell or credential exfiltration command - to a cache key derived from a known inventory hostname such as 'ansible_facts_controller01.example.com'. When an operator next runs a playbook against that host and the Ansible controller fetches cached facts, the pickle payload deserializes and executes arbitrary OS commands as the Ansible service account, which typically holds SSH keys and cloud credentials for the entire managed fleet. No public proof-of-concept code has been identified at time of analysis, but the generic technique of injecting malicious pickle payloads into unauthenticated memcached is well-documented in security research.