- The Mess: Apache has released Tomcat 11.0.25, 10.1.58 and 9.0.121, fixing a batch of security vulnerabilities affecting authentication, access controls, HTTP/2, WebSockets and
RewriteValve. One of the nastier bugs, CVE-2026-68569, can cause authentication to fail open, potentially authenticating a user who does not actually exist in the configuredDataSourceRealm.
This isn’t one spectacular RCE.
It’s arguably more annoying.
Tomcat is sitting underneath Java applications that trust it to make security decisions. When those decisions go wrong, the application can become a lot less secure without the application developer changing a single line of code.
The most interesting flaw is CVE-2026-68569.
Under certain authentication configurations, including CLIENT-CERT and SPNEGO, Tomcat could authenticate a user even when that user didn’t exist in the DataSourceRealm. That’s an authentication failure in exactly the place where you really don’t want one.
Then there’s CVE-2026-65182, a security-constraint bypass caused by the way Tomcat processed overlapping path constraints.
In plain English: under a particular configuration, a request could avoid the restriction that the administrator thought was protecting it.
And Tomcat’s HTTP/2 implementation wasn’t exactly innocent either.
CVE-2026-68763 can be abused to trigger an allocation leak when HTTP/2 streams are reset, potentially leading to denial of service.
There’s also CVE-2026-65637, where strict SNI validation could be bypassed through an HTTP/2 request without an authority value. The Tomcat team explicitly notes that this was an incomplete fix for an earlier vulnerability.
So no, this isn’t just:
“Apache released a bunch of minor patches.”
Several of the bugs touch security boundaries.
- The Damage: Attackers could potentially bypass authentication or application security constraints, trigger denial of service, or manipulate how Tomcat handles requests depending on the server’s configuration.
And there’s another interesting detail.
The vulnerabilities affect multiple supported Tomcat branches.
For CVE-2026-68569, NVD lists:
- Tomcat 11.0.0-M1 through 11.0.24
- Tomcat 10.1.0-M1 through 10.1.57
- Tomcat 9.0.0.M1 through 9.0.120
- older, unsupported 8.5 and 7.x releases are also affected.
So checking only the latest Tomcat 11 installations isn’t enough.
There may be ancient Java applications quietly running Tomcat 9 somewhere in the infrastructure.
And those are exactly the systems administrators tend to forget.
The Tomcat security page lists eleven vulnerabilities fixed in 11.0.25, ranging from low-severity WebSocket and DIGEST authentication issues to important authentication, HTTP/2 and security-constraint problems.
One particularly nasty configuration issue involves RewriteValve.
CVE-2026-65927 could cause rewrite processing to restart at the wrong rule, potentially bypassing access controls.
That means an administrator can look at a rewrite configuration and believe a restriction is being applied while Tomcat processes the rules differently.
That’s the sort of bug that makes security people nervous.
- The Fix: Upgrade Tomcat to 11.0.25, 10.1.58 or 9.0.121 immediately, and retire unsupported 7.x/8.5 installations rather than trying to keep vulnerable legacy servers alive.
After upgrading, don’t stop there.
Check your authentication configuration.
Especially:
CLIENT-CERTSPNEGODataSourceRealmFORMauthenticationDIGESTauthenticationRewriteValve- HTTP/2
- WebSocket applications
Then review externally accessible applications.
The Tomcat security team specifically recommends moving to the fixed releases, and the affected versions cover a huge installed base.
And if you’re running an old Tomcat version because:
“The application is too old to upgrade.”
That’s not a security strategy.
That’s technical debt with an expiration date.
Bugstoday Opinion
This is exactly the kind of vulnerability wave that gets underestimated.
No headline “Tomcat RCE 10.0”.
No instant ransomware apocalypse.
Just authentication logic, access-control processing, HTTP/2 and a few other pieces quietly doing things they shouldn’t.
But those are the mechanisms protecting applications.
When your application server starts making the wrong security decision, you don’t need an RCE to have a serious problem.
The most worrying one here is the fail-open authentication bug.
A security system that says “this user doesn’t exist, but let’s authenticate them anyway” is having a very bad day.
Bugstoday verdict: patch Tomcat. Then check the old Tomcat servers nobody remembers installing. Those are usually the ones worth worrying about.
