Tomcat CVE-2026-34486 Is Under Attack: Only Three Builds Affected, Deadline August 7

[Update, August 5, 2026] A different Tomcat flaw, CVE-2026-34486, is under attack — deadline August 7

On August 4, 2026, CISA added Apache Tomcat's CVE-2026-34486 to its catalog of actively exploited vulnerabilities (KEV), giving U.S. federal agencies until August 7. This is a different flaw from the three covered in this article, disclosed back on April 9, 2026. Our conclusion — that a high number alone is no reason to panic — still holds, but this is a clean illustration of the other half of that advice: check whether something is actually being exploited.

It affects exactly three builds: 11.0.20, 10.1.53 and 9.0.116. The fix landed in 11.0.21, 10.1.54 and 9.0.117, so the routine update targets this article recommends (9.0.121 / 10.1.58 / 11.0.25) close this one too. If you run a single-node Tomcat, it does not apply to you at all.

The flaw lets an attacker slip past EncryptInterceptor, the component that encrypts traffic between nodes in a clustered setup where session state is shared. It traces back to the fix for another flaw, CVE-2026-29146, which left an unencrypted path behind. What is lost is the content of that traffic — confidentiality. In the CVSS breakdown only confidentiality is rated high; there is no tampering and no denial of service. The score is 7.5 — the same number as CVE-2026-66299, the flaw this article says you need not rush for. Two flaws can share a 7.5 and still call for completely different handling.

EPSS, which estimates how likely exploitation is, shows the same gap. As of August 4, 2026, CVE-2026-34486 sits at 0.426 — the top 1.5% of all CVEs — while CVE-2026-66299 is at 0.003 and CVE-2026-59083 at 0.004. Reading those indicators, rather than the headline number, is the point this article has been making. One caution: a public repository claiming to hold a working exploit has appeared, but its billing as "unauthenticated remote code execution" does not match NVD's assessment, where only confidentiality is affected. Do not take exploit code of uncertain provenance at face value.

What to check: whether you run Tomcat in a cluster and configure EncryptInterceptor in server.xml. If so, update ahead of your routine cycle. For the large majority who do not, the routine update remains fine. You can follow actively exploited flaws in our CISA KEV tracker (Japanese).

If your security scanner or a news item flagged "yet another vulnerability in Apache Tomcat," you may have braced for trouble. The short version: once again, there is no need to scramble into emergency response. The newly disclosed CVE-2026-66299 (published in Japan as JVNVU99139115) at the end of July 2026 may appear as "severity 7.5" in scanners, but Apache — the project that develops Tomcat — rates it "Low." And it only affects the bundled "sample" (try-it-out) application that you normally never keep in production. For the vast majority of users, it has no practical relevance.

Apache Tomcat is software for running Java-based web systems, and it is widely used behind the scenes of enterprise systems, including across Japan. Precisely because of that, a "Critical" or "severity 7.5" label tends to put whole teams on alert at once. Yet those numbers and the developer's "Low" rating are, time and again, sharply at odds. This article starts with the newest issue, CVE-2026-66299, then covers the two disclosed in mid-July — CVE-2026-59083 and CVE-2026-59084 — walking through, in order, why the numbers disagree, whether your environment is actually affected, and what to do calmly.

[Latest] CVE-2026-66299: a shutdown attack via the WebSocket chat "sample" app

On July 28, 2026, a DoS (denial of service — an attack that stops the server) vulnerability in Apache Tomcat was disclosed, and Japan's vulnerability portal JVN (JVNVU99139115) also carried it as "a DoS vulnerability in Apache Tomcat." Here is the most important fact, up front: the problem is only in the "WebSocket chat sample app" bundled with Tomcat. This is a try-it-out program that lets developers test behavior, and Apache's official guidance has long advised removing the examples web application in production. Environments that follow that advice and have removed the samples are out of scope for this issue entirely.

CVE-2026-66299: DoS via resource exhaustion in the WebSocket chat sample app

Tomcat ships with a simple chat sample app to demonstrate "WebSocket," the two-way communication between browser and server. The problem was in how that sample was built: the place that temporarily holds messages not yet delivered to the recipient (the buffer) had no upper limit. The fix commit resolves it by putting a cap on that buffer.

When a "slow client" that deliberately delays receiving connects, undelivered messages keep piling up endlessly, eating through the server's memory until the Tomcat process itself falls over — that is what CVE-2026-66299 is. It is classified as uncontrolled resource consumption (CWE-400); it was reported to Apache on July 13, 2026, and disclosed on July 28. It is not the kind of flaw that steals data or takes over a server — it is strictly the "can be stopped" type. And, to repeat, it only works when a try-it-out sample app is left in production and exposed to the outside. Apache rates its severity "Low."

