CVE-2026-12564: Critical Kubernetes Token Exfiltration in Ansible Automation Platform’s Vault Plugin

A critical flaw in Red Hat Ansible Automation Platform let any user who can create a credential steal the Kubernetes service account token belonging to the AAP Controller pod itself, then use that token to read secrets and control pods across the platform’s own namespaces. It carries a CVSS score of 9.6 and is fixed in the September 14, 2026 patch release, 2.7-8.

Quick guide

1. Check your Ansible Automation Platform version. If you run Automation Controller 2.7 on a version older than 2.7-8, you are affected.
2. Apply the 2.7-8 patch release as soon as possible, which changes the Vault credential plugin to use short lived, audience scoped tokens through the Kubernetes TokenRequest API instead of the long lived service account token.
3. Until patched, review who holds credential creation privileges in your Controller, since the flaw requires only that permission, not full admin access, to exploit.
4. Audit any HashiCorp Vault Secret Lookup credentials configured with kubernetes_role authentication, since testing that specific credential type is what triggers the exposure.
5. After patching, review Kubernetes audit logs for the Controller’s namespace for any unexpected API calls from before the patch was applied.
6. If you use the GitPython dependent components in Automation Controller or Automation Hub, confirm they were also updated as part of 2.7-8, which additionally fixed 11 CVEs in GitPython including remote code execution and command injection flaws.

What the vulnerability actually does

The flaw lives in the kubernetes_auth() function inside the AAP Controller’s HashiCorp Vault credential plugin, specifically in awx_plugins/credentials/hashivault.py. When a HashiCorp Vault Secret Lookup credential configured with kubernetes_role authentication is tested, that function reads the Controller pod’s own Kubernetes service account token and sends it to whatever Vault URL the credential specifies. An attacker only needs the ability to create a credential of this type, and can point it at a URL they control, to have the platform hand over its own service account token voluntarily.

According to the vulnerability writeups, an authenticated attacker with credential creation privileges who exfiltrates this token gains Kubernetes API access to control plane namespaces, with full CRUD access to pods and the ability to read secrets, including database credentials and the Django SECRET_KEY the platform itself relies on.

Why credential creation is a lower bar than it sounds

Credential creation is a routine permission handed to many automation users and teams in AAP, since building and testing integrations is a normal part of the job. This vulnerability turns that ordinary permission into a path to the platform’s own control plane, which is a significant escalation from what that permission is meant to allow. It is a useful reminder that “can create a credential” is not a low value permission in a platform whose whole job is holding and using credentials.

The fix

Red Hat’s 2.7-8 patch release, dated September 14, 2026, resolves the issue by having the Vault credential plugin request audience scoped, short lived tokens through the Kubernetes TokenRequest API instead of exposing the pod’s long lived service account token. The same release also updated GitPython to 3.1.59 in Automation Controller and 3.1.57 or later in Automation Hub, addressing 11 separate CVEs in that dependency, including critical remote code execution and arbitrary command injection issues, plus fixes across sqlparse, Django, AIOHTTP, lxml and other third party dependencies.

What actually goes wrong

Automation platforms sit in an unusually privileged position, they exist specifically to hold and use credentials across the rest of your infrastructure. A vulnerability that lets a routine, low level permission reach the platform’s own control plane token means an attacker does not need to compromise an admin account first, an ordinary automation user account is enough. Treat automation platforms with the same access review discipline as a credential vault or a CI/CD system, because functionally that is exactly what they are.

FAQ

Does this affect Ansible Automation Platform versions other than 2.7?

The reporting on this CVE is specific to the 2.7 release line. If you run an older AAP version, check Red Hat’s advisory and errata for that specific version’s patch status rather than assuming it is unaffected.

Do I need to rotate any secrets after patching?

If you cannot rule out that this was exploited before you patched, treat the Controller pod’s Kubernetes service account credentials and anything reachable through them as potentially exposed and rotate accordingly.

Is this exploitable without any special network access?

The attacker needs the credential creation permission inside AAP and needs to be able to receive the exfiltrated token at a URL they control, which is achievable from any network position that can reach the internet or an attacker controlled endpoint.

Sources

Red Hat Ansible Automation Platform 2.7 patch release documentation for the September 14, 2026 release, and public vulnerability writeups of CVE-2026-12564.