CVE-2026-101356: Tomcat HTTP/2 Mix-Up and Fixes

CVE-2026-101356 affects the boundary that keeps one user’s request and response separate from another’s inside Apache Tomcat. Apache describes incorrect recycling and reuse of objects during HTTP/2 processing of asynchronous servlets, with errors potentially leading to request or response mix-ups between users. The project rates the issue Important. Its Tomcat 11 security advisory identifies 11.0.22 through 11.0.26 as affected and places the fix in 11.0.27.

For an application team, the immediate question is which Tomcat process actually receives HTTP/2 traffic, which code it is running, and whether the replacement has reached every serving instance. A public website negotiating HTTP/2 does not answer those questions. Neither does a dependency update that has not been deployed.

The useful response is to connect three pieces of evidence: the runtime version, the protocol path to that runtime, and a completed rollout with application-level isolation checks. That approach also prevents an alarming but imprecise diagnosis from turning into a claim of remote code execution that the cited advisory does not establish.

CVE-2026-101356 affected and fixed versions

Use the branch-specific ranges below for upstream Apache releases. Each row links to that branch’s security advisory; do not apply one branch’s numbering to another.

Apache records September 16, 2026 as the report date and October 20 as public disclosure, under the October 12 fixed-release entries. The affected ranges are unusually useful for triage: they identify a bounded set of releases rather than every historical release in a major branch. An earlier version outside these ranges still needs a separate security review; being outside this CVE’s interval does not establish that the installation is safe. These dates and boundaries come from the branch advisories.

For distribution packages, a banner string is insufficient. A vendor can carry security changes in a package revision that does not resemble the upstream release number. Match the installed package, operating-system release, and vendor status before interpreting the table. Ubuntu’s CVE record tracks package status by release; it should be consulted for Ubuntu packages rather than replacing that evidence with a guessed upstream-to-package equivalence.

The operational recommendation is to deploy a supported release containing the fix and any later relevant security corrections. The first-fixed column identifies the minimum upstream boundary for this issue, not a promise that a specific release will remain the best deployment target indefinitely.

What the public patch actually shows

ה Tomcat 11 fix commit changes the asynchronous state machine’s error predicate. Previously, the predicate recognized the ERROR state. After the change, it also recognizes MUST_ERROR. The accompanying changelog describes a gap in asynchronous error handling and unexpected IllegalStateExceptions in some error conditions.

That is a narrow, verifiable observation about the patch. It is not a complete exploit reconstruction. The advisory establishes the HTTP/2 cross-user mix-up risk; the diff shows one condition involved in correcting asynchronous error classification. Neither alone tells an operator a universal URL, request sequence, concurrency level, or timing window that will reproduce the vulnerability in an arbitrary application.

A useful interpretation is that lifecycle transitions matter as much as the final cleanup operation. Code deciding whether an object is in an error path must account for the relevant intermediate state. Otherwise, downstream processing may make decisions using an incomplete view of that lifecycle. This interpretation explains why a small state-machine change can be security-relevant without inventing a wire-level attack.

The distinction matters during incident review. An IllegalStateException may justify a closer look at a particular deployment or time interval. It does not identify CVE-2026-101356 by itself. Applications can produce that exception for many reasons, and the patch’s changelog does not supply a unique detection signature.

Asynchronous work extends the ownership problem

In a simple mental model, a request enters the container, the application handles it, and the response completes. Asynchronous processing introduces additional transitions: application work can continue or dispatch after the original invocation has returned. The Servlet AsyncContext API exposes operations for dispatch, completion, listeners, and access to the associated request and response.

The security question is whether all work associated with one logical request has finished before its internal resources can serve another. Reuse is compatible with isolation when ownership and lifecycle state are correct. When they diverge, a resource that appears available to one path may still be relevant to another. This is a conceptual explanation of why lifecycle correctness matters, not a claim that the following diagram enumerates Tomcat’s internal call sequence.

A response can look syntactically normal and still belong to the wrong logical request. That makes purely availability-focused acceptance criteria weak. A service returning successful status codes has demonstrated that it responds; it has not demonstrated that the response is associated with the correct user, tenant, and request.

