A Chinese hacker wired DeepSeek into an autonomous attack framework and pointed it at unpatched Apache Tomcat servers, and CISA wants federal systems fixed by Friday — everyone else should move just as fast.
The Cybersecurity and Infrastructure Security Agency told every federal civilian agency to patch a specific Apache Tomcat bug by this Friday, August 7. That part is routine — CISA adds a handful of vulnerabilities to its Known Exploited Vulnerabilities catalog most weeks. What isn't routine is who got caught using it: an autonomous attack framework with DeepSeek wired in as its reasoning engine, running reconnaissance and exploitation while a human operator mostly just watched from Telegram.
A padding oracle that got patched into a new hole
This started back in April. Tomcat's EncryptInterceptor — the component that adds pre-shared-key encryption to messages passed between clustered Tomcat nodes — used CBC mode by default, and CBC mode without proper padding checks is a textbook padding oracle. An attacker with network access to the cluster port could decrypt and forge encrypted cluster messages without ever knowing the key, which opens the door to session manipulation and injecting malicious serialized payloads. That was disclosed publicly on the Tomcat security list on April 9 as CVE-2026-29146, and fixed in 11.0.19, 10.1.53, and 9.0.116.
Except the fix had a bug in it. It closed the padding oracle but left EncryptInterceptor bypassable a different way — and that gap is CVE-2026-34486, the one CISA just flagged. Anyone who patched back in April and moved on is still exposed today.
The April fix left EncryptInterceptor bypassable a different way
11.0.21 / 10.1.54 / 9.0.117
The part that should actually worry you
As Infosecurity Magazine and other outlets documented after reviewing the campaign, an actor going by knaithe (also KnYuan), reportedly based in Zhuhai, China, built an attack stack with DeepSeek wired in as the decision-making layer of a framework called Hermes Agent — orchestrated over Telegram for target selection and exploit sourcing, running non-interactively. Across roughly 460 attempted targets, researchers confirmed only three actual compromises: memory data exfiltration from Citrix NetScaler appliances, and a suspected session-hijacking attempt against a Malaysian government entity. Tomcat came in through a separate, more manual phase of the same campaign — reverse-shell attempts against nine internet-exposed servers using CVE-2026-34486, as BleepingComputer reported when CISA added the flaw to its KEV catalog.
Are you actually exposed
1
Check your Tomcat version against the vulnerable ranges: 11.0.0-M1 through 11.0.20, 10.0.0-M1 through 10.1.53, and 9.0.13 through 9.0.116.
2
Confirm whether clustering is enabled and EncryptInterceptor is configured — standalone Tomcat with clustering off isn't reachable through this specific bug.
3
Upgrade to 11.0.21, 10.1.54, or 9.0.117 — not just the April patch, which this bug bypasses.
4
Restrict network access to the cluster port regardless. Defense in depth, not a substitute for patching.
Tomcat clustering runs over a separate network port — most single-server deployments never turn it on, and this bug only matters to those that do. · Unsplash
This is at least the fourth "the patch didn't fully patch it" story we've covered in a matter of weeks. N-able's N-central shipped a fix that attackers found a way around within weeks. Cisco's firewall management platform had its own static-credential mess. Rails' Active Storage flaw and JetBrains TeamCity's unauthenticated RCE both fit the same shape. Read together, it's less "one vendor screwed up" and more a pattern: complex, security-focused code paths are exactly where a rushed fix reintroduces the same class of bug it was meant to close.
Quick answers
Is CVE-2026-34486 being exploited outside of this one campaign?
As of this writing, the Unit 42-documented case is the confirmed public example. CISA's KEV addition means at least one real-world exploitation was verified — treat "known exploited" as a floor, not the full picture, since KEV entries lag actual attacker activity.
Do I need Tomcat clustering enabled for this to matter?
Yes. EncryptInterceptor only exists on the cluster communication channel. If you run a standalone Tomcat instance with clustering off, CVE-2026-34486 isn't reachable — though upgrading is still worth doing on general principle.
Does upgrading to the April patch (11.0.19/10.1.53/9.0.116) protect me?
No — that's the exact version the new bug bypasses. You need 11.0.21, 10.1.54, or 9.0.117 specifically.
Is this the same kind of bug as Log4Shell?
Not directly. This is a cryptographic bypass on cluster messaging, not a deserialization-of-untrusted-input bug on its own — though the padding-oracle flaw it stems from can be chained toward forged serialized payloads.
8/ 10
Verdict
Patch priority
If you run Tomcat with clustering enabled anywhere on the open internet, this goes to the top of today's list — not because the CVSS score is dramatic (7.5 isn't a 10), but because it's confirmed under active, AI-assisted exploitation and CISA's own deadline is tomorrow.
Best for: Anyone running Apache Tomcat 9, 10, or 11 with clustering enabled
The bigger story here isn't really Tomcat. "AI-powered hacking" stopped being a hypothetical sometime in the last few months, and the first documented cases look exactly like this — not a superintelligent zero-day machine, but a competent-enough model doing the boring parts of reconnaissance and exploitation faster than a person would bother to. Expect the CVSS-7.5-but-actively-exploited pattern to get more common, not less, as more of these frameworks get built.
