CVE-2026-42498

What it actually does

This vulnerability can cause Apache Tomcat to disclose an HTTP authentication header during WebSocket authentication to a host that was not the intended authentication target. In affected versions, WebSocket authentication handling may carry or forward sensitive Authorization header material across an unexpected host boundary. If an attacker can cause or control the WebSocket authentication flow, redirect target, proxy path, or destination host involved in that flow, they may obtain reusable credentials or tokens. The direct impact is credential exposure with potential follow-on unauthorized access, data access, or application actions under the identity represented by the leaked header.

Why it matters to the business

Organizations running affected Apache Tomcat versions may unintentionally leak application or user authentication credentials during WebSocket authentication, creating a risk of account takeover, unauthorized application access, and data exposure. The CVSS score is high enough to prioritize remediation, but current public exploitation signals are low: EPSS is 0.006 and has been flat over 30 days, the issue is not listed in CISA KEV, and no exploit maturity is currently reported. Internet-facing systems, systems using WebSocket authentication, and applications that use bearer tokens, Basic authentication, or other reusable credentials in HTTP Authorization headers should be treated as higher priority.

How an attack unfolds

An attacker first identifies an application or service using an affected Apache Tomcat version with WebSocket functionality and authentication. The attacker then attempts to influence the WebSocket authentication exchange so that Tomcat sends an HTTP Authorization header to a host not expected to receive it, such as an attacker-controlled endpoint, malicious redirect destination, or untrusted intermediary. If successful, the attacker captures the exposed Authorization value from their server, proxy, or network logs. The attacker may then attempt to replay the captured credential or token against the legitimate application or related services, depending on the credential type, scope, expiration, and whether additional controls such as mTLS, token binding, IP restrictions, or MFA are enforced.

How to fix it

Upgrade Apache Tomcat to a fixed supported version: 11.0.22 or later, 10.1.55 or later, or 9.0.118 or later. Apache Tomcat 8.5.x and 7.0.x are affected in the listed ranges and are not included in the recommended fixed-version set in the advisory, so organizations should migrate those deployments to a supported fixed branch rather than relying on an in-place patch. If immediate upgrade is not possible, reduce exposure by disabling or restricting affected WebSocket functionality where feasible, blocking untrusted outbound WebSocket destinations from Tomcat-hosted applications, preventing redirects or cross-host authentication flows, enforcing strict allowlists for WebSocket destinations, avoiding long-lived reusable Authorization headers, rotating credentials that may have traversed WebSocket authentication flows, and placing affected services behind trusted reverse proxies with tight routing controls.

How to confirm the fix worked

Confirm the running Tomcat version is not in the affected ranges: 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, or 7.0.83 through 7.0.109. Validate using the deployed package manager, container image metadata, Tomcat startup logs, the ServerInfo utility, or the versions of Tomcat libraries present in the application image or distribution. After upgrading, perform a controlled WebSocket authentication test involving redirects or alternate hosts and verify that Authorization headers are not sent to hosts outside the expected origin or allowlist. Also verify reverse proxy, egress firewall, and application configuration prevent Tomcat-hosted components from sending authenticated WebSocket traffic to untrusted destinations.

Typical attack path

1. Identify internet-facing or reachable services running affected Apache Tomcat versions.
2. Determine whether the application uses WebSocket endpoints and HTTP authentication headers during WebSocket connection establishment.
3. Create or control a destination that can receive WebSocket authentication traffic or influence the authentication flow.
4. Trigger a WebSocket authentication attempt that causes the Authorization header to be sent to an unexpected host.
5. Capture the leaked Authorization header from web server, proxy, or packet logs on the attacker-controlled endpoint.
6. Replay or abuse the captured credential or token against the intended service or related systems.
7. Use the resulting access to read data, perform application actions, or establish persistence if the credential has sufficient privileges.

How to detect it

Look for evidence that authenticated WebSocket traffic was sent to unexpected hosts. Useful sources include Tomcat access logs, application logs, reverse proxy logs, web application firewall logs, outbound proxy logs, DNS logs, firewall or NetFlow telemetry, and packet captures where available. Focus on requests containing WebSocket upgrade behavior together with Authorization headers, especially where the Host, Origin, Referer, redirect Location, or upstream destination differs from the expected application domain. Investigate outbound connections from Java or Tomcat processes to unfamiliar domains or IP addresses shortly before or during WebSocket authentication attempts. If centralized logs capture headers, search for Authorization values appearing in logs for non-application hosts or third-party destinations. Because this vulnerability results in credential exposure rather than a distinctive payload or file artifact, detection depends heavily on environment-specific baselines and correlation of WebSocket upgrade events, authentication headers, and unexpected destinations. If suspected, treat involved credentials as compromised and rotate them.

• Upgrade: websocket
• Connection: Upgrade
• Sec-WebSocket-Key:
• Sec-WebSocket-Version:
• Sec-WebSocket-Protocol:
• Authorization: Basic
• Authorization: Bearer
• HTTP/1.1 101 Switching Protocols
• Location: ws://
• Location: wss://
• Origin: http://
• Origin: https://
• org.apache.catalina.startup.Catalina
• org.apache.tomcat.websocket

What your security team should do

• Inventory all Apache Tomcat deployments, including embedded Tomcat in application packages, containers, appliances, and developer-built services.
• Prioritize internet-facing Tomcat services and applications that use authenticated WebSocket connections.
• Upgrade to Apache Tomcat 11.0.22+, 10.1.55+, or 9.0.118+; migrate Tomcat 8.5.x and 7.0.x deployments to a supported fixed branch.
• Search logs for WebSocket upgrade requests that include Authorization headers and involve unexpected Host, Origin, proxy, or redirect destinations.
• Review outbound connections from Tomcat processes to unfamiliar hosts, especially around WebSocket authentication activity.
• Rotate potentially exposed credentials, bearer tokens, API keys, or service credentials used in WebSocket authentication flows.
• Add egress allowlisting and application-level destination validation for WebSocket clients and authenticated connection flows.
• Ensure tokens used in Authorization headers are short-lived, audience-scoped, and not reusable across unrelated hosts or services.