3Corns

Red Hat, Bypass Authentication via Spoofing

CVE-2026-12382

Affected packages issued by Red Hat Errata:

Red Hat Ansible Automation Platform 2

- ansible-automation-platform-27/gateway-rhel9

- automation-gateway

Examples in: Java

String sourceIP = request.getRemoteAddr();
            if (sourceIP != null && sourceIP.equals(APPROVED_IP)) {
                authenticated = true;
            }

The authentication mechanism implemented relies on an IP address for source validation. If an attacker is able to spoof the IP, they may be able to bypass the authentication mechanism.

3Corns - Articles, Security, Splitter

Examples in: C

sd = socket(AF_INET, SOCK_DGRAM, 0);
                serv.sin_family = AF_INET;
                serv.sin_addr.s_addr = htonl(INADDR_ANY);
                servr.sin_port = htons(1008);
                bind(sd, (struct sockaddr *) & serv, sizeof(serv));
                
                while (1) {
                    memset(msg, 0x0, MAX_MSG);
                    clilen = sizeof(cli);
                    if (inet_ntoa(cli.sin_addr)==getTrustedAddress()) {
                        n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen);
                    }
                }

The following code samples use a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.

(bad code)

Examples in: C

struct hostent *hp;
                struct in_addr myaddr;
                char* tHost = "trustme.example.com";
                myaddr.s_addr = inet_addr(ip_addr_string);

                hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET);
                if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) {
                    trusted = true;
                } else {
                    trusted = false;
                    }

Examples in: C#

IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
                    IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
                    if (hostInfo.HostName.EndsWith("trustme.com")) {
                    trusted = true;
                    }

While IP addresses tend to be more trustworthy than DNS names, they too can be spoofed. An attacker can easily forge the source IP address in outgoing packets, but doing so means any response traffic will be sent back to that forged address rather than to the attacker. To actually see those responses, the attacker must sniff traffic between the victim and the forged IP — which typically requires positioning themselves on the same subnet as the victim. Source routing could theoretically bypass this constraint, but it's disabled across most of the modern Internet, making it an impractical option in most cases. Ultimately, IP address verification can serve as one useful layer in an authentication scheme, but it should never be relied upon as the sole factor for authenticating a user or host.

3Corns - Articles, Security, Splitter

CVSS v3 Vector

Red Hat:

_{CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N}

CVE List :

_{CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N}

A vulnerability was identified in the Envoy proxy configuration of the AAP Gateway. Although the source code specifies the Subject header in requestHeadersToRemove, the non-mTLS route to EDA event streams fails to strip this header from incoming client requests. As a result, an unauthenticated remote attacker can craft a request with a forged Subject header that matches a legitimate client certificate's distinguished name (DN), thereby bypassing mTLS authentication and injecting arbitrary events into otherwise protected EDA event streams."

3Corns - Articles, Security, Splitter

Mitigations

The following practices can help reduce exposure and mitigate this flaw:

Restrict network access to the non-mTLS EDA event stream route (/eda-event-streams/) at the firewall or load balancer level, permitting only trusted internal sources.

Where mTLS-protected event streams are in use, ensure that only the /mtls/eda-event-streams/ route remains reachable from untrusted networks.

Monitor EDA event stream activity for unusual increases in the events_received counter, which may signal unauthorized event injection.

Review Envoy proxy logs for requests to the non-mTLS event stream route originating from unexpected source IPs.

Affected Deployments

This flaw impacts AAP deployments that rely on mTLS-protected EDA external event streams. It stems from the Gateway component, introduced in AAP 2.5, which contains the Envoy proxy routing configuration.
AAP 2.4, by contrast, uses a different architecture without a Gateway or Envoy component, and is therefore not affected by this specific issue — although a separately tracked, related flaw involving trust of the Subject header on the EDA side may still apply to AAP 2.4 deployments using mTLS with a different proxy setup.