Skip to main content
Vulnerability Database/CVE-2026-75884

CVE-2026-75884: AWX Privilege Escalation Vulnerability

CVE-2026-75884 is a privilege escalation flaw in AWX that allows platform administrators to exploit incomplete blocklist restrictions and escalate to OpenShift namespace-level access. This post covers technical details, affected versions, impact, and mitigation steps.

Published:

CVE-2026-75884 Overview

A flaw in Ansible AWX allows an Ansible Automation Platform (AAP) administrator to escalate privileges within an OpenShift namespace. The container group pod_spec_override field enforces an incomplete blocklist that only restricts automountServiceAccountToken. Attackers can inject initContainers, override serviceAccountName, and mount projected service account token volumes. This grants namespace-level access to OpenShift and enables exfiltration of namespace secrets. The vulnerability is classified under [CWE-184: Incomplete List of Disallowed Inputs].

Critical Impact

An authenticated AAP platform administrator can break out of the intended AWX execution boundary, obtain OpenShift namespace privileges, and read namespace-scoped secrets.

Affected Products

  • Red Hat Ansible Automation Platform (AAP) — AWX component
  • Deployments referenced in Red Hat advisories RHSA-2026:71113, RHSA-2026:71114, and RHSA-2026:71115
  • Additional impacted builds tracked in RHSA-2026:71177 and RHSA-2026:71179

Discovery Timeline

  • 2026-09-23 - CVE-2026-75884 published to NVD
  • 2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-75884

Vulnerability Analysis

AWX container groups let administrators customize the Kubernetes pod specification used to run automation jobs. The pod_spec_override field accepts a partial PodSpec that AWX merges into the runtime pod definition. To prevent trivial token theft, AWX applies a blocklist that strips the automountServiceAccountToken field. The blocklist does not cover other fields that reach the same outcome. An authenticated AAP administrator can supply initContainers, override serviceAccountName, or attach a projected volume containing a serviceAccountToken source. Any of these paths yields a valid token bound to a namespace service account. With that token, the attacker interacts with the OpenShift API at namespace scope and reads Secret objects the service account can access.

Root Cause

The root cause is an incomplete disallow list. Input validation focuses on a single field name rather than the class of behaviors that mount or bind service account credentials. Any PodSpec construct that produces a token, whether through an initContainer, a service account swap, or a projected volume, bypasses the check.

Attack Vector

Exploitation requires authenticated access to AAP with permission to manage container groups. The attacker submits a crafted pod_spec_override payload through the AWX API or UI. When AWX launches the next job in that container group, OpenShift schedules a pod that carries the injected service account token. The pod then queries the OpenShift API for namespace secrets and exfiltrates them.

No verified proof-of-concept code has been published. Refer to the Red Hat CVE Analysis for CVE-2026-75884 and Red Hat Bug #2517893 for vendor technical detail.

Detection Methods for CVE-2026-75884

Indicators of Compromise

  • AWX container group configurations containing initContainers, serviceAccountName, or projected serviceAccountToken volumes within pod_spec_override.
  • Job pods running under a service account other than the default AWX execution service account.
  • OpenShift audit log entries showing get or list calls against secrets from a pod created by AWX.

Detection Strategies

  • Review AWX API traffic and database records for pod_spec_override payloads that reference service account fields or volume projections.
  • Correlate AAP administrator activity with OpenShift ServiceAccount and Secret access events in the same namespace.
  • Alert on pods created in AWX execution namespaces that mount tokens from non-default service accounts.

Monitoring Recommendations

  • Enable OpenShift audit logging at the Metadata level or higher for the namespaces hosting AWX execution pods.
  • Ingest AAP application logs and OpenShift audit logs into a centralized analytics platform for cross-source correlation.
  • Track changes to container group definitions and flag any modification that introduces PodSpec fields outside a known allowlist.

How to Mitigate CVE-2026-75884

Immediate Actions Required

  • Apply the fixes referenced in RHSA-2026:71113, RHSA-2026:71114, RHSA-2026:71115, RHSA-2026:71177, and RHSA-2026:71179.
  • Audit existing container groups and remove any pod_spec_override values that inject initContainers, override serviceAccountName, or mount projected token volumes.
  • Restrict AAP platform administrator membership and require multi-factor authentication for those accounts.

Patch Information

Red Hat has released updated AAP packages through the advisories listed above. Administrators should follow the Red Hat errata for their specific AAP and AWX versions and validate that the patched build enforces the expanded PodSpec restriction.

Workarounds

  • Disable use of pod_spec_override in production container groups until patches are applied.
  • Run AWX execution pods in a dedicated OpenShift namespace that holds no sensitive secrets.
  • Apply an OpenShift admission policy (for example, a Kyverno or Gatekeeper rule) that rejects pods with unexpected serviceAccountName values or serviceAccountToken projections in the AWX namespace.
bash
# Example Gatekeeper-style guardrail concept for the AWX execution namespace
# Reject pods whose serviceAccountName is not the approved AWX runner
# and pods that project a serviceAccountToken volume.
# Replace <awx-runner-sa> and <awx-namespace> with your values.
kubectl label namespace <awx-namespace> \
  pod-security.kubernetes.io/enforce=restricted

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.