CVE-2026-41293 Tomcat HTTP/2 Header Validation Explained

CVE-2026-41293 is an Apache Tomcat vulnerability involving insufficient validation of HTTP/2 request headers before those headers are exposed to applications through the Servlet API.

At first glance, this sounds like a relatively narrow protocol-compliance issue. In practice, it illustrates a much broader security problem: different HTTP protocol implementations must enforce equivalent security boundaries before untrusted request metadata reaches an application.

Apache describes CVE-2026-41293 as an Improper Input Validation vulnerability. The Tomcat security team states that HTTP/2 request headers were not properly validated, meaning an application could receive header values that it reasonably assumed had already satisfied HTTP specification requirements. Apache disclosed the vulnerability on May 12, 2026, after it was reported to the project on April 15, 2026. (Apache Tomcat)

The vulnerability affects supported Tomcat branches through:

Tomcat branch	Betroffene Versionen	Gepatchte Version
Tomcat 11	11.0.0-M1 through 11.0.21	11.0.22+
Tomcat 10.1	10.1.0-M1 through 10.1.54	10.1.55+
Tomcat 9	9.0.0.M1 through 9.0.117	9.0.118+

The CVE record additionally lists the now-unsupported Tomcat 10.0.0-M1 through 10.0.27 and Tomcat 8.5.0 through 8.5.100 as affected. Organizations still operating those end-of-life branches should migrate to a supported release rather than treat an old branch as safe simply because no new patch was issued for it. (CVE)

The immediate remediation is therefore straightforward: upgrade to Tomcat 11.0.22 or later, Tomcat 10.1.55 or later, or Tomcat 9.0.118 or later. (Apache Tomcat)

The more interesting question is why HTTP/2 header validation matters enough to receive its own CVE.

What Is CVE-2026-41293?

CVE-2026-41293 exists because Tomcat’s HTTP/2 processing path historically did not apply all the validation that applications could reasonably expect from an HTTP server.

A Java application frequently interacts with inbound request headers using the Servlet API:

String authorization = request.getHeader("Authorization");
String forwardedFor = request.getHeader("X-Forwarded-For");
String tenant = request.getHeader("X-Tenant-ID");
String originalUri = request.getHeader("X-Original-URI");

Application developers usually do not parse raw HTTP frames themselves. They trust the web server or application container to transform protocol-level input into a valid request representation.

That assumption is central to the vulnerability.

Apache’s advisory specifically warns that applications might reasonably assume values exposed through the Servlet API are specification compliant. With vulnerable Tomcat versions, an HTTP/2 request could violate expected header syntax yet still cross the HTTP/2 processing boundary and become visible to application logic. (Apache Tomcat)

This creates a protocol trust-boundary problem:

Internet
   ↓
HTTP/2 request
   ↓
HEADERS / CONTINUATION frames
   ↓
HPACK decoding
   ↓
Tomcat HTTP/2 implementation
   ↓
Insufficient header validation
   ↓
Servlet request
   ↓
Application assumes headers are valid
   ↓
Unexpected application behavior

The vulnerability does not automatically mean that every affected Tomcat installation can be remotely compromised.

Rather, malformed input can reach code that was written under a different security assumption.

The resulting impact therefore depends heavily on what that application does with the header.

Why HTTP/2 Headers Need Validation

HTTP/2 does not transmit headers as human-readable lines like HTTP/1.1.

A simplified HTTP/1.1 request might look like:

GET /account HTTP/1.1
Host: example.com
Authorization: Bearer token
X-Tenant-ID: 1234

HTTP/2 represents these fields inside binary protocol frames and compresses the header block using HPACK.

Conceptually:

HTTP/2 connection

HEADERS frame
    ↓
HPACK encoded header block
    ↓
HPACK decoder
    ↓
:method = GET
:path = /account
:scheme = https
:authority = example.com
authorization = Bearer token
x-tenant-id = 1234

Binary encoding does nicht eliminate the syntax rules that apply to HTTP fields.

