CVE-2025-49125

What it actually does

This is an authentication-bypass flaw in Apache Tomcat’s handling of web application resources when PreResources or PostResources are mounted at a path other than the web application root. In vulnerable versions, the same mounted resource could be reachable through an unexpected URL path that may not match the security constraints configured for the intended path. As a result, a resource that should require authentication or authorization can be served to an unauthenticated or lower-privileged requester. The impact is primarily unauthorized access to protected web application resources; it does not inherently provide remote code execution, but exposed sensitive files, application functions, or configuration data could enable follow-on compromise.

Why it matters to the business

Organizations running affected Tomcat versions may unintentionally expose protected application content or functionality to unauthenticated users. The operational risk depends on what is mounted through PreResources or PostResources: exposure could range from limited static content disclosure to leakage of sensitive business data, internal application artifacts, or access to functionality assumed to be protected. The issue is not listed in CISA KEV and has a relatively low EPSS score, but because Tomcat is widely deployed and often internet-facing, externally exposed applications should still be prioritized for review and patching.

How an attack unfolds

An attacker first identifies an application served by an affected Apache Tomcat version and looks for URL structures that suggest additional resources are mounted into the web application through PreResources or PostResources. If those resources are mounted below a non-root path and the application relies on security constraints to protect the expected URL, the attacker probes alternate URL paths that Tomcat may resolve to the same underlying resource. When a matching alternate path is found, the request bypasses the security rule that would normally apply to the expected path, allowing the attacker to retrieve the resource or interact with it without the intended authentication or authorization checks. Named exploitation context was provided for MadeYouReset, but no mature public exploit or CISA KEV confirmation is indicated in the supplied data; defenders should still treat suspicious unauthenticated access to protected Tomcat resource paths as potentially relevant.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.8 or later for the 11.x line, 10.1.42 or later for the 10.1.x line, and 9.0.106 or later for the 9.0.x line. Rebuild and redeploy container images, application bundles, and embedded Tomcat distributions so the runtime actually uses the fixed version. Review applications using PreResources or PostResources mounted anywhere other than the web application root and verify that all reachable URL variants are protected by equivalent security constraints. As a temporary mitigation where immediate upgrade is not possible, restrict external access to affected applications, add reverse-proxy or WAF rules for known unintended alternate paths once identified, and avoid relying on a single expected URL pattern to protect mounted resources. Vendor/package fixed versions provided in the input should also be consumed where applicable, including apache/tomcat fixed in commit 05ccf0c3e22d388f0cf853e32485d8249d051f2f and the listed Mageia package updates: kdebase4-runtime 4.12.5-1.2.mga4, kdebase4-runtime 4.10.5-1.2.mga3, kwebkitpart 1.3.2-1.1.mga3, and kwebkitpart 1.3.2-3.1.mga4.

How to confirm the fix worked

Confirm the deployed Tomcat version from runtime banners, package inventory, container image manifests, build files, or startup logs and verify it is at least 11.0.8, 10.1.42, or 9.0.106 depending on the branch in use. Do not rely only on source repository updates; validate the running process and deployed artifact. Review each web application’s context configuration for PreResources and PostResources mounted outside the root path, then test both the intended protected path and possible alternate resolved paths while unauthenticated. A successful fix should return the same authorization decision for all equivalent paths, such as 401, 403, or a redirect to login, rather than serving the resource through an alternate path. Regression tests should be added for mounted resource paths and security-constraint coverage.

Typical attack path

1. Identify internet-facing or reachable applications running vulnerable Apache Tomcat versions.
2. Fingerprint the application structure and look for mounted resources, static assets, or paths that appear protected under normal routing.
3. Probe alternate URL paths that may resolve to the same PreResources or PostResources content but do not match the configured security constraint.
4. Request protected resources without credentials or with a low-privileged session.
5. Use any exposed content, metadata, configuration, or application functionality for data theft, account targeting, or additional exploitation.

How to detect it

To determine whether this was already exploited, review web server, reverse proxy, load balancer, WAF, and Tomcat access logs for unauthenticated or low-privileged requests that returned successful responses for resources normally requiring authentication. Focus on applications with PreResources or PostResources configured outside the web application root, and compare requests to the expected protected path against requests for unusual path variants, duplicate path segments, encoded characters, normalization edge cases, or unexpected prefixes that resolve to the same content. Useful log fields include source IP, authenticated username or session identifier, request URI, status code, response size, referrer, user agent, and upstream application route. Investigate 200/206/304 responses where the same resource is later or normally accessed only after login, especially if there is no associated authenticated session. Correlate suspicious access with application logs showing missing principals, anonymous sessions, authorization-filter bypasses, or unusual static-resource serving. If suspicious access is found, preserve the relevant access logs, application logs, deployed context configuration, web.xml security constraints, and the exact vulnerable application artifact for scoping. There are no universal exploit strings because the alternate path depends on each application’s resource configuration.

What your security team should do

• Inventory all Apache Tomcat deployments, including embedded Tomcat in vendor applications, containers, CI-built application images, and developer-managed services.
• Prioritize patching internet-facing Tomcat applications and any application that uses PreResources or PostResources mounted below a non-root path.
• Upgrade to Tomcat 11.0.8, 10.1.42, or 9.0.106 or later, then redeploy and restart affected services.
• Review web.xml and context resource configuration to ensure authorization controls cover every reachable path to mounted resources.
• Search historical access logs for unauthenticated 200 responses to paths that should require authentication, especially around mounted resource locations.
• If exploitation is suspected, determine exactly what resources were exposed and assess whether credentials, tokens, configuration files, proprietary code, or sensitive records were accessed.
• Add automated security tests that verify protected resources cannot be reached through alternate paths.
• Monitor threat intelligence for any change in exploit maturity, including public proof-of-concept availability or confirmed exploitation activity associated with MadeYouReset or other campaigns.