AAP Controller: testing a Vault credential sends the controller pod's service account token to an attacker URL

Impact

kubernetes_auth() in awx_plugins/credentials/hashivault.py reads the controller pod's Kubernetes service account token and posts it to whatever URL the credential names, so simply testing a HashiCorp Vault Secret Lookup credential configured for kubernetes_role authentication exfiltrates that token. Red Hat's description of what the token grants is the interesting part: Kubernetes API access to the control plane namespaces with full pod CRUD and secret read, which covers the platform database credentials and the Django SECRET_KEY. Pod-create in those namespaces on a cluster that also schedules accelerator work is a path to running attacker code with the automation platform's own privileges, and the leaked SECRET_KEY undermines session and token integrity across the controller. The attacker only needs the ability to add a credential, which is routinely delegated far more widely than cluster admin.

Who can reach it

An authenticated AAP user holding credential-creation privileges in any organisation on the controller. No cluster access and no admin role needed - the controller performs the outbound request on the attacker's behalf.

What to do

The record carries no fixed version, only Red Hat's tracking page and Bugzilla 2490556 - check those for the errata rather than assuming a package level. Meanwhile, cut the blast radius by restricting who may create or edit credentials, and consider egress policy on the controller pods so they can only reach your own Vault endpoints. When the fixed awx_plugins build ships, updating the controller image means rolling the controller pods, which interrupts running jobs but touches no nodes. Treat any service account token that could already have been tested out as burned and rotate it along with the platform database credentials and SECRET_KEY.

References