RFC 9113 explicitly requires HTTP/2 implementations to perform minimum validation of field names and values. Among other requirements, HTTP/2 field names cannot contain uppercase ASCII letters, prohibited control characters or most other invalid characters. Normal field names also cannot contain a colon. Field values cannot contain NUL, LF or CR, and cannot begin or end with certain whitespace characters. (RFC-Editor)

That means the following conceptual fields should not simply be accepted as ordinary valid HTTP/2 fields:

X-Admin: true

The uppercase field name violates HTTP/2’s lowercase field-name requirement.

Similarly, a value containing embedded line-feed, carriage-return or NUL characters violates HTTP/2 field validity requirements.

RFC 9113 makes the security reason unusually explicit: failure to validate HTTP fields can contribute to request-smuggling attacks, particularly when a message is later translated or forwarded through an HTTP/1.1 component that interprets delimiter characters differently. (RFC-Editor)

This does not mean CVE-2026-41293 itself should automatically be described as a universal Tomcat request-smuggling vulnerability. Apache’s own fix commit specifically notes that HTTP/2 does not carry exactly the same request-smuggling concerns as HTTP/1.1. (GitHub)

The important issue is parser disagreement.

Whenever:

Component A interprets input one way
                ↓
Component B interprets the same input another way

an attacker may gain an opportunity to cross a security boundary that neither component intended to expose.

The Root Cause of the Tomcat HTTP/2 Header Validation Vulnerability

The Tomcat patch provides considerably more technical information than the short CVE description.

One of the primary commits is titled:

“Add HTTP/2 header filtering and associated tests”

The patch explicitly says that the change aligns HTTP/2 behavior with HTTP/1.1. (GitHub)

This is the core of CVE-2026-41293.

Tomcat already had reusable HTTP parsing logic in HttpParser, but the HTTP/2 and HPACK processing path needed stronger integration with that validation logic.

The fix modifies components including:

java/org/apache/coyote/http2/HPackHuffman.java
java/org/apache/coyote/http2/HpackDecoder.java
java/org/apache/coyote/http2/Http2Parser.java
java/org/apache/coyote/http2/Stream.java
java/org/apache/tomcat/util/http/parser/HttpParser.java

It also adds and updates HTTP/2-specific tests. (GitHub)

That matters because the flaw sits below normal application code.

A vulnerable request roughly travels through:

HTTP/2 HEADERS
       ↓
Compressed HPACK representation
       ↓
HpackDecoder / HPackHuffman
       ↓
Tomcat request structures
       ↓
Servlet API
       ↓
Application

Before the fix, the decoding operation could produce header strings without applying the complete validation expected at this boundary.

The patch changes that architecture.

How the Tomcat Patch Validates HTTP/2 Header Names

One particularly revealing part of the patch updates HPACK Huffman decoding.

For field names, the patched implementation performs checks conceptually equivalent to:

if (!HttpParser.isToken(c) || Character.isUpperCase(c)) {
    throw new IllegalArgumentException(...);
}

The important pieces are:

HttpParser.isToken(c)

and:

Character.isUpperCase(c)

The first establishes whether a character is valid as part of an HTTP token.

The second adds the HTTP/2-specific lowercase requirement.

This closely matches RFC 9113.

HTTP/2 field names must be lowercase, even though header names are conventionally case-insensitive at the semantic HTTP layer. (GitHub)

This distinction is easy to miss.

In HTTP/1.1:

User-Agent:
user-agent:
USER-AGENT:

have historically been treated as equivalent field names.

HTTP/2, however, requires the transmitted field name to be lowercase:

user-agent

Rejecting an uppercase field is therefore protocol validation, not merely stylistic normalization.

Header Value Validation Was Also Strengthened

The patch does not stop at field names.

It introduces validation while decoding field values, including separate handling of the beginning, middle and end of a value.

The patch uses Tomcat parsing helpers such as:

HttpParser.isFieldVChar(c)

and:

HttpParser.isFieldContent(c)

The code checks the first character, validates subsequent field content and verifies the end of the field value as well. (GitHub)

This maps to an important HTTP/2 rule.

RFC 9113 states that HTTP/2 field values must not contain:

