CVE-2025-49125 is a high-severity authentication bypass vulnerability affecting multiple recent versions of Apache Tomcat, a widely used open-source Java Servlet container and web server. The vulnerability arises when PreResources or PostResources are mounted at locations other than the root of a web application. In such configurations, it is possible for an attacker to access these resources via an alternate, unexpected path. This alternate path is typically not guarded by the same security constraints as the intended resource path, effectively allowing an attacker to bypass authentication controls. The issue affects Apache Tomcat versions from 11.0.0-M1 through 11.0.7, 10.1.0-M1 through 10.1.41, and 9.0.0-M1 through 9.0.105, with older end-of-life versions potentially also vulnerable. The vulnerability is classified under CWE-288, which pertains to authentication bypass using alternate paths or channels. The CVSS v3.1 base score is 7.5, indicating a high severity, with an attack vector of network (AV:N), low attack complexity (AC:L), no privileges required (PR:N), no user interaction needed (UI:N), unchanged scope (S:U), high impact on confidentiality (C:H), and no impact on integrity or availability (I:N/A:N). No known exploits are currently reported in the wild. The issue was addressed in Apache Tomcat versions 11.0.8, 10.1.42, and 9.0.106, and users are strongly advised to upgrade to these or later versions to mitigate the risk. This vulnerability can allow unauthorized access to sensitive resources, potentially exposing confidential data without requiring authentication or user interaction, making it a significant risk for web applications relying on Tomcat for secure resource delivery.

For European organizations, the impact of CVE-2025-49125 can be substantial, especially for those relying on Apache Tomcat to host critical web applications, including internal portals, customer-facing services, and APIs. The authentication bypass can lead to unauthorized disclosure of sensitive information, violating data protection regulations such as the GDPR, which mandates strict controls over personal and sensitive data. Confidentiality breaches could result in regulatory fines, reputational damage, and loss of customer trust. Since the vulnerability does not affect integrity or availability directly, the primary risk is unauthorized data exposure. However, attackers gaining unauthorized access could use this foothold for further lateral movement or reconnaissance within the network. The ease of exploitation (no privileges or user interaction required) increases the likelihood of automated scanning and exploitation attempts, raising the urgency for mitigation. Organizations in sectors with high regulatory scrutiny, such as finance, healthcare, and government, are particularly at risk. Additionally, given the widespread use of Apache Tomcat in European enterprises and public sector infrastructure, the vulnerability presents a broad attack surface.

1. Immediate upgrade of Apache Tomcat instances to the fixed versions: 11.0.8, 10.1.42, or 9.0.106, depending on the version in use. This is the most effective and recommended mitigation. 2. Review and audit the configuration of PreResources and PostResources in web applications to ensure they are mounted at the root or properly secured paths, minimizing the risk of alternate path access. 3. Implement strict access control policies at the web server and application level, including the use of web application firewalls (WAFs) configured to detect and block suspicious path traversal or alternate path access attempts. 4. Conduct thorough security testing and code review of web applications to identify any reliance on insecure resource mounting that could be exploited. 5. Monitor logs for unusual access patterns or attempts to access resources via unexpected paths, enabling early detection of exploitation attempts. 6. Employ network segmentation and least privilege principles to limit the exposure of Tomcat servers to only necessary internal or external networks. 7. Ensure that sensitive resources are protected by multiple layers of security controls beyond Tomcat’s built-in constraints, such as authentication gateways or API management solutions.