CVE-2026-25854

What it actually does

Apache Tomcat contains an open redirect weakness in the LoadBalancerDrainingValve. When this valve is enabled and Tomcat is draining traffic behind a load balancer, crafted requests can cause Tomcat to redirect a user to an attacker-controlled URL instead of a trusted application location. The issue is remotely reachable, requires no authentication, and depends on user interaction because the victim must follow or be induced to interact with the crafted link. The primary technical risks are phishing enablement, abuse of trusted Tomcat-hosted domains in redirect chains, and potential leakage of limited information such as URL parameters, referrer data, or tokens if applications place sensitive values in redirects or query strings.

Why it matters to the business

An attacker can abuse a trusted application URL to send users to a malicious site, making phishing, credential theft, and fraud attempts more convincing. The flaw does not directly allow server takeover or data modification, but it can damage user trust, increase help desk and incident response workload, and create compliance concerns if sensitive links or authentication flows are exposed. Because Apache Tomcat is widely deployed as a Java application server, organizations should treat exposure seriously where affected versions are internet-facing or where the LoadBalancerDrainingValve is configured.

How an attack unfolds

An attacker first identifies an Apache Tomcat instance running an affected version and determines whether the LoadBalancerDrainingValve behavior is reachable. They then craft a URL to the legitimate Tomcat-hosted domain that causes the draining valve redirect logic to point to an untrusted external destination. The attacker sends that URL to a victim through email, chat, ads, support messages, or another social-engineering channel. If the victim clicks the link, the browser initially contacts the trusted Tomcat site and then receives a redirect to the attacker-controlled site. The attacker can use the destination page to collect credentials, prompt malicious downloads, continue an OAuth or SSO phishing flow, or impersonate the original service. There is no current indication from the provided data that this issue is in CISA KEV, associated with ransomware campaigns, or has mature public exploitation, and the EPSS score is low, but exploitation remains plausible because open redirects are easy to weaponize for phishing once a vulnerable redirect pattern is known.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.20 or later for the 11.x line, 10.1.53 or later for the 10.1.x line, or 9.0.116 or later for the 9.x line. Apache Tomcat 8.5.x is affected through 8.5.100 and is no longer a recommended maintained target for this fix path; migrate to a supported fixed Tomcat branch. If immediate upgrade is not possible, review whether LoadBalancerDrainingValve is configured and disable it where not required. As a compensating control, restrict allowed redirect targets at the reverse proxy, load balancer, or application layer; block absolute external redirect values where possible; and add user-facing anti-phishing protections for links that leave trusted domains. Avoid placing secrets, authentication codes, session identifiers, or sensitive business data in URLs, because open redirects can expose them through redirects, browser history, or referrer behavior.

How to confirm the fix worked

Confirm the deployed Tomcat version reports 11.0.20 or later, 10.1.53 or later, or 9.0.116 or later. Review Tomcat configuration for LoadBalancerDrainingValve usage in server.xml, context.xml, application-specific context configuration, or packaged configuration overlays. In a controlled test environment, attempt previously known redirect proof-of-concept patterns and verify the server no longer emits a 3xx Location header pointing to an untrusted external domain. Validate at the edge by confirming reverse proxies or load balancers reject or normalize external redirect destinations. For internet-facing services, run authenticated and unauthenticated web scanning focused on open redirects and manually inspect any finding where a trusted URL produces a Location header with an attacker-controlled scheme or hostname.

Typical attack path

1. Discover a publicly reachable Apache Tomcat service running an affected version.
2. Probe for LoadBalancerDrainingValve redirect behavior and identify a crafted URL pattern that redirects externally.
3. Register or prepare an attacker-controlled destination domain that imitates the legitimate service or captures user input.
4. Send the crafted trusted-domain URL to target users through phishing, messaging, malicious ads, or embedded links.
5. Victim opens the URL and is redirected from the legitimate Tomcat-hosted site to the attacker-controlled site.
6. Attacker harvests credentials, session-related information exposed in URLs, or persuades the victim to perform a harmful action.

How to detect it

To determine whether this was already abused, examine HTTP access logs from Tomcat, reverse proxies, WAFs, CDN logs, and load balancers for requests that returned 301, 302, 303, 307, or 308 responses with a Location header pointing to an external domain. Correlate those events with user-agent, referrer, source IP, and request URI patterns that appear in email campaigns, chat messages, or unusual spikes in short-lived visits. Review application and Tomcat logs around times when the LoadBalancerDrainingValve was active or when nodes were marked draining. Investigate redirect chains where the first hop is a trusted Tomcat-hosted URL and the next hop is a newly registered, lookalike, punycode, URL-shortener, file-sharing, or credential-harvesting domain. If phishing was suspected, correlate affected users with identity-provider sign-in logs, MFA prompts, password reset events, impossible travel alerts, and endpoint telemetry for downloads initiated immediately after the redirect. Because no universal exploit string is derivable from the public description, detections should focus on external Location headers, anomalous redirect destinations, and requests to applications using LoadBalancerDrainingValve.

• LoadBalancerDrainingValve
• Location: http://
• Location: https://
• HTTP/1.1 301
• HTTP/1.1 302
• HTTP/1.1 303
• HTTP/1.1 307
• HTTP/1.1 308

What your security team should do

• Inventory Apache Tomcat deployments and prioritize internet-facing systems and systems involved in authentication, SSO, account management, or user onboarding flows.
• Upgrade affected Tomcat branches to 11.0.20+, 10.1.53+, or 9.0.116+; migrate any remaining 8.5.x deployments to a supported fixed branch.
• Search configurations for LoadBalancerDrainingValve and disable it unless there is a documented operational need.
• Add or tighten allow-list validation for redirect destinations at application, reverse proxy, and load balancer layers.
• Review recent web access logs for suspicious 3xx responses that redirect users to external domains, especially following inbound links from email or messaging campaigns.
• Educate phishing response teams that links beginning with a legitimate Tomcat-hosted domain may still redirect to attacker-controlled infrastructure.
• Avoid transmitting sensitive tokens or credentials in URL parameters across applications hosted on or behind Tomcat.