NUL    0x00
LF     0x0a
CR     0x0d

and a field value must not begin or end with ASCII space or horizontal tab. (RFC-Editor)

Why are CR and LF so security-sensitive?

Because HTTP/1.x historically uses them as structural delimiters.

Consider an abstract value:

normal-value<CR><LF>Injected-Header: value

One component might view that sequence as a single string.

Another component might interpret the same bytes as:

Header-One: normal-value
Injected-Header: value

That difference in interpretation is one of the fundamental building blocks behind HTTP parser-confusion vulnerabilities.

Again, this does not prove that every CVE-2026-41293 deployment is directly exploitable for header injection or request smuggling. It explains why strict rejection must occur before malformed values cross protocol boundaries.

Why HPACK Does Not Make Invalid Headers Safe

An important misconception is that HTTP/2’s binary framing inherently eliminates malicious header syntax.

It does not.

HPACK is principally a compression mechanism.

A simplified pipeline is:

Header strings
     ↓
HPACK encoding
     ↓
HTTP/2 HEADERS frame
     ↓
Network
     ↓
HPACK decoding
     ↓
Header strings

HPACK can represent data that HTTP semantics subsequently prohibit.

RFC 9113 explicitly recognizes this distinction: header compression can convey characters that HTTP field syntax does not permit, so the HTTP/2 implementation itself must validate the decoded result. (RFC-Editor)

This is a useful security engineering principle:

Successful decoding is not equivalent to successful validation.

The same principle applies far beyond Tomcat.

Zum Beispiel:

Base64 decode ≠ trusted input
JSON parse ≠ trusted object
URL decode ≠ safe path
JWT decode ≠ authenticated identity
HPACK decode ≠ valid HTTP header

A parser proves that data can be represented according to an encoding.

A validator establishes whether the resulting data is allowed in the security context where it will be used.

CVE-2026-41293 resulted from those responsibilities not being sufficiently aligned in Tomcat’s HTTP/2 path.

The Servlet API Trust Boundary

The security significance becomes clearer when looking at modern Java applications.

Applications routinely make security decisions from request headers.

Zum Beispiel:

String role = request.getHeader("X-User-Role");

if ("admin".equals(role)) {
    allowAdministrativeFunction();
}

A more realistic deployment might have:

Internet
   ↓
CDN
   ↓
WAF
   ↓
Load Balancer
   ↓
Reverse Proxy
   ↓
Tomcat
   ↓
Spring / Servlet application

Headers can control:

• authentication context
• client identity
• original IP attribution
• virtual-host routing
• tenant selection
• Genehmigung
• redirect behavior
• proxy behavior
• cache behavior
• request signing
• logging
• tracing
• internal API routing

Common examples include:

Authorization
Host
Forwarded
X-Forwarded-For
X-Forwarded-Host
X-Forwarded-Proto
X-Original-URL
X-Rewrite-URL
X-User
X-Role
X-Tenant-ID
X-Internal-Request

Applications often assume that by the time these values reach:

request.getHeader(...)

basic HTTP syntax has already been enforced.

That is precisely the assumption mentioned in Apache’s advisory. (Openwall)

If the container accepts a value outside the expected grammar, application-specific consequences become possible.

What Could CVE-2026-41293 Actually Cause?

The official Apache wording is deliberately cautious:

malformed HTTP/2 headers may trigger unexpected application behavior.

That wording is important.

CVE-2026-41293 should not be represented as a guaranteed remote-code-execution vulnerability.

Its direct primitive is closer to:

Attacker-controlled HTTP/2 request
              ↓
Non-compliant header field
              ↓
Insufficient validation
              ↓
Header exposed through Servlet API
              ↓
Application consumes unexpected input

Everything after that point depends on the application.

Possible classes of downstream behavior could theoretically include:

Application behavior	Potential consequence
Header used in authorization	authorization inconsistency
Header used for proxy routing	routing confusion
Header copied into another protocol	parser disagreement
Header included in logs	log corruption or misleading records
Header forwarded to HTTP/1.1	HTTP interpretation differences
Header used in cache key	cache inconsistency
Header parsed using custom delimiter logic	application logic bypass
Header incorporated into another response	secondary injection behavior