Who would attack this, and why

The target is a Tomcat server left exposed to the internet with the demo sample app still in place, forgotten and not removed. For an attacker, no special ID or password is needed — they only have to connect to that sample from outside — which makes it an easy target for anyone mechanically scanning the web for exposed servers.

What the attacker does is simple. After connecting to the chat sample, they deliberately slow down how fast they receive messages, keep the undelivered ones piling up on the server side, and gradually eat up all the memory. Rather than directly stealing money or information, this is a technique suited to harassment and disruption, where stopping the service is the goal in itself.

The result is that Tomcat stops working, and the websites, business systems, and APIs running on it become unresponsive. That said, if you operate with the samples removed (the practice Apache has long recommended), this damage never occurs in the first place. Turned around, the practical way to view CVE-2026-66299 is as a prompt to check whether you are keeping to the basics of "remove the samples."

The affected versions and fixes are below. Because this flaw stems from a feature added partway through the release history, anything before 9.0.89, and the 8.5 line and earlier, is out of scope from the start — a point that differs from the two mid-July issues described later.

There are two things you can do, either one. One is to remove the examples app still sitting in production. That alone closes this hole, and it is exactly the practice Apache has long recommended. The other is to update to the fixed release (9.0.121 / 10.1.58 / 11.0.25) at your next scheduled maintenance. Neither calls for stopping the service for emergency response.

Why "7.5" and "9.1" disagree with the developer's "Low"

This is the most important part, and it is common to Tomcat vulnerability news. The same vulnerability is labeled a high "7.5" or "9.1" in one place and "Low" in another. The gap comes from who assigns the score, and how.

Severity is expressed as a number from 0.0 to 10.0 by an international yardstick called CVSS (Common Vulnerability Scoring System). The "7.5" attached to CVE-2026-66299 is a value assigned by CISA-ADP, a U.S. government-side body — a provisional score that maxes out only the "it stops" impact (availability). The "9.1" that went around for the two mid-July issues was likewise an auto-enriched score attached mechanically to the vulnerability database (NVD). Both are assigned assuming a "worst case" before each precondition is verified one by one, so they tend to come out higher than the real ease of exploitation.