Trace HTTP/2 to the container before assigning exposure

Document the protocol on every hop. A browser may negotiate HTTP/2 with a CDN while the CDN uses HTTP/1.1 to the origin. Another deployment may use HTTP/2 between an ingress and the Java service. Some services have several routes, including private load balancers and internal clients, with different upstream settings.

These are deployment patterns to investigate, not assumptions about your environment. A screenshot of the browser’s protocol column describes the browser-facing connection. It does not reveal the upstream protocol used by a terminating intermediary. Likewise, a reverse proxy’s presence does not establish that Tomcat cannot receive HTTP/2.

Tomcat’s HTTP/2 configuration reference documents the HTTP/2 Upgrade Protocol component and its association with an HTTP/1.1 connector. Use the matching documentation for the installed branch when reviewing configuration. For embedded deployments, inspect the programmatic configuration as well as files; a standalone server.xml inventory may not describe the running service.

An exposure record should name the listener, intermediary, backend pool, workload, and owner. Include the evidence used to determine each hop’s protocol. If a route is unknown, record it as unknown and assign an owner to resolve it. Treating an unverified assumption as a negative result makes the inventory look complete while leaving the most important uncertainty hidden.

A confirmed HTTP/1.1-only path to Tomcat can change the priority of this specific HTTP/2 issue. It does not eliminate other Tomcat vulnerabilities or prove that every route shares the same restriction. Review bypass paths and alternate listeners before using that observation as a compensating-control argument.

Embedded Tomcat deserves its own inventory

Search the deployed application artifact and its resolved dependency graph, then compare that with runtime evidence. A repository may contain a fixed dependency declaration while an older image is still serving traffic. Conversely, the operating system may have an unrelated Tomcat package that the application never loads.

For a Maven application you own, a local dependency review can start with the following command. It reads the current project’s dependency graph; it does not contact or test a remote target.

./mvnw dependency:tree '-Dincludes=org.apache.tomcat.embed:*'

Use the result to identify the relevant component and version, then retain the resolved build output and application image digest. Do not close the finding from this command alone. It describes the selected project, and production may be running a different artifact. Build evidence becomes remediation evidence only when you can connect it to the deployed workload.

Where a framework manages the dependency, choose a supported framework update or an explicitly validated dependency change. A hurried override can create compatibility problems that are difficult to distinguish from security regression. Test the application behavior that depends on the container, including startup, asynchronous endpoints, authentication, response streaming, and shutdown.

An offline model of request ownership

The educational example below demonstrates stale ownership in a reusable object. It sends no network traffic, does not load Tomcat, and is not a proof of concept for exploiting CVE-2026-101356. Its purpose is to make the isolation invariant testable: work holding an old lease must not use an object after that object has been assigned to a new owner.

The deliberately unsafe path retains a reference across reuse and reads another synthetic user’s marker. The guarded path attaches a generation number to the lease and rejects the old lease. Generation tracking is one toy design technique; it is not a description of Apache’s patch or a proposed replacement for upgrading Tomcat.

from dataclasses import dataclass

@dataclass
class Slot:
    generation: int = 0
    marker: str = ""

    def assign(self, marker):
        self.generation += 1
        self.marker = marker
        return self.generation

slot = Slot()
alice_lease = slot.assign("ALICE_SYNTHETIC")
stale_reference = slot
bob_lease = slot.assign("BOB_SYNTHETIC")

# Deliberately unsafe: an old reference observes the new owner.
assert stale_reference.marker == "BOB_SYNTHETIC"

def read_with_lease(lease):
    if lease != slot.generation:
        raise RuntimeError("expired request lease")
    return slot.marker

assert read_with_lease(bob_lease) == "BOB_SYNTHETIC"
try:
    read_with_lease(alice_lease)
except RuntimeError as error:
    assert str(error) == "expired request lease"
else:
    raise AssertionError("stale lease was accepted")

print("unsafe reuse observed; stale guarded lease rejected")

