CVE-2023-41080: Apache Tomcat Open Redirect in FORM Authentication

CVE-2023-41080 is an open redirect vulnerability in Apache Tomcat: when the ROOT (default) web application is configured to use FORM authentication, a specially crafted URL can cause Tomcat to redirect a user to an attacker-chosen destination. Apache rated it moderate severity, and the fix is a straightforward upgrade — but the conditions are specific enough that it is worth confirming whether you are actually exposed before you panic-patch.

Open redirects are often dismissed as low-impact, and in isolation the CVSS reflects that. The practical danger is as a building block: a redirect from a domain your users trust makes phishing and OAuth-flow abuse far more convincing.

The exact condition

This is not a blanket Tomcat flaw. Three things have to line up:

1. You are running an affected Tomcat version.
2. The ROOT web application — the one mapped to the default context path / — is involved.
3. That application is configured to use FORM authentication.

When those hold, a crafted URL processed during the FORM authentication flow can produce a redirect (an HTTP 302 with a Location header) pointing to a URL the attacker controls, rather than staying within your application. The user's browser follows it, landing on the attacker's site while the address bar history shows they came from your trusted domain.

If your ROOT application does not use FORM authentication, or authentication is handled by a non-ROOT context, this specific CVE does not apply to you. That said, the safe move is still to run a patched Tomcat.

Affected and fixed versions

The vulnerable ranges are:

• Tomcat 11.0.0-M1 through 11.0.0-M10
• Tomcat 10.1.0-M1 through 10.1.12
• Tomcat 9.0.0-M1 through 9.0.79
• Tomcat 8.5.0 through 8.5.92

Older, end-of-life versions may also be affected but will not receive fixes. The patched releases are:

• Tomcat 11.0.0-M11 or later
• Tomcat 10.1.13 or later
• Tomcat 9.0.80 or later
• Tomcat 8.5.93 or later

Confirm what you run:

# From CATALINA_HOME
./bin/version.sh
# or
java -cp lib/catalina.jar org.apache.catalina.util.ServerInfo

The fix

Upgrade to a patched Tomcat release for your line. That is the complete remediation — there is no configuration knob that fully closes it on an unpatched version. If you deploy Tomcat as an embedded dependency (Spring Boot's spring-boot-starter-tomcat, for example), the version is pinned transitively by your framework:

# See the embedded Tomcat version Spring Boot resolves
mvn dependency:tree -Dincludes=org.apache.tomcat.embed:tomcat-embed-core

For embedded Tomcat, upgrade Spring Boot to a release that bundles a patched Tomcat, or override the tomcat.version property in your build if you cannot move the whole framework yet:

<properties>
  <tomcat.version>9.0.80</tomcat.version>
</properties>

Interim mitigation and defense in depth

If you genuinely cannot upgrade immediately and you meet all three exposure conditions, you can reduce risk by placing a reverse proxy or WAF in front of Tomcat that inspects and constrains redirect targets, or by moving authentication off the ROOT context. Both are stopgaps, not fixes.

More broadly, open redirects are a design category worth engineering against regardless of any single CVE:

• Validate redirect targets against an allowlist of known-good destinations rather than reflecting a parameter.
• Prefer relative redirect paths over absolute URLs so a redirect can never leave your origin.
• On OAuth and SSO flows, strictly validate redirect_uri against registered values — open redirects are a favorite pivot for token theft.

Why an embedded Tomcat is easy to miss

The teams most likely to be caught out by CVE-2023-41080 are the ones running Spring Boot, because their Tomcat is embedded and its version is decided by the Spring Boot BOM rather than anything they set. A quick glance at the app shows no "Tomcat" anywhere obvious.

This is the standard transitive-dependency blind spot. An SCA tool resolves the embedded tomcat-embed-core version and flags it against the affected range, so you learn about exposure from a scan rather than from a security researcher. A platform such as Safeguard can also report which services in a fleet still resolve a vulnerable Tomcat after you bump Spring Boot in some repos but not others. See our dependency scanner guide for how that matching works, and if you want to catch redirect behavior at runtime, a dynamic scanner can flag open-redirect responses directly.

FAQ

How serious is CVE-2023-41080?

Apache rated it moderate severity. On its own an open redirect does not compromise data or execute code, but it is a potent phishing and OAuth-abuse enabler because it lends attacker destinations the credibility of your trusted domain. Patch it, but prioritize relative to your critical and high findings.

Am I affected if I do not use FORM authentication?

No. This CVE requires the ROOT web application to be configured for FORM authentication. If your ROOT app uses a different authentication mechanism, or none, this specific vulnerability does not apply — though running a patched Tomcat is still the right baseline.

I use Spring Boot. Does this affect me?

It can, because Spring Boot embeds Tomcat. Check the resolved tomcat-embed-core version with mvn dependency:tree. If it falls in the affected range and your app uses FORM auth on the root context, upgrade Spring Boot to a version that bundles a patched Tomcat, or override the tomcat.version property.

Is there a workaround without upgrading?

There is no complete configuration-only fix on a vulnerable version. You can reduce risk with a reverse proxy or WAF that constrains redirect targets, or by moving FORM authentication off the ROOT context, but the reliable remediation is upgrading to a patched Tomcat release.