The Tomcat Flaw Being Exploited Today Was Created by a Security Fix

SINGAPORE, 7 AUG 2026 — Singapore's Cyber Security Agency reported on 7 August that attackers are actively exploiting a missing-encryption flaw in Apache Tomcat. The flaw exists because of a fix.

CSA's explanation is plain: a fix for one vulnerability introduced another, leaving the original protection easy to bypass.

What broke

Tomcat clusters replicate session data between nodes. The EncryptInterceptor is the component that encrypts those messages in transit, so that the internal channel between servers is not readable by anything sitting on the network between them.

CVE-2026-34486 allows that interceptor to be bypassed. The consequence, in CSA's description, is sensitive data being transmitted without encryption between affected cluster nodes.

The CVSS score of 7.5 is not the story here. The origin of the flaw is.

A fix that created the thing it was fixing

Security patches introduce regressions like any other code change. What is unusual is the shape of the regression. A repair to the encryption path produced a second weakness in the same path, which is the one now being exploited.

An organisation that promptly applied the earlier fix is now exposed. One that never applied it is exposed to the original problem instead. Good patch discipline could not avoid both flaws.

We usually discuss patch discipline as if the only failure mode is patching too slowly. This is the other failure mode — rarer, but not rare.

The catalogue lists the bypass, not the original

CVE-2026-34486 has been in the CISA Known Exploited Vulnerabilities catalogue since 4 August, with a federal remediation deadline of 7 August. The vulnerability it was born from, CVE-2026-29146, is not in the catalogue at all.

This is not an oversight. The catalogue lists what is actively exploited; evidence of attack, not chronology or severity, determines what gets listed.

We saw the same shape in the same week. When we reported on the toolchain listings of 3 to 5 August, the N-able N-central entries arrived in the same order: the bypass was listed on 3 August and the flaw it bypasses on 4 August, the day after. Twice in one week, the descendant reached the catalogue before or instead of the ancestor.

For anyone reading the catalogue as a worklist, that has a practical consequence. A CVE identifier in it is a pointer to a specific exploited condition, not to the family of problems around it. Remediating the listed identifier can leave the related one in place, and the catalogue will not tell you.

Why an internal channel is worth attacking

The exposure here is not the public-facing application. It is the channel a Tomcat cluster uses to talk to itself.

Session replication traffic carries what sessions carry: identifiers, tokens, and whatever the application places in a user's session. It moves between nodes that trust one another, on a network segment operators tend to treat as internal and therefore safe. Encryption on that channel exists precisely because that assumption is not always true.

An attacker who can observe the segment and bypass the interceptor does not need to defeat authentication on the application. The material is on the wire.

This is the same argument that ran through the toolchain listings at the start of the month. The value for an attacker is not the broken component itself, but what that component is trusted to carry.

What the catalogue actually asks for

The entry does not simply say patch. Its required action pairs CISA's BOD 26-04 guidance on prioritising security updates based on risk with the agency's Forensics Triage Requirements, and offers a third option where mitigation is unavailable: discontinue use of the product.

That combination is the catalogue's strictest instruction, and it appeared on every entry in this batch. It tells a federal agency not just to fix the flaw, but to look for evidence that the fix is already too late.

CSA's recommendation runs the same way, and is more specific to this flaw than a generic patch notice. Administrators using Tomcat clustering with the EncryptInterceptor are told to update affected installations and to review systems for signs of unauthorised access or exposure of sensitive data.

The second half of that sentence is the part that costs money, and it is the part that gets dropped.

What to do

Patch to the fixed release, which CSA links from its alert and which should be taken from the vendor rather than from a news report.

The important check here is architectural, not mechanical. Establish whether the cluster's replication traffic crosses any segment you would not want it read on — between availability zones, across a shared virtual network, over a link a third party operates. If the answer is yes, the interceptor was doing real work and its bypass mattered for as long as the affected version was running.

The forensic question is harder than usual, and worth being honest about. Interception leaves no trace on the server. There is no log entry for traffic that was read in transit, so an absence of evidence is uninformative, not reassuring.

What can be established is exposure duration: when the affected version was deployed, and when it was replaced. That interval, set against the sensitivity of what sessions carry in your application, is the whole of the assessment available.

Who this actually reaches

Tomcat clustering is not a niche configuration. It is the standard way to run a Java web application across more than one server while keeping user sessions alive if a node fails, which makes it the default in any deployment that needs to stay up during a restart.

The three affected versions span the 11, 10.1 and 9.0 lines — the currently maintained branches, not a single release. An organisation on a supported version was in scope; an organisation on a long-unsupported one was not, for the unhelpful reason that it never received the fix that caused this.

The two questions a change board should ask

A regression in a security fix changes what a review of that fix has to establish, and most change processes are not set up for it.

The first question is whether the control the patch touched still works afterwards. A change ticket describing a security update is read as safe by definition, and the control it repairs is almost never re-tested once the version number moves.

The second is whether the patch has a parent. Where a fix exists to repair an earlier fix, the earlier one is part of the same story, and an organisation that remediates only the identifier in front of it may be closing the newer half of a pair.

What to watch

Two things.

The first is whether the parent CVE joins the catalogue. If exploitation of the original weakness is observed, it would arrive as a separate entry with its own deadline, and organisations that treated the bypass as the whole problem would find they had remediated half of it.

The second is whether the fix for this fix holds. A repair to an encryption path that has now failed twice deserves a closer read than a routine version bump. Nobody outside the project can yet say whether the third attempt is sound.