CVE-2026-42498: Apache Tomcat Information Disclosure Flaw

CVE-2026-42498 Overview

CVE-2026-42498 is an information disclosure vulnerability in Apache Tomcat. The flaw exposes the HTTP Authorization header to unexpected hosts during WebSocket authentication. When Tomcat's WebSocket client follows redirects, it can forward authentication credentials to hosts other than the originally requested target, leaking sensitive credentials to third parties.

The issue affects Apache Tomcat 11.0.0-M1 through 11.0.21, 10.1.0-M1 through 10.1.54, 9.0.2 through 9.0.117, 8.5.24 through 8.5.100, and 7.0.83 through 7.0.109. Fixed versions are 11.0.22, 10.1.55, and 9.0.118. The 8.5.x and 7.0.x branches have reached end of life.

Critical Impact

WebSocket clients in vulnerable Tomcat versions can leak HTTP authentication credentials to unintended hosts, enabling credential theft and downstream account compromise.

Affected Products

• Apache Tomcat 11.0.0-M1 through 11.0.21
• Apache Tomcat 10.1.0-M1 through 10.1.54
• Apache Tomcat 9.0.2 through 9.0.117
• Apache Tomcat 8.5.24 through 8.5.100 and 7.0.83 through 7.0.109 (end-of-life branches)

Discovery Timeline

• 2026-05-12 - CVE-2026-42498 published to NVD
• 2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-42498

Vulnerability Analysis

The vulnerability resides in the Apache Tomcat WebSocket client implementation. When establishing a WebSocket connection that requires HTTP authentication, the client constructs an Authorization header for the target host. If the server responds with an HTTP redirect, the client follows that redirect and reattaches the Authorization header — even when the redirect points to a different host.

The Common Weakness Enumeration classifies this as Exposure of Sensitive Information to an Unauthorized Actor [CWE-200]. Credentials intended for one server are transmitted to an attacker-controlled or otherwise untrusted host. The exposed material can include HTTP Basic credentials, bearer tokens, or other secrets carried in the Authorization header.

Exploitation has network attack vector characteristics and does not require authentication or user interaction. Confidentiality, integrity, and availability impacts are rated low because the leak is limited to credentials present in the WebSocket handshake.

Root Cause

The root cause is missing host validation during redirect handling in the WebSocket client. The client retains and replays the Authorization header across the redirect chain rather than stripping it when the redirect target differs from the original host. This breaks the implicit trust boundary tied to the host the credentials were issued for.

Attack Vector

An attacker who controls a server reachable by a Tomcat WebSocket client, or who can manipulate DNS or network routing to a target server, can return an HTTP redirect pointing to a host they control. The Tomcat WebSocket client then connects to the attacker's host and presents the original Authorization header. The attacker captures the credential and replays it against the legitimate service.

The vulnerability is exploitable whenever applications running on Tomcat use the WebSocket client API to connect to remote endpoints that may issue redirects. Server-side WebSocket endpoints are not affected by this specific flaw.

No public proof-of-concept code is currently available. See the Apache Mailing List Thread for the official technical description.

Detection Methods for CVE-2026-42498

Indicators of Compromise

• Outbound WebSocket connections from Tomcat application servers to unexpected external hosts following an HTTP 3xx redirect
• HTTP requests containing Authorization headers sent to domains outside the application's documented integration list
• Application logs showing redirect chains in WebSocket handshake exchanges that cross host boundaries

Detection Strategies

• Inventory all Tomcat instances and compare installed versions against the fixed releases (11.0.22, 10.1.55, 9.0.118)
• Audit application code for use of jakarta.websocket.ContainerProvider or javax.websocket.ContainerProvider client APIs that connect to remote endpoints
• Inspect egress proxy logs for WebSocket upgrade requests carrying Authorization headers destined for hosts outside an allowlist

Monitoring Recommendations

• Capture and analyze TLS-inspected egress traffic from Java application servers for cross-host credential replay during WebSocket handshakes
• Alert on HTTP 301, 302, 307, and 308 responses received by Tomcat-based WebSocket clients
• Rotate any credentials known to have been used in WebSocket client flows on vulnerable Tomcat builds after patching

How to Mitigate CVE-2026-42498

Immediate Actions Required

• Upgrade Apache Tomcat to 11.0.22, 10.1.55, or 9.0.118 as soon as feasible
• Migrate workloads off the 8.5.x and 7.0.x branches, which are end of life and will not receive fixes
• Rotate credentials used by WebSocket clients running on vulnerable Tomcat versions if exposure is suspected

Patch Information

The Apache Tomcat project addressed the issue in versions 11.0.22, 10.1.55, and 9.0.118. The fix prevents the WebSocket client from forwarding the Authorization header across redirects that target a different host. Release details are available in the Apache Mailing List Thread and the OpenWall OSS Security Update.

Workarounds

• Restrict outbound network access from Tomcat servers to an allowlist of trusted WebSocket endpoints
• Avoid following redirects in custom WebSocket client code, or strip the Authorization header before reissuing requests to a new host
• Use short-lived tokens rather than long-lived credentials in Authorization headers for WebSocket flows

# Verify installed Apache Tomcat version
$CATALINA_HOME/bin/version.sh | grep "Server number"

# Example egress allowlist enforcement (iptables, restrict to trusted host)
iptables -A OUTPUT -p tcp -m owner --uid-owner tomcat -d trusted-ws.example.com --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp -m owner --uid-owner tomcat -j REJECT