Apache Tomcat EUVD-2026-66131

Exploitation requires an authenticated user (PR:L) with any role that appears as the source of a security-role-ref mapping in the deployed application's web.xml or annotation configuration. The critical precondition is the existence of a security-role-ref element where the role-name maps to a role-link granting access to higher-privileged resources - without such a mapping, no alias is created and the flaw cannot be triggered. Deployments that do not use security-role-ref elements in their descriptors are not exploitable. Authentication is required; unauthenticated exploitation is not possible per the PR:L CVSS metric. The attack is network-accessible (AV:N) and requires no user interaction (UI:N), meaning any authenticated session holder can attempt the bypass directly via HTTP. The limiting factor is the specific role mapping configuration: the severity of impact scales with what resources the aliased role can reach.

The CVSS 8.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H) characterizes this as network-exploitable by any authenticated user with no interaction required, and the assigned confidentiality impact of N warrants scrutiny: if role escalation allows access to protected resource endpoints, confidential data exposure is plausible and may be underweighted. EPSS at 0.20% and 10th percentile strongly suggests no widespread exploitation tooling exists, aligning with SSVC Exploitation: none and Automatable: no. The SSVC Technical Impact of partial appropriately reflects that exploitation scope is bounded by the specific role mapping configuration deployed - not all Tomcat instances will have security-role-ref mappings that create exploitable alias paths. Real-world risk is therefore configuration-dependent: deployments using security-role-ref extensively across privilege boundaries face meaningful exposure, while deployments not using these mappings are unaffected. The high I and A CVSS scores are credible given that role escalation could enable writes or administrative operations on protected resources. Even a mid-sized IT operation should treat this as urgent if their Tomcat deployments rely on role-separated access control enforced at the Realm level. No KEV listing and low EPSS suggest this has not yet been operationalized by threat actors, but the straightforward nature of the flaw (authenticated, low-complexity) makes it a realistic candidate for insider threat or post-compromise lateral movement.

An authenticated user with a low-privileged application role (e.g., 'viewer') that is mapped via security-role-ref to a higher-privileged deployment role (e.g., 'manager') sends HTTP requests to URL patterns protected by the 'manager' role constraint. Due to the Realm incorrectly applying the role alias, the container grants access and the user can invoke administrative endpoints, modify application data, or trigger privileged operations. No public exploit code has been identified; exploitation requires knowledge of the deployed role mapping structure.