CISA added CVE-2026-34486 to the Known Exploited Vulnerabilities catalogue in August 2026. It is classified as missing encryption of sensitive data, carries a CVSS score of 7.5, and allows a bypass of Apache Tomcat's EncryptInterceptor.
That last part deserves attention, because it describes a failure mode most monitoring will never surface.
What EncryptInterceptor is for
Tomcat clustering replicates session state between nodes so a user's session survives a node failure. That replication traffic contains session identifiers and whatever objects the application stores in the session — which in most applications means authentication state, user identifiers, and often a good deal more.
That traffic crosses a network. If the network is untrusted, or merely less trusted than the application, it needs encryption. EncryptInterceptor is the component that provides it: you add it to the cluster channel configuration, supply a key, and replication traffic is encrypted between nodes.
It is opt-in. Adding it is a deliberate act by an operator who identified the risk and addressed it.
Why a bypass is worse than an absence
Consider the two states.
No encryption configured. The risk is visible. It appears in configuration review, in architecture diagrams, in the compliance questionnaire asking whether inter-node traffic is encrypted. The honest answer is "no," and somebody eventually funds fixing it.
Encryption configured but bypassable. Every artefact says the traffic is protected. The configuration file contains the interceptor. The architecture diagram shows an encrypted channel. The auditor's question gets a truthful-seeming "yes." And the traffic on the wire is not protected in the way everyone believes.
The second state is more dangerous precisely because it consumes the attention that would otherwise go to the problem. A known gap gets compensating controls; a gap you believe is closed gets nothing.
This generalises well beyond Tomcat. Silent security-control failures are a category worth treating separately from missing controls. TLS verification disabled by a permissive default, a signature check that returns true on parse failure, an authorization middleware that is registered but never reached on one route — all share the property that the system reports success while providing no protection.
Practical response
The mitigation for this specific CVE is the usual one: identify affected Tomcat versions and update to a fixed release. That work is unglamorous and effective.
Two things are worth doing alongside it.
Establish where clustering is actually enabled. Tomcat clustering is often configured once, years ago, by someone who has since left. Instances that were clustered for a load profile that no longer exists still replicate sessions. The inventory question — which of our Tomcat deployments run clustering, on which network segments — is frequently unanswered, and it determines the real exposure.
Verify the control rather than the configuration. The lesson of a bypass is that reading the config file is insufficient evidence. Capture traffic between two cluster nodes on a test environment and confirm it is unreadable. This takes an afternoon and is the only assertion that survives a bypass class of bug.
That second habit is the transferable one. For any encryption-in-transit control you rely on, there is a difference between "configured" and "demonstrated," and only the second is evidence.
The network-segmentation dependency
Cluster replication traffic should not be on a segment where interception is plausible in the first place. Encryption of that channel is defence in depth, not the primary control.
If your Tomcat nodes replicate across a network segment that also carries general application traffic, or that other tenants and workloads can reach, the encryption bypass is a serious exposure. If they replicate over a dedicated, tightly scoped segment, the same CVE is a hardening item.
This is worth stating plainly because it changes the remediation urgency by an order of magnitude, and it is a determination only you can make about your own topology. It is also the reason KEV listings need local context: the catalogue tells you exploitation is happening somewhere, not that your specific deployment is reachable.
Where this sits in the wider Tomcat picture
Tomcat has a long history of vulnerabilities in the clustering and session-persistence surface — the PersistenceManager deserialization issues, the AJP connector's Ghostcat file-read and RCE path, and an incomplete fix that reopened one of them.
The common thread is that these are all inter-node and connector protocols that were designed for trusted networks and then deployed onto networks that stopped being trusted. AJP assumed a reverse proxy in front of it. Session replication assumed a private cluster segment. Both assumptions held in 2010-era topologies and hold much less often in container orchestration, where "the network" is a flat overlay and any workload may be able to route to any other.
If you run Tomcat clustering, the highest-value work is usually not this CVE. It is confirming that the replication channel is on a segment that justifies the trust the protocol was designed around.
How Safeguard helps
Version inventory that includes embedded runtimes. Tomcat frequently arrives inside something else — an application server bundle, a vendor appliance, a base container image, or as tomcat-embed-core in a Spring Boot dependency tree. Safeguard's Supply Chain Core resolves those transitive and embedded instances into a continuous CycloneDX and SPDX SBOM, so an affected version inside a vendor product is visible rather than invisible.
Reachability and network context in prioritisation. Whether this CVE is urgent depends entirely on whether clustering is enabled and what segment carries the traffic. Safeguard incorporates configuration and network exposure alongside KEV membership and EPSS, so the finding is ranked against your topology rather than a generic score.
Configuration drift detection for security controls. A control that is present in the reference configuration and absent — or ineffective — in a running environment is exactly the gap this CVE class exploits. Safeguard flags divergence between the security configuration you intend and the one deployed.
Griffin for the version bumps. Tomcat updates in a large estate mean touching container base images, Maven and Gradle manifests, and deployment descriptors across many repositories. Griffin authors and tests those changes as reviewable pull requests in parallel.
If you configured EncryptInterceptor, go and capture the traffic between two nodes. Configuration is a claim; a packet capture is evidence.
Sources: The Hacker News — CISA Flags Langflow, Tomcat, and N-central Flaws as Actively Exploited · CISA Known Exploited Vulnerabilities Catalog · Apache Tomcat Security Advisories
