Published on 10 August 2026
An encryption layer that's supposed to protect actually lets attackers straight through – and it has done so ever since a patch that was meant to fix that very encryption. That's exactly what happened with the globally widespread Java web server Apache Tomcat. The security flaw CVE-2026-34486 allows attackers to execute malicious code on vulnerable servers without any credentials and take complete control. On 4 August 2026, the US cybersecurity agency CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalogue – a clear signal that the flaw is already being abused in the wild.
For small and medium-sized businesses running Tomcat – often without even knowing it, because it's embedded in many applications – there's an urgent need to act. In this article we explain what happened, who is affected, how to check whether your system is vulnerable, and what specific steps you need to take now.
Apache Tomcat is one of the most widely deployed Java web servers and so-called servlet containers – the software that runs in the background to serve Java web applications. It's embedded in countless web applications and CMS backends. According to estimates, more than 540,000 Tomcat instances worldwide are directly reachable from the internet.
The flaw CVE-2026-34486 has an official severity rating of CVSS 7.5 ("High"). Given the active exploitation, however, the real-world risk should be considered significantly higher. The problem affects the so-called EncryptInterceptor – a component that's meant to encrypt communication between multiple Tomcat servers in a group (a "cluster").
Particularly explosive: the vulnerability didn't arise from an original programming flaw, but from a faulty patch. In March 2026, the previous flaw CVE-2026-29146 was fixed. During that correction, however, a new, serious error was introduced unnoticed. Security researchers speak of a "fail-open" regression – more on that shortly.
The EncryptInterceptor is supposed to work like a bouncer: only correctly encrypted messages may pass, everything else is rejected. Experts call this secure behaviour "fail-closed" – when in doubt, the door stays shut.
The faulty patch, however, moved a single line of code to the wrong place. Specifically, the command super.messageReceived(msg); was moved from the so-called try block (the section that only runs on successful decryption) into the catch block (the error-handling section). The result: if decryption of a manipulated message fails, the error is logged – but the message is processed anyway. The bouncer notes the rule violation, but lets the attacker in regardless. That's the dangerous "fail-open" behaviour.
Security researcher Bartłomiej Dmitruk of the company Striga, which discovered the regression, describes it like this:
"The encryption layer they trusted was silently passing through every message whose decryption failed. […] An unauthenticated TCP connection leads to arbitrary command execution – via an interceptor that was supposed to discard everything it couldn't decrypt."
In practical terms, this means: an attacker with network access to the cluster communication port (by default port 4000) can inject so-called malicious serialised Java objects. Using known "gadget chains" (ready-made attack building blocks, such as ysoserial CommonsCollections6), arbitrary code can be executed with the privileges of the Tomcat process. The result is an unauthenticated remote code execution (RCE) – the ability to run commands on the server remotely and without any credentials whatsoever. That's the worst case for any server operator.
Yes – actively and on a large scale. The exploitation has already been attributed to a Chinese hacking group tracked under the names UNC5174/UNC6586, operating as part of the so-called SNOWLIGHT campaign. These attackers belong to the category of Advanced Persistent Threats (APT) – highly professional, often state-linked attacker groups.
The figures from the campaign illustrate its scale:
The SOCRadar Threat Research Unit describes the approach as highly automated:
"The campaign shows a highly opportunistic and automated 'spray-and-check' model, used by China-linked threat actors to compromise a broad range of global government and corporate infrastructure."
This "spray-and-check" model means: attackers randomly scan the internet for vulnerable systems and strike in an automated fashion. No company is too small to become a target – everything gets scanned.
Specifically affected are Tomcat versions 9.0.116, 10.1.53 and 11.0.20. These versions contain the faulty patch that introduced the flaw in the first place.
Important for SMBs: Tomcat often doesn't run as visible, standalone software, but embedded in Spring Boot or other Java applications. Many companies run CRM systems, online shops or the backends of their web apps on Tomcat without being aware of it. When in doubt, ask your IT service provider or software developers specifically about the Tomcat version in use.
Germany's Federal Office for Information Security (BSI) also warns:
"A remote, anonymous attacker can exploit multiple vulnerabilities in Apache Tomcat and Tomcat Native to disclose information and bypass security measures."
Work through the following four steps to assess your exposure:
server.xml or your cluster configuration files for the use of the EncryptInterceptor. You're only vulnerable via this vector if this component is active.catalina.out) for the error message "Failed to decrypt message", followed by "javax.crypto.AEADBadTagException" or "BadPaddingException". A frequent occurrence of these errors may indicate ongoing exploitation attempts.Given the active, automated exploitation, acting quickly is crucial. Follow these steps in this order:
EncryptInterceptor, provided the cluster communication takes place in an isolated, trusted network anyway – or switch the encryption algorithm to AES/GCM/NoPadding.A successful exploitation of this vulnerability means complete takeover of the server – and thus access to all data processed on it. Since Tomcat frequently powers CRM systems, shops or web app backends at SMBs, personal data is almost always affected.
This triggers central obligations under the General Data Protection Regulation:
The fines can be substantial: in theory up to 20 million euros or 4 per cent of global annual turnover. In practice, fines for inadequate TOMs at SMBs typically range between 10,000 and 100,000 euros – a loss that hits many small businesses hard.
CVE-2026-34486 is a case study in how a well-intentioned security patch can create a new, more dangerous flaw. An encryption layer meant to protect turned into an open gate. The facts that the flaw can be exploited without authentication, that ready-made exploits exist, and that professional attacker groups are already scanning the entire internet for vulnerable systems in an automated way make it one of the most pressing threats to Tomcat operators right now.
The good news: securing your systems is clear-cut and readily achievable. Check your Tomcat version, update immediately to 11.0.21, 10.1.54 or 9.0.117, and consistently seal off cluster port 4000 from the internet using a firewall. Talk specifically to your IT service provider – precisely because Tomcat is often invisibly embedded in other applications, many companies have no idea they could be affected. Acting now not only prevents a possible server takeover, but also a potentially expensive GDPR data breach.