CVE-2026-32990

Overview

Apache Tomcat is an open-source implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Annotations, and Jakarta Authentication specifications, providing a pure Java HTTP web server environment for running Java code. It is one of the most widely used Java application servers.

‍

A medium-severity vulnerability (CVE-2026-32990) has been identified in Apache Tomcat as an incomplete fix for CVE-2025-66614. The validation of SNI (Server Name Indication) name and HTTP Host header hostname did not account for possible differences in case, allowing the strict SNI checks to be bypassed by sending a mixed-case hostname in the HTTP Host header.

‍

Per OWASP: Authorization Bypass occurs when an attacker can circumvent access controls, potentially gaining unauthorized access to protected resources. In this case, an attacker could bypass the strict SNI hostname validation by exploiting case-insensitive hostname matching, potentially accessing resources protected by client certificate authentication on a different virtual host.

‍

This issue is fixed in NES for Apache Tomcat 8.5.105, and affects versions 9.0.113 through 9.0.115, 10.1.50 through 10.1.52, and 11.0.15 through 11.0.19 of Apache Tomcat.

‍

Details

Module Info

• Product: Apache Tomcat
• Affected packages: tomcat-coyote
• Affected versions: =nes-v8.5.104, >=9.0.113 <=9.0.115, >=10.1.50 <=10.1.52, >=11.0.15 <=11.0.19
• GitHub repository: https://github.com/apache/tomcat
• Published packages: https://repo1.maven.org/maven2/org/apache/tomcat/tomcat-coyote/
• Package manager: Maven
• Fixed in:
  
  • NES for Apache Tomcat
  • Apache Tomcat 11.0.20, 10.1.53, 9.0.116 (OSS)

‍

Vulnerability Info

The vulnerability exists in the checkSni() method of AbstractEndpoint.java, which was introduced as part of the CVE-2025-66614 fix to validate that the SNI hostname matches the HTTP Host header. The method calls getSSLHostConfig(protocolHostName) without lowercasing the protocolHostName parameter.

‍

The getSSLHostConfig() method's javadoc specifies that its parameter must be in lowercase, and the internal sslHostConfigs map is keyed by lowercase hostnames. The SNI hostname is always lowercase per the TLS specification, but the HTTP Host header can contain mixed-case characters (e.g., Example.COM).

‍

When a client sends a mixed-case HTTP Host header, the lookup fails to find the correct SSLHostConfig, falling through to the default. This allows bypassing the strict SNI validation because the SNI hostname resolves to one SSLHostConfig while the non-lowercased protocol hostname resolves to the default, potentially making them match when they should not.

‍

The fix adds toLowerCase(Locale.ENGLISH) normalization:

‍

// Fixed code:
|| getSSLHostConfig(sniHostName) == getSSLHostConfig(
        protocolHostName != null ? protocolHostName.toLowerCase(Locale.ENGLISH) : null));

‍

In the upstream OSS releases, only versions 9.0.113 through 9.0.115 are affected because the checkSni() feature was introduced in 9.0.113 (as the CVE-2025-66614 fix) and the case-sensitivity bug was fixed in 9.0.116. The NES for Apache Tomcat 8.5.x branch is also affected because the CVE-2025-66614 fix was backported to NES 8.5.104 and contains the same case-sensitive protocolHostName comparison.

‍

Steps To Reproduce

To exploit this vulnerability, the Tomcat instance must have strictSni="true" configured on the Connector and multiple SSLHostConfig entries with different client certificate requirements. The attacker sends a TLS connection with a lowercase SNI hostname but a mixed-case HTTP Host header:

‍

TLS ClientHello SNI: secure.example.com
HTTP Host: Secure.Example.COM

‍

The SNI hostname secure.example.com matches the SSLHostConfig that requires client certificates, but the mixed-case Secure.Example.COM fails the case-sensitive map lookup and falls back to the default SSLHostConfig (which may not require client certificates). Since both resolve to different configs, the strict SNI check may pass incorrectly, allowing access without the required client certificate.

‍

Mitigation

Only recent versions of Apache Tomcat are community-supported. Older versions (8.5.x and earlier) will not receive any updates to address this issue. NES for Tomcat includes an update to 8.5.x to address this issue. For more information, see here.

‍

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

• Upgrade to a patched version of Apache Tomcat.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• zhengg (finder)