Your Automation Platform Is a Credential Honeypot: Ansible CVE-2026-11807

Think about what your automation platform actually stores. To configure a fleet, Ansible Automation Platform (AAP) holds the credentials to reach that fleet: SSH keys to your servers, vault passwords that unlock your secrets, OAuth tokens to your cloud accounts. The whole point of the platform is that it is the one system trusted to talk to everything else. That also makes it the single richest target you operate, and CVE-2026-11807 is what happens when the lock on that target slips.

The bug, disclosed in late June 2026 and rated CVSS 9.6 (critical), lets any authenticated user retrieve those credentials in plaintext. Not an admin. Anyone who can log in. Here is what it is, who it hits, and the broader point it makes about where your secrets really live.

What the bug is

The flaw lives in Event-Driven Ansible (EDA), the part of AAP that reacts to events and triggers rulebooks. EDA exposes a websocket API at /api/eda/ws/ansible-rulebook for worker processes to communicate. The problem: that endpoint did not verify the caller's permissions when processing worker messages. It assumed anyone connecting was a legitimate worker.

So an authenticated user can connect to that websocket and send a forged worker message carrying an arbitrary activation_id. The server, trusting the message, responds with the credentials associated with that activation, and it returns them in plaintext. According to Red Hat's advisory those credentials include OAuth tokens, vault passwords, and SSH keys: the exact material an attacker needs to move from "I have a low-privilege login" to "I own everything this platform manages."

The CVSS vector explains the 9.6: network attack vector, low complexity, no user interaction, and a low privilege requirement (you need to be authenticated, but nothing more). The only reason it is not a perfect 10 is that "authenticated" bar, which in many real deployments is a low one.

Who is affected

You are exposed if you run Ansible Automation Platform 2.5 or 2.6 with Event-Driven Ansible. The dangerous shape is the common one: an AAP instance that more than a handful of people can log into, where those people are not all equally trusted with every credential the platform holds. That describes most real installations, because the whole value of a shared automation platform is that teams share it.

The attacker does not need to be an outsider. The bug turns any authenticated account, a contractor, a junior engineer, a service account with a leaked token, into a path to the keys for your entire managed estate.

Fixing it

Red Hat has shipped patches. Update to the fixed releases:

• AAP 2.5: apply the update from advisory RHSA-2026:28497.
• AAP 2.6: apply the update from advisory RHSA-2026:28492.

Patching closes the hole, but with a credential-exposure bug you should assume the worst about the window before you patched. If your AAP was reachable by anyone you would not hand your root SSH keys to, treat the exposed credentials as potentially compromised:

1. Patch first, on both the controller and any EDA components.
2. Rotate the secrets the platform held: SSH keys, vault passwords, OAuth tokens, anything stored as an AAP credential. This is the step teams skip and the one that actually closes the incident, because the patch stops future leaks but does nothing about credentials that may already be out.
3. Review who can authenticate to AAP at all, and prune it. The blast radius of this bug was set by your login list.

The broader point: automation platforms are credential honeypots

Strip away the specifics and CVE-2026-11807 is a lesson about a category, not a product. Your automation control plane is, by design, the place where the most powerful credentials in your organization are concentrated. AAP holds the keys to the fleet. A CI/CD runner holds deploy keys, registry tokens, and cloud credentials. A low-code automation tool like n8n holds the API keys to every service it touches. These systems earn their value by being trusted with everything, which is exactly what makes a single authorization slip in one of them catastrophic.

That reframes how you should treat them:

• Least privilege on who can log in, not just on what they can do. This bug bypassed the "what they can do" layer entirely. The only control that held was "who is in the door," so make that list short and reviewed.
• Segment the credential store. If one platform holds the keys to production, staging, and every cloud account, one bug owns all three. Separate credentials by blast radius so a single platform compromise is not a total one.
• Plan for rotation before you need it. The teams who patch this fast and shrug are the ones who can rotate every AAP-held secret with a script. If rotating your automation credentials is a manual, scary, all-day job, that is a finding in itself.
• Watch the advisories for the tools that hold your keys, not just the apps you write. The software most worth patching urgently is the software trusted with the most, and that is usually your automation and CI platforms, not your web app.

Patch CVE-2026-11807 today if you run AAP. Then sit with the uncomfortable question it raises: if any logged-in user could have walked out with your SSH keys this week, what does that say about how much trust is concentrated in one place, and how quickly you could rotate your way out of it?