A passing run demonstrates only the behavior of this model. It says nothing about whether a live Tomcat instance is affected, whether a particular request sequence can trigger the issue, or whether a deployment has been successfully patched. Keeping those conclusions separate prevents a teaching aid from becoming misleading evidence in a vulnerability ticket.

The same distinction should guide automated testing. A test can have correct assertions and still exercise the wrong component or protocol. Record what was actually executed and which boundary was observed. A negative result without that context is easy to overinterpret.

Validate isolation in an authorized staging environment

Build a bounded test around synthetic users and non-sensitive data in an environment you control. Use two accounts, separate sessions, and unique request markers. Each account should receive a different deterministic marker from a test endpoint or existing safe workflow. Have the test runner verify ownership of each returned marker, rather than merely checking for a successful response.

Define the acceptance rule before execution: a response for account A must never include account B’s marker, and vice versa. Keep caches out of the test path or record their configuration explicitly. Otherwise a cache-key problem can resemble cross-user response mixing and lead the investigation toward the wrong component.

Start with ordinary success paths to verify the test itself. Then exercise the application’s documented asynchronous completion and error behaviors under a small, approved concurrency budget. Include normal completion, controlled application errors, and timeouts where the application supports them. Do not infer a production exploit recipe from this plan; it is an application regression strategy, and the public advisory does not provide a universal trigger.

Use positive controls. Deliberately feed the assertion checker a mismatched synthetic marker in the test harness and confirm that it fails. Confirm that the runner is using separate sessions and reaches the intended backend. A test that cannot detect a known mismatch offers little assurance when every live response appears correct.

Capture the deployed version and image digest alongside the results. If a load balancer spreads requests over multiple instances, record backend identity through an approved non-sensitive mechanism. A passing test against one fixed instance cannot establish the state of the rest of the pool. Mixed deployments deserve particular attention during rolling updates and rollback rehearsals.

Interpret results without overclaiming

A marker mismatch is an isolation failure requiring investigation. It does not, by itself, establish that Tomcat caused it. Application state, session handling, caching, and test harness errors are alternative explanations. Preserve the smallest useful evidence set and reproduce with synthetic data before drawing a causal conclusion.

A clean run is useful regression evidence, but it does not prove that a timing-dependent vulnerability is absent. The stronger closure evidence combines a fixed runtime on every relevant instance with a well-described test that exercised the intended route. These forms of evidence answer different questions and should remain separate in the report.

Stop the exercise if unexpected real-user data appears, the system becomes unstable, or traffic escapes the approved environment. Preserve identifiers and timestamps through the organization’s incident process. Avoid copying personal response bodies into broad-access tickets; access-controlled evidence and a redacted description usually serve the investigation better.

Patch the running fleet and prove convergence

Choose the appropriate fixed branch, rebuild affected applications or replace standalone installations, and test compatibility before rollout. A staged deployment should establish that the application starts, accepts the intended protocols, completes asynchronous work correctly, and preserves session behavior. Keep the security change attributable by recording the old and new artifacts.

Drain and replace instances using the deployment platform’s normal controls. Do not assume that replacing files on disk updates a running Java process. The closure question is which code the serving processes now execute. Record replacement or restart evidence and confirm that old workloads are no longer receiving traffic.

Make the rollback decision explicit. A rollback that restores an affected image reopens the finding. If operational pressure requires that tradeoff, record it as a time-bounded exception with an owner and compensating controls that have actually been verified. Calling the deployment successful while retaining the vulnerable rollback target as an active fallback creates ambiguity during the next outage.

Temporary protocol restrictions may be worth considering when an immediate upgrade is blocked, but they require deployment-specific validation. Removing HTTP/2 at one edge does not establish that an internal connector or alternate route has stopped accepting it. The cited advisory does not give a universal configuration-only remediation. Treat a temporary control as a bounded risk decision, then complete the upgrade.

The HTTP/2 configuration reference documents object-recycling-related settings, but a descriptive option is not automatically an endorsed workaround for this CVE. Avoid introducing a new tuning value into production solely because its name resembles the advisory’s mechanism. Obtain branch-appropriate guidance and test operational effects before relying on configuration changes.