These should be treated as application-dependent possibilities, not automatic properties of CVE-2026-41293.

This distinction becomes especially important because some vulnerability databases currently portray the issue much more severely than Apache itself.

Why Does Apache Call CVE-2026-41293 Low Severity While Other Databases Show 9.8 Critical?

CVE-2026-41293 has one of the more striking severity disagreements among recent Tomcat vulnerabilities.

Apache Tomcat’s own security pages classify the vulnerability as:

Niedrig

The Apache announcement also explicitly labels the severity as Low. (Mail Archive)

At the same time, GitHub Advisory Database and GitLab’s advisory database currently display a CVSS v3.1 score of:

9.8 Critical

with a vector corresponding to network-accessible, unauthenticated compromise with high confidentiality, integrity and availability impact. (GitHub)

Those two descriptions should not be casually blended together.

A 9.8 CVSS vector implies something much stronger than the impact described by Apache’s security team.

Apache’s description does nicht state that sending an invalid HTTP/2 header directly provides:

Remote code execution
Authentication bypass
Full confidentiality compromise
Full integrity compromise
Full availability compromise

Instead, it says the invalid header might produce unexpected application behavior when an application assumes specification compliance.

That is a conditional impact.

A defensible security assessment should therefore preserve both pieces of information:

Quelle	Severity representation
Apache Tomcat security team	Niedrig
Apache security announcement	Niedrig
GitHub Advisory Database	9.8 Critical
GitLab Advisory Database	9.8 Critical

Apache is also the software vendor and CNA responsible for the vulnerability disclosure, which makes its description particularly important when determining the vulnerability’s actual primitive.

The appropriate operational conclusion is not to ignore the issue because Apache says Low.

Nor is it appropriate to claim that every vulnerable Tomcat server is trivially exploitable for unauthenticated RCE because a third-party database displays 9.8.

The correct response is:

patch the vulnerable container and separately analyze how your applications use HTTP headers.

Is CVE-2026-41293 an HTTP Request Smuggling Vulnerability?

Not exactly, at least based on the official disclosure.

RFC 9113 explicitly warns that failure to validate fields can enable request-smuggling attacks, especially when HTTP/2 messages are translated into HTTP/1.1. (RFC-Editor)

This makes request smuggling highly relevant to understanding why the validation requirement exists.

However, the Tomcat patch itself contains an important observation: the maintainers note that HTTP/2 does not have the same request-smuggling concerns that exist with HTTP/1.1. (GitHub)

That means CVE-2026-41293 should not simply be renamed:

Apache Tomcat HTTP/2 Request Smuggling RCE

without evidence supporting that exploit chain.

The more precise relationship is:

CVE-2026-41293
        ↓
Invalid HTTP/2 fields can cross validation boundary
        ↓
Potential parser/application disagreement
        ↓
Specific architecture determines resulting impact

If another component later serializes, transforms or forwards that malformed header differently, a more serious secondary vulnerability could emerge.

That would require analysis of the complete request path.

HTTP/2 Connection-Specific Headers Matter Too

HTTP/2 also changes the semantics of several headers that developers associate with HTTP/1.1.

RFC 9113 prohibits HTTP/2 messages from carrying connection-specific fields including:

connection
proxy-connection
keep-alive
transfer-encoding
upgrade

Die TE field is a narrow exception but may only contain trailers in an HTTP/2 request. (RFC-Editor)

This is another example of why HTTP/2 cannot simply be treated as “HTTP/1.1 transported differently.”

Protocol semantics differ.

Security testing therefore needs to examine both:

HTTP/1.1 parsing

and:

HTTP/2 parsing

instead of assuming that successful validation of one guarantees equivalent behavior in the other.

Pseudo-Headers Add Another HTTP/2 Parsing Layer

HTTP/2 uses pseudo-header fields such as:

:method
:scheme
:authority
:path

These replace information that would otherwise appear in portions of the HTTP/1.1 request line or Gastgeber Kopfzeile.

