CVE-2026-55276
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Apache Tomcat is an open-source web server and servlet container, maintained by the Apache Software Foundation, that implements the Jakarta Servlet, Jakarta Pages (JSP), Jakarta Expression Language, and Jakarta WebSocket specifications and provides a pure-Java HTTP environment for running Java web applications.
An information exposure vulnerability CVE-2026-55276 has been identified in Apache Tomcat, which causes the effective web.xml that Tomcat writes to its logs when logEffectiveWebXml="true" to omit parts of a web application's security configuration. The special wildcard roles * and **, and empty deny-all <auth-constraint/> blocks, are dropped from the logged output, so the recorded diagnostic copy understates the access-control rules that are actually configured. This is a logging-fidelity defect only and does not affect runtime authorization: Tomcat continues to enforce the complete, in-memory security constraints, and the incomplete representation appears solely in the optional logged copy of the configuration.
Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.
This issue affects multiple versions of Apache Tomcat below 11.0.23.
Details
Module Info
- Product: Apache Tomcat
- Affected packages: tomcat-util-scan, tomcat-embed-core
- Affected versions: >=9.0.0.M1 <9.0.98, >=10.1.0-M1 <10.1.34, >=11.0.0-M1 <11.0.23
- GitHub repository: https://github.com/apache/tomcat
- Published packages:
- Package manager: Maven
- Fixed in:
- NES for Apache Tomcat 8.5.100-tomcat-8.5.107
- Apache Tomcat 11.0.23, 10.1.56, 9.0.119 (OSS)
Vulnerability Info
This Low-severity vulnerability is found in the tomcat-util-scan package in Apache Tomcat, in the org.apache.tomcat.util.descriptor.web.WebXml class. When a Context is configured with logEffectiveWebXml="true", Tomcat serializes the merged effective deployment descriptor via WebXml.toXml() and writes it to the log so operators can inspect the configuration in force. The routine that emits each security constraint only renders an <auth-constraint> element when the constraint carries one or more named roles:
if (constraint.findAuthRoles().length > 0) {
sb.append(" <auth-constraint>\n");
for (String role : constraint.findAuthRoles()) {
appendElement(sb, INDENT6, "role-name", role);
}
sb.append(" </auth-constraint>\n");
}
findAuthRoles() returns only the explicitly named roles. The two special wildcard roles a constraint may carry, * (all defined roles) and ** (all authenticated users), are tracked separately and are never appended, so a constraint authorized by those wildcards is logged without any <auth-constraint> element. A constraint that denies all access through an empty <auth-constraint/> (an auth-constraint with zero roles) likewise satisfies neither branch and produces no element at all. As a result, the logged effective web.xml can appear more permissive than the configuration Tomcat is actually enforcing, misleading anyone who relies on the log to audit the application's access-control rules.
Mitigation
Only recent versions of Apache Tomcat are community-supported. The community support version will not receive any updates to address this issue. For more information, see here.
Users of the affected components should apply one of the following mitigations:
- Upgrade to a patched version of Apache Tomcat.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
Credits
- Apache Tomcat security team