CVE-2026-65637

Overview

Apache Tomcat is an open-source web server and servlet container, maintained by the Apache Software Foundation, that implements the Jakarta Servlet, Jakarta Pages (JSP), Jakarta Expression Language, and Jakarta WebSocket specifications and provides a pure-Java HTTP environment for running Java web applications.

An authorization bypass vulnerability (CVE-2026-65637) has been identified in the Apache Tomcat HTTP/2 implementation, which allows a client to skip the strict SNI validation that ties the host a request claims to address to the TLS SNI hostname negotiated for the connection. An HTTP/2 request that supplies neither the :authority pseudo-header nor a Host header was still accepted as complete, and because the SNI comparison runs only while an authority value is being parsed, that comparison never ran for such a request. On a TLS connector serving several virtual hosts where only some require client-certificate authentication, this can let a client have its request served by a host whose TLS requirements it never satisfied.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects NES for Apache Tomcat releases 8.5.104 through 8.5.109, as well as the maintained Apache Tomcat 9.0.x, 10.1.x, and 11.0.x lines (fixed upstream in 9.0.121, 10.1.59, and 11.0.25). Stock Apache Tomcat 8.5.x releases, including the final community release 8.5.100, do not contain the strict SNI validation that this vulnerability bypasses: that feature was added by the fix for CVE-2025-66614, which the End-of-Life community 8.5.x line never received and which NES for Apache Tomcat backported to its own 8.5.x line.

Module Info

• Product: Apache Tomcat
• Affected packages: org.apache.tomcat:tomcat-coyote (embedded: org.apache.tomcat.embed:tomcat-embed-core)
• Affected versions:
  • NES for Apache Tomcat: >=8.5.104 <=8.5.109 (stock Apache Tomcat 8.5.x, including 8.5.100, is not affected)
  • Apache Tomcat 9.0.x: >=9.0.113 <9.0.121 (the advisory declares 9.0.115 through 9.0.120)
  • Apache Tomcat 10.1.x: >=10.1.50 <10.1.59 (the advisory declares 10.1.53 through 10.1.57)
  • Apache Tomcat 11.0.x: >=11.0.15 <11.0.25 (the advisory declares 11.0.20 through 11.0.24)
• GitHub repository: https://github.com/apache/tomcat
• Published packages: https://central.sonatype.com/artifact/org.apache.tomcat/tomcat-coyote
• Package manager: Maven
• Fixed in: NES for Apache Tomcat 8.5.100-tomcat-8.5.110 (upstream fixed in Apache Tomcat 9.0.121, 10.1.59, and 11.0.25)

Vulnerability Info

This Medium-severity vulnerability is found in the org.apache.tomcat:tomcat-coyote package in NES for Apache Tomcat releases 8.5.104 through 8.5.109 and in Apache Tomcat 9.0.113 through 9.0.120, 10.1.50 through 10.1.57, and 11.0.15 through 11.0.24, in the org.apache.coyote.http2 protocol implementation.

A TLS connector can serve several virtual hosts, each with its own SSLHostConfig and its own client-certificate requirements. Strict SNI validation, enabled by default, requires that the SNI hostname a client negotiates during the TLS handshake matches the hostname the request itself claims to address, so that a client cannot negotiate a session against one virtual host and then be served by another. The comparison is performed by AbstractEndpoint.checkSni(String sniHostName, String protocolHostName), and the HTTP/2 code reaches it from exactly one place: the routine that parses an incoming :authority pseudo-header or Host header and records the result as the request's server name. A request that supplies neither value never reaches that routine, so it never reaches the comparison either.

Whether an HTTP/2 request is complete enough to process is decided by Stream.receivedEndOfHeaders(). That check required a method, a scheme, and, for anything other than CONNECT, a request URI, but it never required an authority:

final boolean receivedEndOfHeaders() throws ConnectionException {
    if (coyoteRequest.method().isNull() || coyoteRequest.scheme().isNull() ||
            !coyoteRequest.method().equals("CONNECT") && coyoteRequest.requestURI().isNull()) {
        throw new ConnectionException(sm.getString("stream.header.required", getConnectionId(), getIdAsString()),
                Http2Error.PROTOCOL_ERROR);
    }

A client could therefore complete a TLS handshake using an SNI hostname of its choosing and then send an ordinary HTTP/2 request carrying :method, :scheme, and :path but neither :authority nor Host. The stream was accepted as valid, the request was processed, and the SNI comparison was silently skipped for it. Where one virtual host on the connector requires client-certificate authentication and another does not, this reopens exactly the exposure strict SNI validation was introduced to close: the handshake can be directed at the host that demands no certificate, while the request never states at the HTTP/2 layer which host it is addressing. The HTTP/1.1 path is not affected, because it parses a mandatory Host header and performs the comparison unconditionally. The Apache Tomcat security team rates this issue Moderate and published no CVSS vector for it.

The gap is the second incomplete correction in a sequence. Strict SNI validation was added to address CVE-2025-66614; CVE-2026-32990 then corrected that validation's case-sensitive handling of the hostname; and CVE-2026-65637 closes the remaining hole, that the validation can be skipped altogether by omitting the authority. Community Apache Tomcat 8.5.x reached End-of-Life before any of the three, so it never received strict SNI validation and is outside the scope of this advisory. NES for Apache Tomcat backported the CVE-2025-66614 and CVE-2026-32990 corrections to its 8.5.x line, and it is those backports, both of them fixes for real defects, that carry this remaining gap into the NES line.

Mitigation

Only recent major lines of Apache Tomcat are community-supported. The affected 8.5.x line reached End-of-Life on March 31, 2024 (final community release 8.5.100) and will not receive public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported Apache Tomcat major line (9.0.x or later) that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Parag Ambildhuke (finder)