CVE-2026-34486

What it actually does

CVE-2026-34486 is a cryptographic protection failure in Apache Tomcat 11.0.20, 10.1.53, and 9.0.116 where a prior fix allowed the EncryptInterceptor to be bypassed. In affected clustered Tomcat deployments that rely on EncryptInterceptor to protect sensitive replication or cluster traffic, data that administrators expect to be encrypted may be transmitted without encryption. The primary technical impact is loss of confidentiality: an attacker with network visibility into the affected traffic path could read sensitive session, application, or cluster data in transit. The CVSS vector indicates network exploitability, low attack complexity, no required privileges, no user interaction, and high confidentiality impact, with no direct integrity or availability impact.

Why it matters to the business

Organizations running affected Apache Tomcat versions may unknowingly expose sensitive application or session data on the network despite believing encryption is enabled. This can lead to credential/session compromise, exposure of personal or regulated data, breach notification obligations, compliance findings, and loss of customer trust. The risk is elevated because the vulnerability is listed in CISA KEV, has reported active exploitation, has a high EPSS probability, and is past the CISA remediation due date of 2026-08-07, making delayed remediation operationally and governance-significant.

How an attack unfolds

An attacker first identifies Apache Tomcat deployments using affected versions, especially clustered configurations where EncryptInterceptor is configured to protect sensitive intra-cluster traffic. The attacker then obtains a network position that can observe traffic between Tomcat nodes or relevant application communication paths, such as through compromised adjacent infrastructure, malicious insider access, exposed network segments, or traffic capture on an insufficiently segmented environment. Because the affected versions may bypass EncryptInterceptor, the attacker can capture traffic that operators expect to be encrypted but is actually sent in cleartext or without the intended protection. The attacker then analyzes captured packets or logs to recover sensitive values such as session data, application state, tokens, credentials, or user data, and may reuse that information for account takeover, lateral movement, or further application compromise. Active in-the-wild exploitation and KEV status indicate defenders should assume public exploit knowledge and prioritize investigation as well as patching.

How to fix it

Upgrade affected Apache Tomcat installations to a fixed release: upgrade Tomcat 11.0.20 to 11.0.21 or later, Tomcat 10.1.53 to 10.1.54 or later, and Tomcat 9.0.116 to 9.0.117 or later. Because this vulnerability is in CISA KEV and has active exploitation, treat remediation as urgent and verify all packaged, embedded, containerized, and vendor-bundled Tomcat instances, not only standalone servers. If immediate upgrade is not possible, reduce exposure by isolating Tomcat cluster traffic on trusted networks, enforcing transport-layer encryption such as TLS or VPN/IPsec independently of EncryptInterceptor, restricting access to cluster ports, disabling clustering features not in use, and preventing packet capture visibility from untrusted network segments. Mitigations should be considered temporary until the fixed Tomcat version is deployed.

How to confirm the fix worked

Confirm the installed Tomcat version is not 11.0.20, 10.1.53, or 9.0.116 and is at least 11.0.21, 10.1.54, or 9.0.117 respectively. Check server startup logs, package manager output, container image manifests, build dependencies, and bundled application server distributions for the effective Tomcat version. Review Tomcat clustering configuration for use of EncryptInterceptor and verify that sensitive inter-node traffic is also protected by TLS, VPN, IPsec, or equivalent transport encryption. Where safe and authorized, perform a packet capture on the relevant cluster traffic path after patching and confirm sensitive payloads are not readable in cleartext. Validate network segmentation and firewall rules so only expected peer nodes can reach Tomcat cluster communication ports.

Typical attack path

1. Identify internet-facing or internally reachable Apache Tomcat instances and determine whether they run 11.0.20, 10.1.53, or 9.0.116.
2. Determine whether the deployment uses clustering or configurations that rely on EncryptInterceptor for sensitive traffic protection.
3. Gain or use an existing network vantage point where Tomcat cluster or application traffic can be observed.
4. Capture traffic that should have been encrypted by EncryptInterceptor.
5. Inspect captured traffic for readable session data, tokens, credentials, application state, or personal data.
6. Use recovered sensitive data to impersonate users, access applications, or support additional intrusion activity.

How to detect it

To determine whether exploitation or exposure already occurred, focus on evidence of unencrypted sensitive traffic and suspicious access to Tomcat cluster communication paths. Review network flow logs, firewall logs, IDS/IPS alerts, packet broker records, packet capture repositories, and EDR/NDR telemetry for unexpected systems communicating with Tomcat cluster ports or observing traffic between Tomcat nodes. Examine Tomcat logs, startup logs, configuration files, and deployment records to identify the period when affected versions 11.0.20, 10.1.53, or 9.0.116 were running with EncryptInterceptor configured. Search for packet captures, tcpdump/Wireshark activity, unusual promiscuous-mode network interfaces, or unauthorized diagnostics on hosts or network devices that could observe Tomcat traffic. Look for subsequent signs of misuse of exposed data, such as anomalous session reuse, authentication from unusual locations, unexpected application access using valid sessions, or token reuse shortly after inter-node traffic was observable. There are no universal payload IOCs for this issue because exploitation may consist of passive traffic capture, so detection should emphasize affected-version exposure, network vantage points, readable traffic, and downstream misuse of captured secrets.

• Apache Tomcat/11.0.20
• Apache Tomcat/10.1.53
• Apache Tomcat/9.0.116
• org.apache.catalina.tribes.group.interceptors.EncryptInterceptor
• EncryptInterceptor
• conf/server.xml
• tcpdump
• tshark
• wireshark
• dumpcap
• pcap
• promiscuous mode

What your security team should do

• Immediately inventory all Apache Tomcat deployments, including embedded, containerized, appliance-bundled, and vendor-supplied instances.
• Prioritize upgrades to Tomcat 11.0.21+, 10.1.54+, or 9.0.117+ for any affected versions, especially clustered deployments using EncryptInterceptor.
• Because the issue is in CISA KEV, has active exploitation, and is past the 2026-08-07 remediation deadline, escalate patching through emergency change or highest-priority vulnerability management workflows.
• Hunt for prior exposure by reviewing network telemetry, packet capture systems, IDS events, and access logs around Tomcat cluster networks since deployment of affected versions.
• Restrict Tomcat cluster communication to trusted peer nodes only and ensure independent transport encryption is enforced even after patching.
• Rotate secrets, invalidate sessions, and review access tokens if evidence suggests sensitive traffic was captured or exposed.
• Update base images, golden AMIs, application server packages, and dependency manifests to prevent reintroduction of affected Tomcat versions.
• Monitor Apache Tomcat advisories and vendor distributions for downstream fixed package releases if Tomcat is bundled inside another product.