REDHAT-BUG-2537465: Medium severity Red Hat Ansible Automation Platform vulnerability
Reported internally by Red Hat engineering (Robin Bobbitt) via PSIRTSUPT-24014 / AAP-66516.
Root cause: the gateway API (POST /api/gateway/v1/servicekeys/) lets an AAP administrator mint a valid HS256 signing secret for the Controller service identity. Nothing constrains service-key creation to the installer provisioning path, so an admin-issued key is indistinguishable from a legitimately provisioned one. Possession of it lets the admin forge a service-auth JWT that impersonates the Controller service and then call POST /api/gateway/v1/workloadidentitytokens/ (X-ANSIBLE-SERVICE-AUTH: <forged JWT>) with arbitrary workload claims, obtaining a gateway-signed RS256 Workload Identity Token for any real or contrived Controller workload. That WIT is accepted by any downstream resource server (e.g. HashiCorp Vault) trusting the gateway OIDC public key, returning the AAP credentials configured for that workload.
Preconditions: attacker is an AAP administrator (PR:H); FEATUREOIDCWORKLOADIDENTITYENABLED=true; a downstream resource server trusts the gateway OIDC key and grants access by WIT claims.
Version applicability: the workload-identity endpoint and feature flag exist in AAP 2.7, where the full chain is exploitable. In AAP 2.5 and 2.6 the service-key-creation precondition exists but the WIT endpoint does not, so there is no privilege escalation there; however a forged service-auth token yields an attribution/audit-trail bypass (actions can be attributed to the service the key was minted for, or to another user). A service key created in 2.5/2.6 persists across upgrade and remains valid for WIT forgery once the flag is enabled in 2.7. AAP 2.4 has no gateway and is not affected.
Upstream fix (public): https://github.com/ansible/jewel/pull/235 (gateway service). Related collection update: https://github.com/ansible/ansible.platform/pull/254 (does not itself fix the vulnerability).
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Exposure requires FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED=true, an AAP administrator account, and a downstream resource server that trusts the gateway OIDC public key and authorizes access using Workload Identity Token claims. The workload-identity endpoint and feature flag exist in AAP 2.7.
What level of access does an attacker need?
The attacker must already be an AAP administrator. That administrator can create a service key, use its HS256 secret to forge Controller service authentication, and request workload identity tokens with arbitrary workload claims.
What downstream impact is possible?
A forged Workload Identity Token can be accepted by downstream resource servers such as HashiCorp Vault when they trust the gateway OIDC key. The downstream server can then return the AAP credentials configured for the claimed workload, including for a contrived Controller workload if its claims are accepted.
Can an administrator-issued malicious service key be distinguished from a legitimate provisioning key?
No. The reported root cause states that service-key creation is not restricted to the installer provisioning path, so an administrator-issued key is indistinguishable from a legitimately provisioned key.