CVE-2026-12382: AAP Gateway Authentication Bypass Flaw

CVE-2026-12382 Overview

CVE-2026-12382 is an authentication bypass vulnerability in the Ansible Automation Platform (AAP) Gateway Envoy proxy configuration. The non-mTLS route to Event-Driven Ansible (EDA) event streams fails to strip the Subject HTTP header from incoming client requests. Although the source code declares requestHeadersToRemove for this header, the directive is not applied on that route. An unauthenticated remote attacker can inject a spoofed Subject header matching a legitimate client certificate Distinguished Name (DN). This bypasses mutual TLS (mTLS) authentication and permits arbitrary event injection into protected EDA event streams. The weakness is categorized as [CWE-290] Authentication Bypass by Spoofing.

Critical Impact
Unauthenticated remote attackers can forge trusted client identities and inject arbitrary events into protected EDA event streams, subverting automation integrity.

Affected Products

Red Hat Ansible Automation Platform (AAP) Gateway
AAP Envoy proxy component routing to EDA event streams
Event-Driven Ansible (EDA) event stream consumers behind the affected Gateway

Discovery Timeline

2026-07-15 - CVE-2026-12382 published to the National Vulnerability Database (NVD)
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-12382

Vulnerability Analysis

The AAP Gateway uses Envoy as a front-end proxy to route requests to backend services, including EDA event streams. Envoy supports two routes to these streams: an mTLS-authenticated route and a non-mTLS route. On the mTLS route, Envoy derives the Subject header from the client certificate DN and forwards it downstream so that the backend can identify the caller. On the non-mTLS route, no client certificate is presented, so any inbound Subject header must be scrubbed before the request reaches the backend. The Envoy configuration declares this scrubbing via requestHeadersToRemove, but the directive is not effective on the non-mTLS route. Requests carrying an attacker-supplied Subject header pass through unchanged, and the backend treats the spoofed DN as authoritative caller identity.

Root Cause

The root cause is an incorrect trust boundary in the Envoy route configuration. The backend accepts the Subject header as an authenticated identity claim without verifying that it originated from Envoy's mTLS handshake. Because the non-mTLS route does not strip the client-supplied header, the identity claim can be forged. This is a classic instance of authentication bypass by spoofing [CWE-290], where an identity assertion is trusted without cryptographic binding to the underlying transport.

Attack Vector

The attack is remote and unauthenticated. An attacker sends an HTTP request to the non-mTLS route exposed by the AAP Gateway and adds a Subject header containing the DN of a legitimate client certificate, for example CN=eda-producer,OU=automation,O=example. The Gateway forwards the request to the EDA event stream backend, which reads the Subject header and treats the caller as an authorized producer. The attacker can then inject arbitrary events into protected streams, which may in turn trigger downstream automation rulebooks and playbooks.

No verified public exploit code is available. Refer to the Red Hat CVE-2026-12382 Details and Red Hat Bug Report #2489126 for vendor technical analysis.

Detection Methods for CVE-2026-12382

Indicators of Compromise

Inbound HTTP requests to AAP Gateway non-mTLS routes containing a client-supplied Subject header.
EDA event stream entries attributed to a certificate DN that did not complete an mTLS handshake at the Envoy edge.
Automation rulebook executions triggered by events with source identities that do not correlate to any active mTLS session in Envoy access logs.

Detection Strategies

Compare Envoy access logs against backend EDA logs to identify events where a Subject header is present but no client certificate was validated on the corresponding connection.
Alert on any request reaching the non-mTLS listener that includes a Subject header, since legitimate clients on that route should never send one.
Baseline the set of certificate DNs that legitimately publish to each EDA stream and flag deviations.

Monitoring Recommendations

Enable Envoy access logging with request header capture on both mTLS and non-mTLS listeners for the Gateway.
Forward Gateway and EDA logs to a centralized SIEM or data lake and correlate on request ID, source IP, and asserted Subject.
Monitor EDA event stream ingestion rates and producer identity distributions for anomalies.

How to Mitigate CVE-2026-12382

Immediate Actions Required

Apply the Red Hat errata update referenced in RHSA-2026:13508 to affected AAP Gateway deployments.
Restrict network exposure of the non-mTLS Gateway route to trusted management networks until the patch is deployed.
Rotate or review any EDA-driven automation that may have been triggered by unverified events since the vulnerability was introduced.

Patch Information

Red Hat has released a fix through RHSA-2026:13508. The update corrects the Envoy route configuration so that the Subject header is stripped from all inbound requests on the non-mTLS route before forwarding to EDA event streams. Administrators should follow Red Hat's standard update procedure for AAP Gateway components and verify the patched configuration after deployment.

Workarounds

Add an explicit Envoy request_headers_to_remove: ["Subject"] entry on the affected non-mTLS route and reload the proxy configuration.
Place a reverse proxy or web application firewall (WAF) rule in front of the Gateway to drop any inbound Subject header from external clients.
Disable the non-mTLS route entirely if EDA producers can be reconfigured to use only the mTLS-authenticated endpoint.

bash

# Example Envoy route snippet enforcing Subject header removal
# on the non-mTLS listener routing to EDA event streams
route_config:
  virtual_hosts:
    - name: eda_non_mtls
      domains: ["*"]
      request_headers_to_remove:
        - "Subject"
      routes:
        - match: { prefix: "/eda/events" }
          route: { cluster: eda_event_stream }