Act nowDisclosed

Advisory · CVE-2026-75884

Critical AWX pod spec override flaw escalates to OpenShift namespace access

An incomplete blocklist on the AWX container group pod_spec_override field lets an AAP platform administrator inject initContainers and service account overrides, escalating to OpenShift namespace-level access and secret exfiltration.

Advisory published September 23, 2026Independent summary
Vendor
Red Hat
Product
Red Hat Ansible Automation Platform 2
Identifier / CWE
CVE-2026-75884
CWE-184
Action timing
Immediate
ELI5

Explain it like I’m five

AWX lets bosses customize the containers that run automation jobs, but its list of forbidden customizations was too short. A boss can sneak in extra containers and borrowed ID badges, then roam the whole neighborhood reading everyone else's secrets.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Custom pod spec

    An AAP platform administrator submits a container group with a crafted pod_spec_override.

  2. 02Blocklist gap

    The override filter blocks only automountServiceAccountToken, so initContainers, serviceAccountName overrides, and projected service account token volumes pass through.

  3. 03Namespace escalation

    The injected spec gives the attacker's pods OpenShift namespace-level access.

  4. 04Secret exfiltration

    Namespace secrets, including those belonging to other tenants of the namespace, can be read and exfiltrated.

What happened

A flaw in AWX’s container group handling allows privilege escalation to OpenShift namespace-level access. The pod_spec_override field is filtered with an incomplete blocklist that restricts only automountServiceAccountToken, permitting injection of initContainers, serviceAccountName overrides, and projected service account token volumes. A user with AAP platform administrator rights can exploit this to break out of their intended scope and exfiltrate namespace secrets.

Red Hat reports Red Hat Ansible Automation Platform 2 as affected and rates the issue critical at CVSS 9.1. Red Hat has not stated a fixed version in the data available, so remediation should follow the vendor bulletin.

What to do

  1. Review who holds AAP platform administrator rights and trim the list to operational necessity.
  2. Follow the Red Hat security bulletin for patches or mitigations and apply them.
  3. Audit container group definitions for pod_spec_override entries containing initContainers, serviceAccountName, or projected volumes.
  4. Review OpenShift audit logs for unusual pod creation or secret access from automation namespaces.
  5. Rotate namespace secrets that automation service accounts could have reached.

Management note

The attacker here is already an administrator, which makes this easy to dismiss, but the blast radius crosses tenant boundaries: one AAP admin can reach secrets for the whole namespace. Treat admin-role hygiene as the immediate control while the vendor fix lands.