RFC 9113 defines strict rules around them.

Pseudo-headers must appear before normal fields, may not be duplicated improperly, must be valid for their context and must satisfy protocol-specific requirements. (RFC-Editor)

A typical request might conceptually contain:

:method: GET
:scheme: https
:authority: application.example
:path: /api/users

accept: application/json
authorization: Bearer ...

The security lesson is broader than CVE-2026-41293.

Modern HTTP attacks increasingly emerge from inconsistent transformations across:

HTTP/2 pseudo-headers
        ↓
HTTP request representation
        ↓
HTTP/1.1 translation
        ↓
Reverse proxy metadata
        ↓
Framework request APIs

A security boundary therefore exists at every translation step.

How to Determine Whether Your Tomcat Server Is Affected

Start with the installed Tomcat version.

For a traditional deployment:

$CATALINA_HOME/bin/version.sh

On Windows:

%CATALINA_HOME%\bin\version.bat

You may see output similar to:

Server version: Apache Tomcat/10.1.x
Server built:   ...
JVM Version:    ...
OS Name:        ...

Then compare the version with the official ranges.

For supported branches:

11.0.21 or earlier → affected
11.0.22+           → fixed

10.1.54 or earlier → affected
10.1.55+           → fixed

9.0.117 or earlier → affected
9.0.118+           → fixed

Apache confirms these patched releases in its Tomcat security advisories. (Apache Tomcat)

For Spring Boot or embedded Tomcat deployments, checking the operating system’s Tomcat package may not be enough.

The vulnerable component may be bundled inside the application.

For Maven:

mvn dependency:tree | grep tomcat

For Gradle:

./gradlew dependencies | grep tomcat

Relevant Maven components include packages such as:

org.apache.tomcat.embed:tomcat-embed-core
org.apache.tomcat:tomcat
org.apache.tomcat:tomcat-catalina

GitHub’s advisory tracks affected and fixed versions for these Tomcat Maven artifacts as well. (GitHub)

Check Whether HTTP/2 Is Actually Reachable

Exposure also matters.

A vulnerable Tomcat installation is most directly relevant when untrusted clients can reach its HTTP/2 processing path.

From an authorized environment, you can inspect protocol negotiation using:

curl -I --http2 https://example.com/

Verbose mode provides more context:

curl -v --http2 https://example.com/

Look for negotiated HTTP/2 behavior.

However, do not assume that observing HTTP/2 externally proves that Tomcat itself receives HTTP/2.

A deployment may look like:

Client
  │ HTTP/2
  ▼
Cloud Load Balancer
  │ HTTP/1.1
  ▼
Nginx
  │ HTTP/1.1
  ▼
Tomcat

In this architecture, the public endpoint supports HTTP/2 while Tomcat might never process an HTTP/2 frame.

Another architecture could be:

Client
  │ HTTP/2
  ▼
Tomcat

or:

Client
  │ HTTP/2
  ▼
Reverse proxy
  │ HTTP/2
  ▼
Tomcat

These have different exposure characteristics.

Therefore, inventory should document protocol negotiation at every hop.

Reverse Proxies Do Not Automatically Make the Vulnerability Irrelevant

It may be tempting to conclude:

We have Nginx or a cloud load balancer in front of Tomcat, therefore CVE-2026-41293 does not matter.

That is too simplistic.

Die richtige Frage lautet:

Which component terminates HTTP/2, and what representation does it send downstream?

Consider three models.

Architecture A: HTTP/2 Terminates Before Tomcat

Internet
   ↓ HTTP/2
Reverse Proxy
   ↓ HTTP/1.1
Tomcat

Tomcat’s vulnerable HTTP/2 parser might not be reachable from the public client.

This can significantly reduce direct exposure.

Architecture B: HTTP/2 Is Passed to Tomcat

Internet
   ↓ HTTP/2
Load Balancer
   ↓ HTTP/2
Tomcat

Tomcat continues to process HTTP/2 request headers and therefore remains directly relevant.

Architecture C: Tomcat Is Directly Exposed

Internet
   ↓
Tomcat HTTP/2 connector

