Reported internally by Red Hat engineering (Robin Bobbitt) via PSIRTSUPT-24014 / AAP-66516.

Root cause: the gateway API (POST /api/gateway/v1/service_keys/) 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/workload_identity_tokens/ (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); FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED=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).