CVE-2025-66614 & CVE-2026-24733: Two Tomcat Vulnerabilities That Also Affect Spring Boot 2.7

On February 17, 2026, the Apache Software Foundation disclosed two new vulnerabilities in Apache Tomcat. Individually, CVE-2025-66614 (moderate) and CVE-2026-24733 (low) look like narrow edge cases. Together, they reveal something more important: Tomcat's request handling has been trusting protocol-level identity signals that attackers can trivially forge.

If you are running Tomcat 8.5, you are exposed to both, and you will never receive an official patch. And if you are running Spring Boot 2.7, you are carrying the same vulnerable Tomcat in your application's dependency tree, whether you realize it or not.

‍

What are CVE-2025-66614 and CVE-2026-24733?

Both vulnerabilities are classified as CWE-20 (Improper Input Validation). Both allow an attacker to bypass access controls. Both were disclosed on the same day. And both share a common root cause: Tomcat accepted conflicting identity information from different layers of the request without cross-validating them.

‍

CVE-2025-66614: Client certificate authentication bypass via SNI mismatch

Severity: Moderate CWE: CWE-20 (Improper Input Validation) Reported: October 15, 2025 Disclosed: February 17, 2026

When Tomcat is configured with multiple virtual hosts and different TLS requirements per host, the server needs to know which host the client is connecting to at two different points: during the TLS handshake (via the SNI extension) and in the HTTP request (via the Host header). Tomcat did not validate that these two values matched.

This means an attacker could initiate a TLS connection using the SNI hostname of a virtual host that does not require client certificate authentication, then send the actual HTTP request to a virtual host that does. The result: the client certificate requirement is silently bypassed.

Affected versions:

‍

Preconditions for exploitation:

• Multiple virtual hosts configured on the same Connector
• At least one virtual host requires client certificate authentication
• At least one other virtual host does not
• Client certificate authentication is enforced only at the Connector level (not in the application layer)

This is not an exotic configuration. Enterprises running Tomcat as a shared application server with mixed internal/external endpoints will recognize it immediately.

‍

CVE-2026-24733: Security constraint bypass via HTTP/0.9

Severity: Low CWE: CWE-20 (Improper Input Validation) Identified: November 26, 2025 Disclosed: February 17, 2026

HTTP/0.9 is a protocol from 1991 that supports only GET requests. It has no headers, no status codes, and no content negotiation. The specification explicitly limits it to the GET method.

Tomcat did not enforce this limitation. If a security constraint was configured to allow HEAD requests to a URI but deny GET requests, an attacker could send a specification-invalid HEAD request using HTTP/0.9, and Tomcat would process it as a GET. The security constraint that should have blocked the GET was bypassed entirely.

Affected versions: Same as CVE-2025-66614 (see table above). Fixed in 9.0.113, 10.1.50, 11.0.15. No official fix for Tomcat 8.5.

Preconditions for exploitation:

• A security constraint differentiates between HEAD and GET for the same URI
• Tomcat is reachable via HTTP/0.9 (not blocked by a reverse proxy or WAF)

The severity is rated low because the prerequisite configuration, allowing HEAD but denying GET to the same endpoint, is unusual. But "unusual" is not the same as "nonexistent." Method-level security constraints appear in audit-driven configurations, compliance-focused deployments, and applications that expose metadata endpoints via HEAD while restricting full data retrieval.

‍

How these vulnerabilities are connected

The superficial connection is timing and taxonomy: same product, same CWE, same disclosure date, same affected version ranges. But the real connection is architectural.

Both CVEs exploit the same design weakness: Tomcat trusts identity signals at one protocol layer (TLS hostname via SNI, HTTP method via request line) without validating them against identity signals at another layer (HTTP Host header, HTTP protocol version constraints). The attacker's technique in both cases is the same: present one identity to the access control check and a different identity to the request handler.

This pattern, split-identity attacks against layered protocol stacks, is well understood in security research. What makes these two CVEs notable together is that they demonstrate the pattern operating at two completely different layers of the same server: one at the TLS/HTTP boundary (CVE-2025-66614) and one at the HTTP protocol version boundary (CVE-2026-24733). Any security architecture that assumes Tomcat cross-validates identity across protocol layers should be re-evaluated.

‍

Why Tomcat 8.5 and Spring Boot 2.7 users are in a different situation

Apache Tomcat 8.5 reached end of life on March 31, 2024. The last official release was 8.5.100. Both CVE-2025-66614 and CVE-2026-24733 explicitly list 8.5.0 through 8.5.100 as affected versions, and the Apache advisory confirms that no patch will be issued for the 8.5 branch.