Investigate symptoms with correlation rather than signatures

Start from affected runtime intervals and the routes that actually used HTTP/2. Review application errors, asynchronous completion failures, request correlation records, and any reported content mismatches in those intervals. The public patch mentions unexpected IllegalStateExceptions, making those errors relevant context, but it does not make them a reliable detector for this specific CVE.

Useful telemetry links a request identifier to a synthetic or privacy-safe user identifier, backend instance, protocol, route, timestamp, and outcome. That relationship helps distinguish an application exception from an isolation concern. A spike in server errors can direct investigation; it cannot establish that one user’s response reached another.

If a user reports seeing another account’s content, preserve the original report and investigate the response path, including caches and application authorization. Avoid an immediate attribution to the most recent CVE. The incident’s scope should follow evidence about which identities, records, and instances were involved. A version finding supports the investigation but does not replace it.

The primary sources cited here establish the defect and its fixes. They do not establish a public exploitation campaign or demonstrate remote code execution. Accordingly, this article makes neither claim. If later primary evidence changes the exploitation assessment, update that assessment separately from the version and rollout records.

Do not merge neighboring Tomcat advisories

The same release can address several independent defects. CVE-2026-101296 concerns JNDIRealm credential validation with non-GSSAPI SASL mechanisms; it is not the asynchronous HTTP/2 mix-up. CVE-2026-88041 concerns HTTP/2 trailer information crossing request boundaries. The Tomcat 10 advisory entries describe these separately and give different affected ranges.

This distinction changes testing. A successful authentication test does not validate HTTP/2 request ownership, and an HTTP/2 regression does not validate a realm’s credential handling. Track each finding against its own prerequisites, remediation evidence, and acceptance criteria even when one upgrade resolves several records.

A security review can share the inventory and rollout work across those findings. It should not share an unsupported conclusion. The point of a CVE-specific ticket is to preserve the connection between the defect, the affected component, the change applied, and the evidence used to close it.

Frequently asked questions

What is CVE-2026-101356?

• It is an Apache Tomcat issue involving object recycling and reuse during HTTP/2 processing of asynchronous servlets. Apache identifies potential request or response mix-ups between users in its security advisory.

Which versions should be upgraded?

• The affected upstream intervals are 11.0.22–11.0.26, 10.1.55–10.1.60, and 9.0.118–9.0.122. Their first fixed releases are 11.0.27, 10.1.61, and 9.0.123 respectively, as listed in the branch-linked version table above. Validate distributor packages using the distributor’s own status.

Does HTTP/2 on my public website prove exposure?

• No. Establish the protocol that reaches Tomcat, including internal and alternate routes. A terminating intermediary can use a different upstream protocol from the browser-facing connection.

Is this a confirmed remote code execution vulnerability?

• The cited Apache advisory describes cross-user request and response mixing. It does not establish remote code execution, and the patch diff is not a complete exploit demonstration.

Can a scanner or one clean test close the issue?

• A version result can identify a component requiring review. A clean behavioral test covers only the tested route and conditions. Closure should include fixed runtime evidence across the serving fleet, with application isolation regression results as additional evidence.

Can we fix it by changing a recycling option?

• Do not treat a documented tuning option as CVE-specific remediation without authoritative guidance for the relevant branch. Deploy a supported fixed build and verify the running instances; evaluate temporary controls against the actual protocol paths.

What should the remediation report contain?

• Include the affected runtime inventory, branch-specific fix decision, deployed artifacts, completed instance replacement, protocol evidence, synthetic isolation results, and any remaining exceptions. Separate proof of patch deployment from conclusions about historical data exposure.

Close the ownership gap in evidence as well as code

A dependency declaration, a deployment event, and a passing test each describe a different part of the response. Connect them to the same serving workloads before closing the finding. That gives the next engineer a defensible answer to the practical question: which application instances were affected, what replaced them, and what evidence shows the intended boundary now holds?

The following video provides broader context for authorized application security testing. It is not a demonstration or detector for CVE-2026-101356.