Ansible Automation Platform CVE-2026-75884

Requires an AAP platform administrator account (CVSS PR:H) and a deployment that uses container groups backed by OpenShift/Kubernetes, since the vulnerable pod_spec_override field only applies to container-group execution. The specific weakness is that the pod_spec_override blocklist restricts only automountServiceAccountToken, leaving initContainers, serviceAccountName overrides, and projected service-account token volumes injectable. Limiting factors: exploitation is gated on the highest AAP privilege tier (platform admin), so it is an insider/compromised-admin scenario rather than an unauthenticated one; environments not using container groups on OpenShift are not exposed; no user interaction is needed (UI:N) and the vector is network-reachable (AV:N).

This is a genuinely high-impact but access-gated flaw, not an inflated CVSS number. The vendor CVSS 3.1 vector (9.1, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) is internally consistent with the description: exploitation demands PR:H (an AAP platform administrator, the highest privilege tier), but the scope change (S:C) and full C:H/I:H/A:H reflect that the impact crosses a trust boundary - from the automation-controller into the underlying OpenShift/Kubernetes cluster namespace, where namespace secrets can be exfiltrated. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The real-world risk is therefore driven by insider/compromised-admin threat models rather than opportunistic mass exploitation: a malicious or compromised platform admin can convert their AAP authority into cluster-namespace compromise. The high CVSS is legitimate for what it measures (impact after the privilege prerequisite is met), but the PR:H gate substantially narrows the exploit population, so prioritization should weigh how tightly platform-admin access is controlled in a given environment. Only two references (Red Hat access page and Bugzilla) are provided and no fixed version is listed, so patch availability is not confirmed from the input.

An AAP platform administrator (or an attacker who has compromised such an account) submits a container group with a crafted pod_spec_override that adds initContainers, overrides serviceAccountName, and mounts a projected service-account token volume - bypassing the blocklist that only strips automountServiceAccountToken. When the execution pod runs, it assumes elevated namespace privileges and reads OpenShift namespace secrets. No public exploit code is identified in the provided data; the flaw is network-reachable but requires high privileges (PR:H) and no user interaction.