CVE-2026-12564: Automation-controller: automation-controller: kubernetes service account token exfiltration via hashicorp vault credential ssrf
A flaw was found in the AAP Controller's HashiCorp Vault credential integration. When a HashiCorp Vault Secret Lookup credential is configured with kubernetesrole authentication, the credential test endpoint (POST /api/controller/v2/credentials/{id}/test/) triggers the kubernetesauth() function which reads the controller pod's Kubernetes service account token from /var/run/secrets/kubernetes.io/serviceaccount/token and POSTs it as {"jwt": "<satoken>", "role": "<role>"} to the user-supplied vault URL. There is no validation or restriction on the vault URL target. An authenticated attacker with credential-creation privileges can set the vault URL to an attacker-controlled server and capture the SA token. The exfiltrated token (system:serviceaccount:ansible-automation-platform:automation-controller) has broad Kubernetes RBAC permissions including: full pod CRUD (get,list,watch,create,update,patch,delete) in both ansible-automation-job and ansible-automation-platform namespaces, and individual secret access (get,create,delete) in both namespaces. This allows the attacker to read database credentials, the Django SECRETKEY, and access all 31+ pods in the AAP platform namespace. In AAP Cloud (managed service) environments, this constitutes a tenant-to-infrastructure escape as the control plane is managed by Red Hat. The token has an approximately 1-year lifetime.
Upstream: https://github.com/ansible/awx (awxplugins/credentials/hashivault.py) Affected function: kubernetesauth() at hashivault.py:462-468 Reporter: Chris Meyers (internal — cmeyers) Tested against: platform.cus-0616.aws.ansiblecloud.com (AAP Cloud, ROSA)
Other sources
A flaw was found in the AAP Controller's HashiCorp Vault credential plugin. The kubernetesauth() function in awxplugins/credentials/hashivault.py reads the controller pod's Kubernetes service account token and sends it to an attacker-controlled URL when a HashiCorp Vault Secret Lookup credential with kubernetesrole authentication is tested. An authenticated attacker with credential-creation privileges can exfiltrate the service account token, gaining Kubernetes API access to the control plane namespaces with full pod CRUD and secret read permissions, including database credentials and the Django SECRETKEY.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Who can realistically exploit this issue?
AAP Controller deployments are exposed if an authenticated user has permission to create HashiCorp Vault Secret Lookup credentials and can cause a credential test using kubernetes_role authentication. The attacker must be able to supply an attacker-controlled Vault URL.
What access could an attacker gain after obtaining the token?
Successful exploitation sends the controller pod's Kubernetes service account token to the attacker-controlled URL. That token can provide Kubernetes API access to control-plane namespaces, including full pod CRUD access and permission to read secrets such as database credentials and the Django SECRET_KEY.
How can administrators identify potentially affected activity?
The issue is triggered when a HashiCorp Vault Secret Lookup credential configured with kubernetes_role authentication is tested. Review credential creation permissions and existing or newly tested Vault credentials for attacker-controlled URLs.