Someone left a 'this way to the exit' sign on your lobby door, and it points to a dark alley
CVE-2023-41080 is an open redirect vulnerability in Apache Tomcat's FORM authentication handler. When the ROOT (default) web application is configured to use FORM-based authentication, an attacker can craft a URL that, after the user authenticates, redirects them to an attacker-controlled site. Affected versions span Tomcat 9.0.0-M1 through 9.0.79, with the fix shipped in 9.0.80 (released 2023-08-25). The same flaw affects Tomcat 8.5.0–8.5.92, 10.1.0-M1–10.0.12, and 11.0.0-M1–11.0.0-M10.
Apache rated this Moderate and NVD assigned CVSS 3.0 base 6.1 — and even that feels generous. This is an open redirect, not code execution, not data exfiltration, not auth bypass. The attacker gains nothing on the server; they merely abuse the server's reputation to lend credibility to a phishing link. The victim must click a crafted URL *and* authenticate before the redirect fires. Tenable's own VPR scored it 2.3 (Low), which is far more honest. The MEDIUM label overstates the operational risk.
4 steps from start to impact.
Precondition: ROOT webapp uses FORM auth
<login-config><auth-method>FORM</auth-method></login-config>. Many production deployments either remove or replace the ROOT webapp entirely, or use a reverse proxy that handles auth upstream. Without this exact configuration, the redirect does not trigger.- Tomcat ROOT webapp deployed and accessible
- FORM authentication configured on the ROOT webapp
- Most enterprise Tomcat deployments deploy apps under context paths, not ROOT
- Reverse proxies (nginx, Apache httpd, F5) often front Tomcat and handle auth, making the FORM handler unreachable
- Hardened installs remove default webapps per CIS Tomcat Benchmark
Attacker crafts malicious redirect URL
- Knowledge of the target Tomcat URL
- Attacker-controlled destination domain
- URL must pass email/browser phishing filters to reach the victim
- Modern browsers may warn on cross-domain redirects depending on configuration
Victim clicks link and authenticates
- Victim interaction — must click link
- Victim must have valid credentials and enter them
- Victim must not notice the post-auth redirect to a foreign domain
- Requires social engineering to get the click
- Security-aware users notice domain changes after login
- MFA on the Tomcat app does not prevent the redirect but slows the chain and increases user scrutiny
Post-redirect phishing opportunity
- Attacker has a convincing phishing page hosted
- Victim has already authenticated to the real site — reduced motivation to re-enter credentials on the phishing page
- Browser URL bar shows the attacker domain, alerting observant users
The supporting signals.
| In-the-wild exploitation | No evidence. Not listed in CISA KEV. No campaigns or threat actor usage reported. No GreyNoise tags observed. |
|---|---|
| Proof-of-concept | Public PoC exists — simple crafted URL demonstrating the redirect. No weaponized tooling; this is a URL construction, not an exploit binary. |
| EPSS score | ~6.05% probability of exploitation in 30 days (93rd percentile). Elevated for an open redirect due to Tomcat's popularity, but still reflects low direct impact. |
| CISA KEV status | Not listed as of 2026-09-16. |
| CVSS 3.0 vector | CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N — Network-accessible, no privileges, but requires user interaction. Scope changed (redirect crosses origin). Low confidentiality and integrity impact, zero availability impact. |
| Tenable VPR | 2.3 (Low) — Tenable's own risk-based score already disagrees with CVSS and rates this well below MEDIUM. |
| Affected versions (Tomcat 9) | 9.0.0-M1 through 9.0.79 |
| Fixed version (Tomcat 9) | 9.0.80 (released 2023-08-25). Also fixed in 8.5.93, 10.1.13, 11.0.0-M11. |
| Disclosure timeline | Reported 2023-08-17, public disclosure 2023-08-22, fix released 2023-08-25. |
| Researcher / reporter | Reported to the Apache Tomcat security team. No named individual researcher prominently credited. |
noisgate verdict.
The single most decisive factor is that this is an open redirect — the server itself is never compromised, no data is accessed, and no code is executed; the entire impact is lending domain reputation to a phishing link, which requires victim interaction and social engineering to exploit. Even Tenable's own VPR of 2.3 confirms this is operationally low-risk.
Why this verdict
- Impact ceiling is phishing, not compromise: Open redirects do not give the attacker any access to the server, any data, or any persistence. The entire value is making a phishing URL look slightly more legitimate. This caps the real-world severity well below what CVSS 6.1 implies.
- User interaction required: The victim must click a crafted link, authenticate on the real server, and then fail to notice a domain change. Each step compounds the friction and reduces the probability of successful exploitation.
- Configuration-dependent: Only affects the ROOT webapp with FORM authentication — a specific deployment pattern. CIS Tomcat Benchmark and most enterprise hardening guides recommend removing default webapps, further narrowing the exposed population.
- Role multiplier: Tomcat serves as an application tier in most deployments (typical role). Even if Tomcat sits behind a CI/CD pipeline or hosts a business-critical app, an open redirect does not escalate to host, domain, or fleet compromise. The blast radius is *user-level phishing*, not *server-level breach*. No high-value role changes the impact ceiling for this vulnerability class — an open redirect on a hypervisor management UI or a CI/CD server is still just an open redirect. The floor does not apply.
- VPR confirms downgrade: Tenable's own Vulnerability Priority Rating of 2.3 (Low) — which incorporates threat intelligence, exploit maturity, and real-world risk — already agrees this is overrated at MEDIUM.
Why not higher?
An open redirect cannot escalate to remote code execution, privilege escalation, or data exfiltration regardless of the deployment context. There is no CISA KEV listing, no observed exploitation campaigns, and the blast radius is limited to social engineering amplification. Even on Tomcat instances fronting critical applications, the server itself is not compromised — only the user's browser is redirected. MEDIUM or higher would overstate the risk.
Why not lower?
While the VPR of 2.3 might justify an IGNORE verdict, the EPSS 93rd percentile suggests *some* attacker interest, and public PoC code exists. Open redirects are routinely used in phishing chains and can bypass URL reputation filters that whitelist the trusted domain. For organizations with large user populations authenticating against Tomcat-hosted apps, this has non-zero phishing risk that warrants tracking, even if it doesn't warrant urgent action.
What to do — in priority order.
- Remove or replace the ROOT default web application — If the ROOT webapp is not needed (and in most enterprise deployments it isn't), undeploy it entirely. This eliminates the vulnerability without patching. Do this as standard hardening — no specific SLA pressure given the LOW verdict.
- Front Tomcat with a reverse proxy that handles authentication — If authentication is handled by nginx, Apache httpd, or an identity provider (SAML/OIDC) before requests reach Tomcat, the FORM auth redirect path is never exposed. This is already standard in most enterprise architectures.
- Deploy URL rewriting rules to validate redirect targets — If you must use FORM auth on the ROOT webapp, add a Valve or filter that validates the redirect URL against an allowlist of trusted domains. This blocks the open redirect without upgrading Tomcat.
- WAF open-redirect rules — generic WAF signatures for open redirects may not catch this because the redirect occurs *after* authentication, not in the initial request. The malicious URL passes through as a normal login flow.
- MFA on Tomcat — MFA does not prevent the redirect. The user authenticates successfully (including MFA), and *then* gets redirected. MFA protects the account, not the redirect chain.
Crowdsourced verification payload.
Run this on each Tomcat host or from an auditor workstation with HTTP access to the Tomcat instance. No special privileges needed — it checks the Tomcat version via the server header or the RELEASE-NOTES file. Example: bash check_cve_2023_41080.sh https://tomcat.example.com:8443
#!/usr/bin/env bash
# check_cve_2023_41080.sh — Detect CVE-2023-41080 (Tomcat open redirect)
# Usage: bash check_cve_2023_41080.sh <TOMCAT_BASE_URL>
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN
set -euo pipefail
URL="${1:?Usage: $0 <TOMCAT_BASE_URL>}"
# Try to get version from Server header
VERSION=$(curl -sk -o /dev/null -D - "$URL" 2>/dev/null \
| grep -i '^server:' \
| grep -oP 'Apache-Coyote/[0-9.]+|Tomcat/[0-9.]+' \
| grep -oP '[0-9]+\.[0-9]+\.[0-9]+' \
| head -1)
if [[ -z "$VERSION" ]]; then
# Try RELEASE-NOTES if accessible
VERSION=$(curl -sk "$URL/RELEASE-NOTES" 2>/dev/null \
| grep -oP 'Apache Tomcat Version [0-9.]+' \
| grep -oP '[0-9]+\.[0-9]+\.[0-9]+' \
| head -1)
fi
if [[ -z "$VERSION" ]]; then
echo "UNKNOWN — could not determine Tomcat version from $URL"
exit 2
fi
echo "Detected Tomcat version: $VERSION"
# Parse major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"
# Vulnerable: 9.0.0 through 9.0.79
if [[ "$MAJOR" -eq 9 && "$MINOR" -eq 0 && "$PATCH" -le 79 ]]; then
echo "VULNERABLE — Tomcat $VERSION is affected by CVE-2023-41080 (fixed in 9.0.80)"
exit 0
# Also check 8.5.x: 8.5.0 through 8.5.92
elif [[ "$MAJOR" -eq 8 && "$MINOR" -eq 5 && "$PATCH" -le 92 ]]; then
echo "VULNERABLE — Tomcat $VERSION is affected by CVE-2023-41080 (fixed in 8.5.93)"
exit 0
else
echo "PATCHED — Tomcat $VERSION is not affected by CVE-2023-41080"
exit 1
fiIf you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.