TL;DR: CVE-2026-15554 lets an unauthenticated attacker bypass CLIENT-CERT authentication on any Undertow-based server fronted by an AJP reverse proxy. The vulnerability echoes the Ghostcat class of AJP flaws (CVE-2019-10072, CVE-2020-1938) but targets a different attribute. An attacker crafts a malformed AJP request with forged ssl_cert and is_ssl attributes. Undertow trusts those attributes and grants access without a valid client certificate.

The ecosystem: Undertow, AJP, and why this keeps happening

Undertow is the web server embedded in WildFly and JBoss EAP. Red Hat ships it as the default servlet container. When you place Apache httpd or another reverse proxy in front of JBoss EAP, the proxy typically talks to the backend using the AJP (Apache JServ Protocol) on port 8009.

AJP carries request attributes from the proxy to the backend. The backend trusts these attributes implicitly. That trust model is the root of a recurring vulnerability pattern. The proxy sets attributes like ssl_cert (the client's TLS certificate), is_ssl (whether the connection used TLS), and remote_user. The backend consumes them to make authentication and authorization decisions.

Ghostcat (CVE-2020-1938) exploited this trust to read arbitrary files via the javax.servlet.include attributes. CVE-2026-15554 exploits the same trust model for a different goal: bypassing mutual TLS authentication entirely.

What happened

Undertow's AJP listener processes incoming AJP requests and maps them to servlet requests. Among the attributes it reads are ssl_cert and is_ssl. When a request arrives with is_ssl set to true and ssl_cert populated, Undertow populates the javax.servlet.request.X509Certificate request attribute with the certificate data. The CLIENT-CERT authentication valve then checks this attribute to authenticate the client.

The flaw: Undertow did not verify that the AJP request actually originated from a trusted proxy. Nor did it validate that the ssl_cert value was a legitimate certificate forwarded by the proxy's TLS layer. Any client who can reach the AJP port can set these attributes directly in their own AJP request.

An attacker constructs a raw AJP request to port 8009. They set is_ssl=true and ssl_cert to any certificate string (or a fabricated one). Undertow populates the X509Certificate attribute. The CLIENT-CERT valve sees a certificate and proceeds with authentication. Depending on the application's CLIENT-CERT configuration, the attacker may be granted access as an authenticated user without ever presenting a valid TLS certificate to the proxy.

The attack requires network access to the AJP port. In misconfigured deployments where port 8009 is exposed to untrusted networks (internal or external), the barrier to exploitation is low.

Who is affected

Jboss EAP is Red Hat's enterprise Java platform, used across banking, telecommunications, government, and healthcare sectors. WildFly serves as the community upstream. Any deployment that meets all three conditions is vulnerable:

• Uses CLIENT-CERT (mutual TLS) authentication for any web application.
• Runs behind an AJP reverse proxy (Apache httpd with mod_jk or mod_proxy_ajp).
• Exposes the AJP listener (port 8009) to any network the attacker can reach.

Deployments that use HTTP instead of AJP for proxy communication are not affected. Deployments that isolate the AJP port on a loopback interface or dedicated management network are at lower risk. No fixed version has been published as of August 11, 2026.

What to do

No patch version is available yet. Apply these mitigations immediately:

• Block the AJP port at the network layer. Port 8009 should never be reachable from outside the application server host. Configure your firewall to allow AJP traffic only from the reverse proxy's IP address. This is the single most effective mitigation.
• Bind AJP to loopback or a private interface. In the Undertow configuration, bind the ajp-listener to 127.0.0.1 or a dedicated management interface IP. Do not bind to 0.0.0.0.
• Switch from AJP to HTTP reverse proxying. If you use mod_proxy, switch from mod_proxy_ajp to mod_proxy_http. HTTP proxying does not carry the trusted-attribute model that AJP does, eliminating this entire class of vulnerability.
• Verify CLIENT-CERT at the proxy, not the backend. If your architecture allows, terminate and validate mutual TLS at the reverse proxy layer. Pass the authenticated identity to the backend via a header you control, rather than relying on AJP's ssl_cert attribute.

Why it matters

This vulnerability is part of a pattern. AJP's attribute-forwarding trust model has produced multiple serious CVEs over the past seven years. Each one found a different attribute to exploit, but the root cause is the same: the backend trusts atted attributes from the proxy without cryptographic verification of the proxy's identity.

The CLIENT-CERT bypass is distinct from Ghostcat. Ghostcat enabled arbitrary file reads. This CVE enables authentication bypass. For deployments that rely on mutual TLS as their primary authentication mechanism, a bypass here grants the attacker direct application access under an authenticated identity.

The hol.org CVE record does not yet carry a CVSS score. Based on the attack pattern (unauthenticated, requires network access to AJP port, results in auth bypass on CLIENT-CERT-protected applications), this likely scores in the 7.x to 8.x range pending NVD analysis.

References

• CVE-2026-15554 on hol.org
• CVE-2026-15554 on NVD (pending enrichment)
• CVE-2020-1938 (Ghostcat) on NVD