But the exposure extends beyond standalone Tomcat deployments. Spring Boot 2.7 embeds Tomcat 9.0.83 as its default servlet container, and both CVEs affect Tomcat 9.0.0.M1 through 9.0.112. That means every Spring Boot 2.7 application using the default embedded Tomcat (which is essentially all of them unless you explicitly swapped in Jetty or Undertow) is vulnerable to both CVEs.

Spring Boot 2.7.18, the final open source release, shipped on November 23, 2023. Its managed dependency list is frozen. There will be no Spring Boot 2.7.19 that bumps tomcat-embed-core to 9.0.113. The CVEs will remain in your dependency tree for as long as you run OSS Spring Boot 2.7, and your vulnerability scanner will flag them on every scan.

This is a pattern that compounds. As HeroDevs has documented previously, Spring Boot 2.7.18 carries at least 29 known CVEs across its managed dependencies, including Tomcat, Undertow, Elasticsearch, Jetty, and others. CVE-2025-66614 and CVE-2026-24733 add to that growing list, and every new Tomcat advisory will continue to do so.

This is not hypothetical risk. The vulnerabilities are publicly disclosed, the affected version ranges are documented, and the technical details are sufficient for an attacker to reproduce the bypass. Any compliance framework that requires timely remediation of known vulnerabilities (SOC 2, PCI DSS 4.0, the EU Cyber Resilience Act's reporting obligations starting September 2026) will flag these as open findings with no remediation path.

The upgrade problem

For standalone Tomcat 8.5 users, upgrading to 9.x is not a trivial version bump. It requires Java EE to Jakarta EE namespace migration if jumping to 10.x+, servlet API version testing, configuration migration, and regression testing of every deployed application.

For Spring Boot 2.7 users, the situation is arguably worse. Upgrading to Spring Boot 3.x requires migrating to Java 17+, switching from javax.* to jakarta.* namespaces, updating Spring Security configuration, reworking Spring Data repositories, and testing compatibility across your entire dependency graph. For large enterprise applications, this is a multi-month effort.

You cannot simply override tomcat.version in your pom.xml to bump to 9.0.113, either. While Maven allows it, Spring Boot 2.7 was never tested against Tomcat 9.0.113, and there is no guarantee of compatibility. You would be running an untested combination in production.

For organizations running either as a shared platform, the upgrade is a multi-quarter project, not a hotfix.

‍

Remediation

For teams running Tomcat 9, 10, or 11 standalone, apply the upstream patches immediately:

• Tomcat 9: upgrade to 9.0.113 or later
• Tomcat 10: upgrade to 10.1.50 or later
• Tomcat 11: upgrade to 11.0.15 or later

For teams running Spring Boot 3.x or later, check which Tomcat version your Spring Boot release manages. If your embedded tomcat-embed-core is below 9.0.113 (Spring Boot 3.x uses Tomcat 10.x, so check against the 10.1.50 threshold), upgrade your Spring Boot version to one that includes the fix.

For teams running Tomcat 8.5 or Spring Boot 2.7, the official remediation path is a major version upgrade. If that is not feasible on your security policy's required timeline, you have two interim options:

1. Mitigate at the infrastructure layer. Block HTTP/0.9 traffic at your reverse proxy or WAF (addresses CVE-2026-24733). Ensure client certificate validation occurs at the application layer, not just the Connector level (addresses CVE-2025-66614). Neither mitigation fully eliminates the vulnerability, but both reduce the attack surface.
   
   
2. Use commercial long-term support. HeroDevs NES for Apache Tomcat provides patched builds for Tomcat 8.5 that include fixes for both CVE-2025-66614 and CVE-2026-24733. The NES release (v8.5.103) validates SNI hostnames against HTTP Host headers and restricts HTTP/0.9 to GET-only, matching the fixes applied to the supported branches. For Spring Boot 2.7 users, HeroDevs NES for Spring provides updated managed dependencies, including a patched Tomcat, within a tested and compatible Spring Boot 2.7 distribution. Both are drop-in replacements: same configuration, same API surface, same deployment model.
   
   

‍

What to do right now

1. Determine your exposure. Check whether any Tomcat instance in your environment uses multiple virtual hosts with mixed TLS client certificate requirements. Check whether HTTP/0.9 traffic can reach your Tomcat servers. If either condition is true, you are exploitable.
   
   
2. Audit your version. For standalone Tomcat: run ./catalina.sh version or check the ServerInfo.properties file. Any version below 9.0.113, 10.1.50, or 11.0.15 is affected. Any 8.5.x version is affected with no official fix available. For Spring Boot 2.7: run mvn dependency:tree | grep tomcat-embed-core or the Gradle equivalent. If the version is below 9.0.113, you are vulnerable. If you are on Spring Boot 2.7.18 (the last OSS release), it will be 9.0.83, and it is vulnerable.
   
   
3. Patch or mitigate. For supported branches, upgrade. For Tomcat 8.5 or Spring Boot 2.7, implement infrastructure-layer mitigations and evaluate NES for Apache Tomcat or NES for Spring to close the gap permanently.
   
   
4. Review your security constraint model. Both CVEs bypass access controls that were correctly configured. If your security posture depends on Tomcat enforcing protocol-level constraints (client certs at the Connector, method-based security constraints), verify that those assumptions hold against cross-layer manipulation.
   
   

These are not theoretical vulnerabilities. They are publicly disclosed, well-documented, and affect one of the most widely deployed Java application servers in production, both as a standalone server and as the embedded runtime inside Spring Boot. If you are on an EOL branch, whether that is Tomcat 8.5 or Spring Boot 2.7, the gap between "known vulnerability" and "patched" only grows wider from here.

‍

HeroDevs provides Never-Ending Support (NES) for end-of-life open source software, including Apache Tomcat, Spring, Angular, Node.js, and more. NES delivers security patches, compliance documentation, and drop-in compatibility for EOL frameworks so your team can remediate vulnerabilities without forced migrations.

‍

FAQ

What are CVE-2025-66614 and CVE-2026-24733?Both are improper input validation vulnerabilities (CWE-20) in Apache Tomcat disclosed on February 17, 2026. CVE-2025-66614 allows an attacker to bypass client certificate authentication by exploiting a mismatch between the TLS SNI hostname and the HTTP Host header. CVE-2026-24733 allows an attacker to bypass HTTP method-based security constraints by sending a specification-invalid HEAD request via HTTP/0.9, which Tomcat processes as a GET.

What versions of Tomcat are affected?Both CVEs affect Tomcat 9.0.0.M1 through 9.0.112, 10.1.0-M1 through 10.1.49, and 11.0.0-M1 through 11.0.14. Official patches are available in Tomcat 9.0.113, 10.1.50, and 11.0.15. Tomcat 8.5 (all versions through 8.5.100) is affected with no official fix, as the branch reached end of life on March 31, 2024.

Why does this affect Spring Boot 2.7 users?Spring Boot 2.7 embeds Tomcat 9.0.83 as its default servlet container, which falls within the affected range for both CVEs. Spring Boot 2.7.18 was the final open-source release, and its managed dependency list is frozen — there will be no updated release bumping the embedded Tomcat to 9.0.113. Every Spring Boot 2.7 application using the default embedded Tomcat is vulnerable.

Can I just override the Tomcat version in my pom.xml?Not safely. While Maven allows overriding the tomcat.version property, Spring Boot 2.7 was never tested against Tomcat 9.0.113. Running an untested dependency combination in production introduces compatibility risk that isn't accounted for in the Spring Boot 2.7 release.

What are the preconditions for exploiting CVE-2025-66614?The application must run multiple virtual hosts on the same Connector, with at least one host requiring client certificate authentication and at least one that does not. Client certificate enforcement must occur at the Connector level rather than in the application layer. This is a common configuration in enterprises running Tomcat as a shared server with mixed internal and external endpoints.

What are the preconditions for exploiting CVE-2026-24733?A security constraint must differentiate between HEAD and GET requests for the same URI, and HTTP/0.9 traffic must be able to reach the Tomcat server. The severity is rated low because this configuration is uncommon, but it does appear in audit-driven and compliance-focused deployments.

What interim mitigations are available for Tomcat 8.5 and Spring Boot 2.7 users?Two infrastructure-layer mitigations reduce exposure: blocking HTTP/0.9 traffic at a reverse proxy or WAF addresses CVE-2026-24733, and enforcing client certificate validation at the application layer rather than only at the Connector addresses CVE-2025-66614. Neither fully eliminates the vulnerabilities, but both reduce the attack surface while a permanent remediation path is established.

How does HeroDevs NES address these CVEs?HeroDevs NES for Apache Tomcat provides a patched build (v8.5.103) that validates SNI hostnames against HTTP Host headers and restricts HTTP/0.9 to GET-only, matching the fixes applied to supported Tomcat branches. NES for Spring provides Spring Boot 2.7 users with updated managed dependencies including a patched Tomcat, within a tested and compatible distribution. Both are drop-in replacements requiring no code changes or migration.

How do I check whether my Spring Boot 2.7 application is vulnerable?Run mvn dependency:tree | grep tomcat-embed-core or the Gradle equivalent. If you are on Spring Boot 2.7.18 (the final OSS release), the version will be 9.0.83, which is vulnerable to both CVEs.

‍