Apache Tomcat CVE-2026-65182

Exploitation requires a specific web.xml configuration: a <security-constraint> for a longer URL path must be declared BEFORE a more restrictive <security-constraint> for a shorter sub-path of that path, causing Tomcat to apply the broader rule to the sub-path. If an application does not use overlapping security constraints in this vulnerable ordering, it is not exploitable regardless of Tomcat version. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms that where the vulnerable constraint ordering exists, no authentication or user interaction is needed and the protected resource can be reached remotely; the primary limiting factor is therefore this non-default, per-application constraint arrangement rather than platform or privilege requirements.

The signals are somewhat divergent and should be weighed together. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:N) yields a 9.1 Critical, reflecting an unauthenticated, low-complexity, network-reachable authorization bypass with high confidentiality and integrity impact but no availability effect. Against that, EPSS is only 0.23% (13th percentile), there is no CISA KEV listing, and no public exploit is identified - so this is not evidence of active or imminent mass exploitation. The key limiting factor is configuration dependence: exploitation requires an application whose web.xml orders a longer-path constraint before a more restrictive shorter-sub-path constraint, so many deployments will not be exposed at all. The realistic read is a high-severity-but-conditional issue: any operator running an affected version with the vulnerable constraint ordering should treat it as urgent and patch, while low EPSS suggests widespread opportunistic exploitation is not currently occurring.

An attacker enumerates a Tomcat-hosted application and requests a protected shorter sub-path (for example an admin or API endpoint) whose restrictive security constraint is shadowed by an earlier, broader constraint on a longer path. Because Tomcat applies the wrong constraint, the request is served without the required authentication or role, giving the attacker access to resources or functionality that should have been denied. No public proof-of-concept is currently identified, but exploitation requires only crafted HTTP requests and no user interaction.