The "Low" rating, by contrast, comes from Apache — the project that knows this flaw best — weighing the actual conditions and impact. For CVE-2026-66299, the premise that "this is about a sample app you should never keep in production" is properly baked into Apache's "Low." Many commercial scanners import and display the auto-enriched value or the CISA-ADP value as-is, so an internal scan can raise a "7.5" or "Critical" alarm even when the substance is not urgent. Rather than panic at the number alone, the right approach is to look at the assigning project's (developer's) rating together with whether it is actually being exploited. None of these three are listed on the U.S. CISA catalog of vulnerabilities known to be exploited (KEV) either — though a separate Tomcat flaw, CVE-2026-34486, was added to KEV on August 4, 2026 (see the update at the top).

The two disclosed earlier (CVE-2026-59083 and CVE-2026-59084)

Before this latest CVE, two vulnerabilities in Apache Tomcat were disclosed on July 14, 2026. Japan's JVN (JVNVU95286373) also carried them as "multiple vulnerabilities in Apache Tomcat." Here too Apache rates both "Low," and there are no reports of real attacks. One is an access-control bypass from a URL-interpretation gap; the other is not a flaw in the program at all, but a case where the documentation for a configuration step was insufficient. No public proof-of-concept (PoC) and no KEV listing have been confirmed.

CVE-2026-59083: a URL-interpretation gap that can bypass access control

Tomcat has a feature called "RewriteValve" that rewrites requested URLs internally. The issue was that Tomcat could mistakenly interpret a "+" (plus) sign in the rewritten URL as a space, in certain cases. Exploiting this interpretation gap could, under the right conditions, reach a path that should be protected by access control (a security constraint). This is not an RCE (remote code execution) that takes over the server, and it only works in environments that "use RewriteValve and have a specific configuration." The classification is improper handling of URL encoding (CWE-177), and it was found by the Tomcat security team itself. Apache rates its severity "Low," and the fixes are 11.0.24 / 10.1.57 / 9.0.120.

CVE-2026-59084: insufficient documentation for the encryption setting

The second concerns "EncryptInterceptor," a mechanism that encrypts communication between servers in a "cluster" setup that runs multiple Tomcat instances together. The key point is that this is not a flaw in the program, but a "documentation gap": the requirements for configuring it safely were not sufficiently written down. The classification is insufficient technical documentation (CWE-1059). Any real impact would be limited to the narrow case of an organization that had been using this encryption with a mistaken configuration, where the expected protection may not have been in effect. Apache also rates this "Low," and the fixes are likewise 11.0.24 / 10.1.57 / 9.0.120. Even this docs-only change was given a high 9.1 by auto-enrichment — an extreme example of the gap between the number and reality.

Is your environment affected?

Let's check calmly. These three only really matter in environments like the following. If none apply, there is almost no practical impact.

Fixes are provided per supported line. If you want to clear all three, use the guide below. Only CVE-2026-66299 leaves older versions from before the feature was added (before 9.0.89, and 8.5 and earlier) out of scope, whereas the two mid-July issues cover a wide range of the supported lines. Note that the Tomcat 8.5 line (and 7.0) has already reached end of life, so if you run those, the real move — regardless of these issues — is to migrate to the still-supported 9.0 line or later.

To clear all three at once, update to the newer fixed release for your line (9.0.121 / 10.1.58 / 11.0.25), which also covers the two mid-July issues in one go.

So what should you do?

The response is simple. At your next scheduled maintenance, update to the fixed release for your supported line (9.0.121 / 10.1.58 / 11.0.25). That clears all three at once. There is no call to stop the service now and apply an emergency patch. In addition, if there is an examples app still sitting in production, remove it — that closes CVE-2026-66299 on the spot without waiting for an update, and it aligns with the practice Apache has long recommended. Environments that fell under "in scope" in the earlier table (using RewriteValve, or encrypted cluster communication) should review their configuration alongside the update, for peace of mind.

The main takeaway is a mindset: don't decide based on the "7.5" or "Critical" a scanner shows, alone. Even with a high number, if you also check whether it is actually being exploited (listing on KEV), how easy exploitation is (a metric called EPSS), and the assigning project's rating, it becomes clear whether you truly need to hurry or a routine cycle suffices. In the Apache world, severity often runs hot in the coverage, yet the real severity varies greatly case by case — from the AI-discovered HTTP/2 shutdown attack to the login-free Apache MINA flaw. Checking behind the number, one case at a time, prevents both wasted fire-drills and missing the genuine emergencies.

Frequently asked questions

Q. CVE-2026-66299 shows as "severity 7.5." Should I stop everything and respond now?

A. No emergency stop is needed. The 7.5 is a value from CISA-ADP that maxes out only the "it stops" impact; Apache, the assigning project, rates it "Low," and no real exploitation has been confirmed. What's more, it only affects the sample app you normally never keep in production. Removing the examples from production, or updating to 9.0.121 / 10.1.58 / 11.0.25 at your next maintenance, is enough.

Q. If I've removed the sample app, is CVE-2026-66299 irrelevant to me?

A. Correct. This hole is specific to the WebSocket chat sample (examples) bundled with Tomcat, and Apache has long recommended removing it in production. Environments that have taken the samples out are out of scope from the start. If they are still there, this is a good chance to remove them.

Q. Why do the developer and the scanner disagree on severity?

A. What a scanner shows is often a "worst-case"-leaning value assigned mechanically by a vulnerability database or by CISA-ADP. The assigning project (developer) weighs the actual conditions and impact, so it lands closer to reality. When the numbers disagree, prioritize the project's rating and the real exploitation status.

Q. Our Tomcat is on the 8.5 line. What now?

A. Tomcat 8.5 has already reached end of life and will receive no new fixes. As it happens, the 8.5 line is out of scope for CVE-2026-66299, but including the two mid-July issues, running an end-of-life version in production is itself the bigger risk. Plan a migration to the still-supported 9.0 line or later.

In summary

The newly disclosed Apache Tomcat vulnerability CVE-2026-66299 may show up as "severity 7.5" in scanners, but Apache rates it "Low," and there are no reports of real attacks. It affects only the WebSocket chat "sample app" you normally never keep in production, where an uncapped buffer lets a slow connection eat through memory and shut things down. If you have removed the samples, it is irrelevant to begin with. The mid-July CVE-2026-59083 and CVE-2026-59084 are likewise rated "Low," and none of these call for stopping the service for emergency response.

What to do is update to 9.0.121 / 10.1.58 / 11.0.25 at your normal cadence, remove any sample app still in production, and review the configuration if you use RewriteValve or cluster encryption. That is enough. This whole set of cases is also a reminder of a basic principle in vulnerability response: don't be swept along by a "7.5" or "Critical" label — judge using the assigning project's rating, real exploitation status, and ease of exploitation.

References

• ▸JVN - JVNVU99139115 DoS vulnerability in Apache Tomcat (CVE-2026-66299)
• ▸NVD - CVE-2026-66299
• ▸JVN - JVNVU95286373 Multiple vulnerabilities in Apache Tomcat
• ▸NVD - CVE-2026-59083
• ▸NVD - CVE-2026-59084
• ▸Apache Tomcat - Security (official severity ratings)