Tomcat 11.0.26 fixes HTTP/2 regression that can attach headers to the wrong request

What happened

Apache shipped Tomcat 11.0.26 on 15 September 2026, and the release's security page carries an Important-rated entry for CVE-2026-86350, a flaw in HTTP/2 request handling. According to a write-up on dev.to, the issue became public on 23 September 2026, when the Tomcat security team moved the report from its private list into the public advisory; the original report had been filed on 28 August 2026.

The defining detail is that this is a regression rather than a brand-new defect. The flaw arrived with the patch for CVE-2026-41293, an earlier HTTP/2 handling bug, and survived through the 11.0.22 to 11.0.25 releases before being corrected.

How the bug works

The code introduced by that earlier fix parses HTTP/2 requests along a path that behaves differently from the rest of the connector. Because of that divergence, header fields belonging to one request can end up recorded against another request on the same connection — one that may belong to a different client.

The dev.to article spells out two practical consequences. Cached or proxied responses can be handed to the wrong client, and any security decision that derives from headers — routing rules, rate limiting and the like — can be evaluated against the wrong request.

On severity, Tomcat labels the issue Important and published no CVSS vector. A roundup on securityonline.info, cited by dev.to, scores it 9.1 under CWE-444, but that figure comes from the aggregator rather than the vendor. The advisory ships no proof-of-concept code, and no exploitation in the wild has been confirmed in the sources reviewed.

Affected versions and exposure

Three maintained branches are affected:

• 11.0.22 to 11.0.25
• 10.1.55 to 10.1.59
• 9.0.118 to 9.0.121

Tomcat 8.5 has no entry for this CVE.

Installations that terminate HTTP/2 directly on the Tomcat connector are the ones in scope. Deployments that keep HTTP/2 switched off, or that terminate TLS and HTTP/2 at an upstream proxy, carry a smaller practical surface.

For context, the dev.to report notes that a ZoomEye query for Apache Tomcat returns 580,597 internet-facing assets, while a query scoped to this CVE returns zero matches. The product-level count therefore says nothing about how many of those hosts are actually running an affected build.

Remediation

The fix is to move to 11.0.26, 10.1.60 or 9.0.122 on whichever branch is in use. The upstream commits are 192bc749 for 11.0.x, 259e938d for 10.1.x and 5adadc4e for 9.0.x.

Two practical cautions come with the upgrade. First, verify the build actually running in production rather than trusting a package name, because container images and distribution backports tend to lag the upstream release. Second, where an upgrade has to wait for a maintenance window, check whether HTTP/2 is enabled on the connector and consider disabling it in the meantime. Reviewing HTTP/2 access logs for unexpected header patterns, and hardening header validation at an upstream proxy, are suggested as secondary controls.

Why it matters

Header cross-talk between requests sharing an HTTP/2 connection breaks an assumption that almost no application code ever questions: that the headers on a request belong to that request. A request that arrives carrying someone else's session token, forwarding address or API key can silently poison cache layers, skew rate limiting or misroute traffic, with nothing in the logs obviously pointing at the cause.

The regression angle matters too. Teams that upgraded quickly to fix CVE-2026-41293 are exactly the ones exposed here, a reminder that security patches themselves need verifying and not just installing. The remediation is straightforward, but confirming the running build — especially in containerised deployments — is the step most likely to be skipped.