This creates the clearest direct exposure.

Even in Architecture A, upgrading remains preferable because network architectures change, internal traffic may bypass the public proxy, and relying on an intermediary as a permanent compensating control leaves vulnerable software deployed.

How Security Teams Should Validate CVE-2026-41293

Testing this issue should focus on protocol behavior rather than blindly running an exploit script.

A safe validation workflow is:

1. Identify Tomcat version
       ↓
2. Determine HTTP/2 configuration
       ↓
3. Map every HTTP termination point
       ↓
4. Identify where HTTP/2 becomes HTTP/1.1
       ↓
5. Inventory security-sensitive headers
       ↓
6. Upgrade Tomcat
       ↓
7. Verify malformed fields are rejected
       ↓
8. Regression-test application behavior

Security teams should pay particular attention to applications that consume headers controlling:

authentication
authorization
tenant selection
routing
client IP
redirects
cache keys
privileged internal access

For example, search Java code for:

getHeader(
getHeaders(
getHeaderNames(

and then determine whether any of those values enter security-sensitive operations.

An application pattern such as:

String trustedUser = request.getHeader("X-Authenticated-User");

deserves more attention than:

String browser = request.getHeader("User-Agent");

because the consequence of unexpected input is fundamentally different.

Why Application-Layer Validation Is Still Important

Fixing Tomcat should be the primary response.

But CVE-2026-41293 also highlights an architectural principle: security-sensitive application fields should still receive semantic validation.

Suppose a tenant header should contain only an integer identifier.

Instead of:

String tenantId = request.getHeader("X-Tenant-ID");
loadTenant(tenantId);

the application should apply its own expected grammar:

String tenantId = request.getHeader("X-Tenant-ID");

if (tenantId == null || !tenantId.matches("[0-9]{1,12}")) {
    throw new IllegalArgumentException("Invalid tenant ID");
}

Tomcat’s job is to ensure the input is valid HTTP.

The application’s job is to ensure the input is valid for the application.

These are different layers:

Protocol validation
        ↓
HTTP semantics
        ↓
Application syntax validation
        ↓
Authorization and business logic

Defensive systems become substantially stronger when every layer validates the assumptions it actually owns.

Do WAF Rules Fix CVE-2026-41293?

A WAF may reduce exposure, but it should not replace upgrading.

A WAF sits at a different layer and may itself:

• terminate HTTP/2
• normalize headers
• decode HPACK
• translate HTTP/2 into HTTP/1.1
• remove malformed fields
• reject suspicious protocol behavior

That can make exploitation harder.

But it also introduces another parser.

A modern request path may contain:

Client parser assumptions
        ↓
CDN HTTP/2 parser
        ↓
WAF parser
        ↓
Load balancer parser
        ↓
Reverse proxy parser
        ↓
Tomcat HTTP/2 parser
        ↓
Servlet framework

Security vulnerabilities frequently appear precisely because two of these components disagree.

For CVE-2026-41293, the definitive remediation is therefore to eliminate the known weak parser behavior rather than depend indefinitely on an upstream parser hiding it.

Recommended Remediation

For Tomcat 11:

Upgrade to Apache Tomcat 11.0.22 or later

For Tomcat 10.1:

Upgrade to Apache Tomcat 10.1.55 or later

For Tomcat 9:

Upgrade to Apache Tomcat 9.0.118 or later

These are the versions recommended by Apache. (Apache Tomcat)

Tomcat 10.0 and 8.5 are end-of-life branches appearing in the affected CVE record. Organizations using them should migrate to a currently supported Tomcat release. (CVE)

After upgrading, teams should also:

1. restart every affected Tomcat instance;
2. verify the running version rather than only the installed package;
3. inspect embedded Tomcat dependencies in packaged Java applications;
4. rebuild container images rather than patching only the host;
5. verify old application replicas have been terminated;
6. inspect internal as well as Internet-facing Tomcat services;
7. regression-test reverse proxies and API gateways;
8. test security-sensitive header handling.

This is particularly important in Kubernetes environments.

Updating:

FROM ...

or a Maven version does nothing to pods that are still executing an old artifact.

The effective remediation chain is:

dependency update
      ↓
application rebuild
      ↓
container rebuild
      ↓
registry update
      ↓
deployment rollout
      ↓
old replica removal
      ↓
runtime verification

How to Prioritize CVE-2026-41293

The unusual severity disagreement means organizations should prioritize based on context instead of copying a scanner’s numerical score.

A useful model is:

Zustand	Priorität
Patched Tomcat	No longer vulnerable to this CVE
Vulnerable Tomcat with HTTP/2 disabled/unreachable	Lower immediate exposure
Internet-accessible vulnerable Tomcat with HTTP/2	Patch promptly
HTTP/2 Tomcat plus security-sensitive custom headers	Higher investigation priority
Tomcat behind multiple HTTP translation layers	Investigate parser consistency
Unsupported Tomcat 8.5/10.0	Migration strongly recommended
Headers used directly for authorization or internal trust	Highest application-review priority

Apache’s Low rating is important, but it should not be interpreted as permission to postpone routine patching indefinitely.

Conversely, the 9.8 rating shown by several vulnerability databases should not be used as evidence that an unauthenticated attacker automatically gains code execution.

The exploitability of the underlying primitive is architecture dependent. (Mail Archive)

Is CVE-2026-41293 Being Actively Exploited?

As of August 28, 2026, authoritative evidence of widespread in-the-wild exploitation is not apparent from the sources reviewed for this article. Rapid7’s current CVE entry reports that CVE-2026-41293 is not in the CISA Known Exploited Vulnerabilities catalog.

That should not be confused with proof that exploitation is impossible.

Public vulnerability databases and repositories may contain proof-of-concept material, scanner checks or experimental demonstrations. Those are different from verified real-world exploitation campaigns.

For defenders, the distinction is:

Vulnerability exists        → confirmed
Official patch exists       → confirmed
Public technical interest   → yes
CISA KEV listing            → no, based on current checked data
Widespread active attacks   → not established by authoritative evidence reviewed

Since fixed Tomcat releases have been available since May 2026, leaving an affected Internet-facing deployment unpatched provides little operational benefit.

The Broader Lesson: HTTP/2 Security Is About Interpretation

CVE-2026-41293 is valuable beyond the individual Tomcat bug because it demonstrates a recurring pattern in modern web infrastructure.

Security engineers often think about an HTTP request as one object:

Anfrage

Operationally, the same request may be reconstructed repeatedly:

HTTP/2 bytes
   ↓
frames
   ↓
HPACK fields
   ↓
proxy request object
   ↓
HTTP/1.1 serialization
   ↓
another parser
   ↓
framework request
   ↓
application object

Each conversion creates an opportunity for semantic disagreement.

This is the foundation behind many classes of vulnerabilities involving:

• HTTP request smuggling
• HTTP/2 downgrade attacks
• ambiguous Content-Length
• Transfer-Encoding inconsistencies
• host-routing attacks
• cache poisoning
• proxy authentication bypass
• path normalization discrepancies
• header normalization bugs

The best defense is not simply adding more filtering.

It is making parsing rules deterministic at every trust boundary.

CVE-2026-41293 Detection Checklist

Security teams assessing Tomcat environments can use the following sequence.

Siehe	What to determine
Tomcat version	Is it inside an affected range?
Embedded Tomcat	Does a Java application bundle a vulnerable version?
HTTP/2 configuration	Can Tomcat itself process HTTP/2?
External exposure	Can untrusted clients reach that listener?
Reverse proxies	Where is HTTP/2 terminated or downgraded?
Security headers	Which request headers influence trust decisions?
Custom parsing	Does application code parse header delimiters itself?
Forwarding	Are incoming headers forwarded to another service?
Patch state	Is runtime actually 11.0.22+, 10.1.55+, or 9.0.118+?
Regression testing	Are malformed HTTP/2 fields rejected after remediation?

The most valuable investigation is not merely asking:

“Does our scanner report CVE-2026-41293?”

Instead ask:

“Can attacker-controlled non-compliant HTTP/2 header data reach a security-sensitive application component in our architecture?”

That question exposes the actual risk.

CVE-2026-41293 FAQ

What is CVE-2026-41293?

CVE-2026-41293 is an Improper Input Validation vulnerability in Apache Tomcat where HTTP/2 request headers were not sufficiently validated before being exposed to applications through the Servlet API. (CVE)

Which Apache Tomcat versions are affected?

The supported affected branches are Tomcat 11.0.0-M1 through 11.0.21, Tomcat 10.1.0-M1 through 10.1.54, and Tomcat 9.0.0.M1 through 9.0.117. The CVE record also identifies unsupported Tomcat 10.0 and 8.5 releases as affected. (CVE)

Which versions fix CVE-2026-41293?

Upgrade to Tomcat 11.0.22 or later, Tomcat 10.1.55 or later, or Tomcat 9.0.118 or later. (Apache Tomcat)

Is CVE-2026-41293 critical?

Apache rates the issue Low. Some vulnerability databases currently display a CVSS 3.1 score of 9.8 Critical. This is an important scoring disagreement, and Apache’s actual description does not establish universal unauthenticated RCE. (Mail Archive)

Is CVE-2026-41293 a remote code execution vulnerability?

Apache does not describe it as a direct RCE vulnerability. The documented primitive is insufficient validation of HTTP/2 headers, potentially resulting in unexpected application behavior.

Is authentication required?

The underlying parsing behavior occurs while Tomcat processes an HTTP/2 request, before normal application-level authentication necessarily becomes relevant. However, actual security impact depends on what the application subsequently does with the malformed header.

Does disabling HTTP/2 mitigate the vulnerability?

Preventing untrusted HTTP/2 requests from reaching Tomcat can reduce the direct attack surface because the affected functionality is Tomcat’s HTTP/2 request-header processing path. It should be treated as a temporary exposure-reduction measure, not a substitute for installing the fixed release.

Does a reverse proxy fix it?

Not inherently. A reverse proxy may terminate and normalize HTTP/2 before traffic reaches Tomcat, reducing exposure, but the result depends on the exact protocol architecture. Upgrading Tomcat remains the preferred remediation.

Final Assessment

CVE-2026-41293 is best understood as a protocol validation boundary failure, rather than simply another generic Tomcat CVE.

HTTP/2 sends fields through binary frames and HPACK compression, but those fields are still subject to strict HTTP syntax requirements. Tomcat’s vulnerable HTTP/2 implementation did not consistently enforce that boundary before request headers became available through the Servlet API.

The Apache patch makes the security model clearer. HTTP/2 header decoding now performs stronger field-name and field-value checks, including token validation, rejection of uppercase field-name characters, and checks against invalid field-value content. The changes intentionally bring HTTP/2 behavior closer to the validation already expected from Tomcat’s HTTP/1.1 processing. (GitHub)

RFC 9113 explains why this matters: malformed fields can become security-relevant whenever HTTP implementations, intermediaries or applications interpret the same data differently. (RFC-Editor)

For defenders, however, there is an equally important distinction to preserve. Apache rates CVE-2026-41293 as Low and describes its direct consequence as unexpected application behavior. Although several downstream vulnerability databases currently display a 9.8 Critical score, there is insufficient basis in the official advisory to treat every affected Tomcat instance as an unauthenticated RCE target. (Mail Archive)

The practical response is uncomplicated: upgrade Tomcat 11 to 11.0.22 or later, Tomcat 10.1 to 10.1.55 or later, and Tomcat 9 to 9.0.118 or later. Teams running Tomcat 8.5 or 10.0 should migrate away from those unsupported branches. Then inspect applications where request headers influence authentication, authorization, routing, tenancy or other trust decisions. (CVE)

CVE-2026-41293 ultimately demonstrates a rule that applies to every modern web stack:

A request is only as trustworthy as the most permissive parser it crosses.

For the official technical details, see the Apache Tomcat 11 security advisory, Apache Tomcat 10 security advisorydie official CVE record, and the HTTP/2 field-validation requirements in RFC 9113.