Apache Tomcat, one of the world’s most widely deployed open-source Java web servers, has been found to carry a significant cryptographic vulnerability that exposes clustered deployments to a classic yet dangerous class of attack. Tracked as CVE-2026-29146 and rated “Important” in severity, this flaw resides within the EncryptInterceptor component.
It stems from the use of CBC (Cipher Block Chaining) mode encryption by default, a configuration choice now confirmed to be vulnerable to a padding oracle attack. The Apache Software Foundation published the original advisory on April 9, 2026, and patches are immediately available across all supported branches.
Apache Tomcat Padding Oracle Flaw
CVE-2026-29146 is a Padding Oracle vulnerability in Apache Tomcat’s EncryptInterceptor component when operating under its default configuration.
The EncryptInterceptor It is specifically designed to encrypt inter-node communications within a Tomcat cluster, ensuring that data passing between cluster members cannot be read by third parties on the network.
However, when the interceptor defaults to CBC mode without proper message authentication, attackers positioned on the same network segment can exploit predictable server responses to padding errors and progressively decrypt intercepted traffic.
A padding oracle attack is a cryptographic side-channel technique where an adversary repeatedly submits specially crafted ciphertext to a decryption oracle, in this case, the Tomcat cluster node, and observes how the system responds to valid versus invalid padding.
By analyzing whether a decryption operation succeeds or fails based on the validity of the padding, the attacker can recover the plaintext byte by byte without ever knowing the encryption key.
This class of attack, originally formalized in 2002, has been weaponized against real-world systems in high-profile breaches and remains dangerously relevant wherever CBC mode is used without an accompanying integrity check (i.e., HMAC or authenticated encryption).
The vulnerability was discovered and responsibly disclosed by Uri Katz and Avi Lumelsky of Oligo Security, a runtime security firm.
Affected Versions
The vulnerability spans five major Tomcat release lines, covering a large portion of active production deployments globally. According to the Apache OSS-Security mailing list disclosure, the following versions are confirmed vulnerable:
- Apache Tomcat 11.0.0-M1 through 11.0.18
- Apache Tomcat 10.1.0-M1 through 10.1.52
- Apache Tomcat 9.0.13 through 9.0.115
- Apache Tomcat 8.5.38 through 8.5.100
- Apache Tomcat 7.0.100 through 7.0.109
End-of-support (EOS) versions, such as Tomcat 7.x and 8.5.x, are included in the scope, meaning organizations still running these legacy branches face the same exposure with no vendor-provided patch pathway for those versions. Administrators running these older releases should treat this vulnerability as a critical signal to migrate.
Technical Root Cause
The root cause is straightforward but consequential. It EncryptInterceptor defaults to CBC mode for encrypting cluster traffic.
CBC mode, when used in isolation without an accompanying authentication mechanism (such as an HMAC-based MAC-then-Encrypt or Authenticated Encryption with Associated Data AEAD scheme), creates the conditions for a padding oracle.
When a Tomcat cluster node receives a ciphertext with incorrect padding, it returns a distinguishably different error response compared to a ciphertext with valid padding but bad content, giving attackers a binary signal they can exploit iteratively.
The SentinelOne vulnerability database clearly describes the attack path: an adversary exploits “differences in server responses when processing correctly versus incorrectly padded ciphertext,” allowing iterative decryption of sensitive cluster communications without possessing the private key.
In clustered enterprise deployments, which often carry session tokens, authentication data, and application state between nodes, the consequences of traffic decryption can include session hijacking, credential theft, and full application compromise.
Mitigation and Patched Versions
The Apache Software Foundation has released patched builds across all actively supported branches. Administrators should upgrade to one of the following fixed versions without delay:
- Apache Tomcat 11.0.20 or later
- Apache Tomcat 10.1.53 or later
- Apache Tomcat 9.0.116 or later
However, a critical downstream issue must be acknowledged. Researchers monitoring the Apache security mailing list report that the fix introduced in 9.0.116 was itself incomplete, leading to a follow-on vulnerability tracked as CVE-2026-34486, which allows it EncryptInterceptor to be bypassed entirely on the 9.0.116 build.
Organizations that upgraded specifically to 9.0.116 to address CVE-2026-29146 must further upgrade to Apache Tomcat 9.0.117 to fully close both the original padding oracle flaw and the bypass introduced by the initial patch.
This Apache patch scenario underscores the importance of continuously tracking the full advisory chain rather than applying a single version bump.
Recommended Actions for Security Teams
Organizations running Apache Tomcat in clustered configurations should immediately conduct the following:
- Audit all Tomcat deployments across environments to identify versions within the affected range
- Prioritize upgrading Tomcat 9.x deployments to 9.0.117 (not just 9.0.116) due to the bypass introduced by the intermediate fix
- Review
EncryptInterceptorconfigurations and consider switching to authenticated encryption cipher suites until the upgrade is confirmed - Monitor inbound cluster traffic for anomalous decryption error patterns that may indicate active oracle probing
- Apply compensating controls such as network segmentation or mTLS between cluster nodes if immediate patching is not possible for EOS branches like 7.x and 8.5.x
The broader lesson from CVE-2026-29146 is that default, insecure cryptographic configurations remain one of the most persistent and overlooked categories of enterprise vulnerabilities.
Unauthenticated CBC mode has been a known hazard for over two decades. Yet, its continued use as a default in widely deployed middleware demonstrates how slowly hardened defaults propagate through mature codebases.
Frequently Asked Questions (FAQs)
Q1: What is CVE-2026-29146 in Apache Tomcat?
CVE-2026-29146 is an “Important” severity padding oracle vulnerability in Apache Tomcat EncryptInterceptor, caused by the use of CBC encryption mode by default, allowing attackers to decrypt cluster traffic without the encryption key.
Q2: Which Apache Tomcat versions are affected by CVE-2026-29146?
Versions 11.0.0-M1 to 11.0.18, 10.1.0-M1 to 10.1.52, 9.0.13 to 9.0.115, 8.5.38 to 8.5.100, and 7.0.100 to 7.0.109 are all confirmed vulnerable.
Q3: Is the patch for CVE-2026-29146 in Tomcat 9.0.116 fully safe?
No, Tomcat 9.0.116 introduced a related bypass flaw (CVE-2026-34486), so Tomcat 9.x users must upgrade to 9.0.117 for complete remediation.
Q4: Who discovered CVE-2026-29146?
The vulnerability was responsibly discovered and reported by Uri Katz and Avi Lumelsky of Oligo Security, and was officially credited by the Apache Software Foundation in the April 9, 2026, advisory.
Site: http://thecybrdef.com
About the Author
