[CVE-2025-49125] Apache Tomcat Pre/Post-Resource Authentication Bypass Exposes Protected Content

TL;DR
Apache Tomcat versions 9.0.0-M1 through 9.0.105, 10.1.0-M1 through 10.1.41 and 11.0.0-M1 through 11.0.7 allow unauthenticated access to files that were supposed to sit behind security constraints when those files are served through PreResources or PostResources mounted at a non-root path. A crafted request to an alternate URL sidesteps the security check entirely. Upgrading to 9.0.106, 10.1.42 or 11.0.8 closes the hole. No public exploit is available at the time of writing.

1. Summary

By taking advantage of Tomcat’s flexible resource mounting system an attacker can build a URL that reaches protected files without ever presenting credentials. Every application that relies on PreResources or PostResources to overlay static content or bundled libraries is potentially exposed.

2. Context – why PreResources and PostResources exist

Modern Java web applications often need to ship additional static files that live outside the traditional webapps/ROOT directory. Since Tomcat 8, the server has supported three overlay types inside a [Context] element:

• PreResources – files that shadow anything inside the web application
• Ordinary application resources (the familiar WEB-INF/classes et al.)
• PostResources – fallback files consulted only when a match is not found elsewhere

Developers mount those resources wherever they like, for example at /branding or /extras. The expectation is that any security constraint declared in web.xml applies to the mounted directory in the same way it applies to files shipped in the WAR.

Tomcat’s implementation tried to honour that promise but a path-handling error created a blind spot.

3. Technical Details – the alternate path that skips the Realm

During request processing Tomcat calls org.apache.catalina.webresources.StandardRoot.getResource to resolve the target file. The method scans the three resource sets in order and returns the first hit.

When a Pre or Post resource is mounted at a non-root path such as /branding, Tomcat stores the internal mapping but fails to record a second mapping that includes the application’s context path. As a result a request like:

GET /myapp/branding/logo.png HTTP/1.1

is correctly checked against security constraints attached to /branding/*.
However the same file is also reachable via

GET /branding/logo.png HTTP/1.1

because the resource resolver sees the leading slash, treats it as an application-relative path and hands the file straight to the DefaultServlet. The security pipeline never fires because Tomcat thinks the request does not target the web application at all.

If the skipped constraints normally require authentication or a role, an unauthenticated visitor gains access.

Proof-of-concept configuration

A minimal reproduction uses a plain context.xml:

<Context>
  <Resources>
    <PreResources className="org.apache.catalina.webresources.DirResourceSet"
                  base="/opt/branding"
                  webAppMount="/branding"/>
  </Resources>
</Context>

Protect everything under /branding with

<security-constraint>
  <web-resource-collection>
    <web-resource-name>Brand assets</web-resource-name>
    <url-pattern>/branding/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>admin</role-name>
  </auth-constraint>
</security-constraint>

After deployment https://example.com/myapp/branding/logo.png demands credentials, but https://example.com/branding/logo.png serves the image without challenge.

The patch adds a check that refuses resource requests not prefixed with the web application’s context when the target comes from a mounted set.

4. Impact – information disclosure chains

The immediate consequence is read-only exposure of the mounted files. At first glance that sounds tame, yet modern Java frameworks frequently place:

• JSP fragments that reveal database credentials in comments
• Configuration backups containing API keys
• Pre-compressed javascript bundles with source maps that leak internal code structure

If a backend relies on obscurity to keep endpoints secret, the alternate path can unravel that assumption. A reverse proxy fronting multiple Tomcat instances will not strip the leading slash, so the bug crosses the infrastructure boundary untouched.

5. Remediation – upgrade or remount

Tomcat maintainers released 9.0.106, 10.1.42 and 11.0.8 on 2025-06-16. Drop-in replacement is the simplest fix.

If an immediate upgrade is impossible you can:

1. Remount PreResources and PostResources at / (the root). Mounting at the root is unaffected.
2. Block requests that do not include the context path with a reverse proxy rule while you schedule the upgrade.

These workarounds buy time but they introduce operational complexity; upgrading remains the recommended approach.

6. Timeline

7. References

• Apache mailing-list advisory: https://lists.apache.org/thread/m66cytbfrty9k7dc4cg6tl1czhsnbywk
• Fix commit: https://github.com/apache/tomcat/commit/d94bd36fb7eb32e790dae0339bc249069649a637

About Volerion

Volerion delivers AI-driven enrichment minutes after a CVE goes live. A single call to our REST API returns CVSS 4.0 vectors, exploitability metrics and affected products complete with remediation. Additionally, we offer different scoring profiles, complete with insight into the eight comprehensive categories that make up the final score. Our API is also available in the tradditional NVD API 2.0 format, so integration is as simple as swapping hosts. Spend less time parsing CVEs and more time closing them.

How the Volerion Risk Score Fits With CVSS, EPSS and KEV

At the time of writing:

• CVSS 3.1 assigns 7.5 to CVE-2025-49125, highlighting high confidentiality impact with no privileges required.
• EPSS is 0.0002, indicating a very low observed likelihood of exploitation in the next 30 days.
• The vulnerability is not in CISA’s KEV catalog, so there is no federal deadline attached.

The Volerion Risk Score weighs these signals together with additional factors such as product prevalence and exploit maturity. At 6.89 this issue lands in our high-risk band even though the EPSS number is low, because Tomcat sits at the core of countless public-facing services and the exploit only needs an HTTP client.