Apache Tomcat CVE Round-Up: 10 Vulnerabilities Patched Across Tomcat 9, 10, and 11 (April 2026)
Two High-severity EncryptInterceptor vulnerabilities, a pair of incomplete-patch bypasses, and eight more findings across Tomcat 9, 10, and 11 — here is what changed and what still needs attention.
Apache Tomcat had a busy early spring. A coordinated wave of releases across Tomcat 9, Tomcat 10, and Tomcat 11 disclosed 10 vulnerabilities on April 9, 2026, covering fixes shipped in March and April. The severity range runs from two High-severity issues (CVE-2026-29146 and CVE-2026-34486, both involving the EncryptInterceptor) down through a cluster of Medium and Low findings touching TLS configuration, OCSP validation, request smuggling, and credential exposure in logs.
The story that connects this batch: two of the ten CVEs exist because an earlier patch was incomplete. CVE-2026-34486 specifically undermines the 9.0.116 fix for CVE-2026-29146. If your team updated to address the EncryptInterceptor issue last month, you are not fully remediated yet.
If you're running any version of Tomcat 9, 10, or 11 prior to the April 2026 releases, some combination of these ten applies to you. Here's the full picture.
Fixed in 9.0.117, 10.1.54, 11.0.21
Fixed in 9.0.116, 10.1.53, 11.0.20
Fixed in Apache Tomcat (April 3, 2026)
CVE-2026-34486 | High | EncryptInterceptor bypass
The most significant of the four. This one exists because the fix for CVE-2026-29146 in 9.0.116 introduced an error that allowed the EncryptInterceptor to be bypassed entirely. If you updated to 9.0.116 specifically to address the padding oracle issue in the EncryptInterceptor (CVE-2026-29146), you need 9.0.117 to complete the remediation. The original fix introduced a new bypass path. Affects 9.0.116 only.
This is the kind of CVE that earns its High rating not just on technical merit but on context: it specifically undermines a security patch that teams may have just deployed, and it affects only the version that tried to fix the underlying problem.
CVE-2026-34500 | Medium | OCSP soft-fail bypass with FFM
When CLIENT_CERT authentication is configured with soft-fail disabled and the FFM (Foreign Function & Memory API) integration is in use, OCSP certificate revocation checks don't fail as expected in some scenarios. The practical result: a certificate that should trigger a hard failure may be silently accepted instead. Affects 9.0.92 to 9.0.116.
This is a sibling of CVE-2026-29145 (9.0.116), which covered the same OCSP soft-fail behavior without the FFM-specific path. If you applied 9.0.116 for CVE-2026-29145, this is the FFM edge case that wasn't covered.
CVE-2026-34487 | Low | Kubernetes bearer token in cluster logs
The cloud membership component for Tomcat clustering was logging Kubernetes bearer tokens in plaintext log messages. If your logging infrastructure ships logs to a central aggregator, SIEM, or shared storage, this is a credential exposure risk regardless of the Low severity rating. Bearer token exposure in logs is exactly the kind of finding that compliance teams flag in SOC 2 reviews. Affects 9.0.13 to 9.0.116.
CVE-2026-34483 | Low | JSON access log injection
When non-default values were used for the Connector attributes relaxedPathChars and/or relaxedQueryChars, incomplete escaping allowed arbitrary JSON to be injected into JSON-format access logs. If your logging pipeline parses access logs downstream (SIEM ingestion, log analytics, alerting), injected content could corrupt or manipulate those log entries. Affects 9.0.40 to 9.0.116.
Fixed in Apache Tomcat (March 20, 2026)
CVE-2026-29146 | High | EncryptInterceptor padding oracle attack
The EncryptInterceptor uses CBC mode encryption by default. CBC without proper authentication is vulnerable to padding oracle attacks, which can allow an attacker to decrypt intercepted traffic. This is the root vulnerability that CVE-2026-34486 later partially reopened. If you're using the EncryptInterceptor for Tomcat clustering traffic encryption, this is the critical one to understand: CBC default is the problem, and the fix in 9.0.116 was subsequently incomplete (see CVE-2026-34486 above). You need 9.0.117 for a complete resolution. Affects 9.0.13 to 9.0.115.
CVE-2026-32990 | Medium | SNI case-sensitivity bypass (incomplete fix)
The fix for CVE-2025-66614 in 9.0.113 was meant to enforce strict SNI name and hostname matching. It didn't account for case differences. An attacker could bypass strict SNI checks by varying the case of the hostname, allowing traffic intended for one virtual host to potentially reach another. Affects 9.0.113 to 9.0.115. This is the second patch-on-patch story in this round-up: incomplete validation logic addressed in one release, bypassed in the next.
CVE-2026-29145 | Medium | OCSP soft-fail bypass (CLIENT_CERT auth)
When CLIENT_CERT authentication is configured with soft-fail disabled, OCSP revocation checks didn't fail as expected in some scenarios. A revoked certificate that should result in a hard auth failure may have been accepted. If your application relies on OCSP for certificate revocation enforcement, this gap means clients with revoked certificates may have been authenticating successfully. Affects 9.0.13 to 9.0.115.
CVE-2026-29129 | Low | TLS cipher preference order not preserved
TLS 1.3 cipher suite configuration was added, but the implementation didn't preserve the configured order of cipher suites and ciphers. If your security policy requires a specific cipher preference order (common in FedRAMP, PCI DSS, and DoD hardening requirements), the order you configured was not being honored. This is a compliance documentation risk as much as a technical one: the configuration said one thing, the runtime did another. Affects 9.0.114 to 9.0.115.
CVE-2026-25854 | Low | Open redirect via LoadBalancer draining state
When a Tomcat node in a cluster was placed in the LoadBalancerDrainingValve disabled/draining state, a specially crafted URL could trigger a redirect to an attacker-controlled URI. Open redirects are consistently Low severity on their own but land in phishing and credential harvesting attack chains with disproportionate frequency. Affects 9.0.0.M23 to 9.0.115.
CVE-2026-24880 | Low | Request smuggling via chunk extension
Tomcat didn't validate the contents of HTTP/1.1 chunk extensions. If a reverse proxy in front of Tomcat permitted CRLF sequences in an otherwise valid chunk extension, this enabled a request smuggling attack. The attack requires both a vulnerable Tomcat version and a reverse proxy that passes through malformed chunk extensions, but request smuggling is a high-consequence class of vulnerability when the conditions align. Affects 9.0.0.M1 to 9.0.115.
The patch-on-patch pattern
Two of these ten CVEs exist because a previous fix was incomplete:
CVE-2026-32990 corrects a case-sensitivity gap in the CVE-2025-66614 SNI validation fix. The original fix enforced strict hostname matching but didn't normalize case before comparison. The bypass was straightforward once the fix was public.
CVE-2026-34486 is the harder one. The fix for CVE-2026-29146 (EncryptInterceptor CBC padding oracle) introduced an error that left the EncryptInterceptor bypassable. Teams that updated to 9.0.116 specifically for the EncryptInterceptor fix are in a worse position than teams that skipped it: they're on 9.0.116, which has the new bypass, without realizing the remediation was incomplete. If this applies to your team, 9.0.117 is the correct target.
The lesson here is one that holds across the Java ecosystem: when a High severity patch ships, the fix itself becomes a target for bypass research. Tracking just "is the CVE patched?" is not enough if the patch is subsequently undermined.
What this means if you're on Tomcat 9.x
If you're on 9.0.115 or earlier, upgrading to 9.0.117 closes all ten of these. That's the OSS path, and for teams on current supported branches, it's the right move.
Tomcat 9.x reaches end-of-life on March 31, 2027. The 10.x and 11.x branches use the jakarta.* namespace and represent the long-term supported path. Migrating from Tomcat 9 to 10 is not a drop-in upgrade: the javax.* to jakarta.* namespace change requires updates across your application code and dependencies. For many enterprise teams running large Servlet-based applications, that migration is a multi-quarter project.
HeroDevs NES for Tomcat provides security-patched packages for teams that can't immediately complete the Tomcat 9 migration. NES currently covers EOL Tomcat 8.5 and will extend support for Tomcat 9.0 past the March 2027 end-of-life date, keeping scanner findings resolved and giving your team the runway to migrate on a planned timeline rather than under audit pressure.
If you're still on Tomcat 8.5 or earlier, the conversation is more urgent. Read on.
Contact HeroDevs to learn about NES for Tomcat
NES is a bridge, not a destination.
What this means if you're on Tomcat 8.5
Tomcat 8.5 reached end-of-life on June 30, 2024. The right path forward is upgrading to a currently supported version of Tomcat. Tomcat 10.1 and 11.0 are the actively maintained branches, and the Apache community continues to release security patches for both.
That said, getting from 8.5 to 10 is not a version bump. The javax.* to jakarta.* namespace change requires updates across your application code and dependencies, and for large enterprise Servlet-based applications that's a multi-quarter effort. Upgrading to 9 first closes the 8.5 EOL gap but lands you on a version that reaches its own end-of-life in March 2027, with the namespace migration still ahead of you. That's two migrations in sequence, not one.
If a direct migration to Tomcat 10 or 11 isn't feasible on your current timeline, HeroDevs NES for Tomcat 8.5 is here to help. NES delivers security-patched packages for EOL Tomcat 8.5 via a drop-in, token-authenticated private registry, requiring minimal or no code changes in most environments. Scanner findings resolve, audit attestation is available, and your team gets the runway to plan and execute a single, well-scoped migration to a supported branch instead of chasing two EOL deadlines back to back.
Contact HeroDevs to learn about NES for Tomcat
Fixed in NES 8.5
Frequently asked questions
I updated to 9.0.116 for the EncryptInterceptor fix. Am I still vulnerable?
Yes. CVE-2026-34486 in 9.0.117 addresses a bypass introduced by the 9.0.116 fix for CVE-2026-29146. You need 9.0.117 to fully close the EncryptInterceptor issue.
Are all 10 CVEs in every affected version?
No. Each CVE has its own version range. The table above shows which version closes each one. Broadly, 9.0.117 fixes everything on this list. If you have specific version constraints, check the affected range for each CVE individually.
How do I know if I'm using the EncryptInterceptor?
Search your Tomcat configuration for EncryptInterceptor in server.xml or cluster configuration files. If it's present, CVE-2026-29146 and CVE-2026-34486 both apply to you.
The Kubernetes bearer token CVE is Low. Should I care?
Yes, if you're running Tomcat clustering in a Kubernetes environment. Severity ratings reflect the technical exploitability of a vulnerability in isolation. Bearer token exposure in logs is a low-complexity, high-impact finding in any security review or SOC 2 audit. Severity rating doesn't capture log pipeline exposure.
What's the right path if we can't upgrade to 9.0.117 right now?
Short-term: disable or restrict the affected features where possible. For the EncryptInterceptor issues, reconfigure to avoid CBC mode if your version allows it. For OCSP, evaluate whether compensating controls exist at the load balancer or mTLS layer. For the long term, 9.0.117 is the OSS fix. If staying on an older 9.x branch is a business requirement, HeroDevs NES provides a remediated package path.
Related:
.png)
