CVE-2026-43515

What it actually does

This vulnerability is an improper authorization issue in Apache Tomcat’s handling of servlet security constraints when multiple method constraints define the same HTTP method for the same URL extension or pattern. Under affected configurations, Tomcat may apply the wrong constraint or fail to enforce the intended access control for a request method, allowing an unauthenticated remote attacker to access protected web application resources or perform actions that should require authentication or authorization. The impact is primarily loss of confidentiality and integrity for applications relying on Tomcat-enforced method-based authorization; availability impact is not indicated.

Why it matters to the business

Applications hosted on affected Apache Tomcat versions may unintentionally expose protected functions or data to unauthenticated users. Because Tomcat is widely used for Java web applications and the flaw is remotely reachable with low attack complexity and no required credentials, successful exploitation could result in unauthorized access to sensitive information, unauthorized transactions or administrative actions, compliance exposure, and loss of trust in affected services. Although this issue is not currently listed in CISA KEV and no mature public exploitation is indicated, the high CVSS severity warrants prioritized remediation, especially for internet-facing Tomcat deployments and applications that depend on web.xml or annotation-based method constraints for access control.

How an attack unfolds

An attacker first identifies a web application running on an affected Apache Tomcat version. They then enumerate accessible paths, file extensions, and HTTP methods such as GET, POST, PUT, DELETE, PATCH, or OPTIONS. If the application defines overlapping or duplicate method constraints for the same extension or URL pattern, the attacker sends requests using the method and path combination that triggers Tomcat’s improper authorization handling. Instead of enforcing the stricter intended constraint, Tomcat may allow access as though a weaker or unintended rule applied. The attacker can then read protected content, invoke restricted endpoints, or modify application state depending on what the misconfigured constraint protects. Exploitation depends on the affected application’s security-constraint configuration, so not every Tomcat deployment will be exploitable even if the server version is vulnerable.

How to fix it

Upgrade Apache Tomcat to a fixed release: 11.0.22 or later for the 11.x branch, 10.1.55 or later for the 10.1.x branch, or 9.0.118 or later for the 9.x branch. Apache lists older 8.5.x and 7.0.x lines as affected; these branches are end-of-life or not provided with a fixed version in the advisory, so migrate to a supported fixed branch rather than attempting to continue operating them. As interim mitigation, review web application security constraints for duplicate or overlapping method constraints on the same URL pattern, extension mapping, or servlet mapping; remove ambiguity; prefer deny-by-default constraints; and enforce authorization in application code or an upstream access-control layer for high-risk endpoints. Restrict internet exposure to administrative or sensitive application paths until upgrades are complete.

How to confirm the fix worked

Confirm the deployed Tomcat version is 11.0.22 or later, 10.1.55 or later, or 9.0.118 or later, depending on the branch. Validate container images, packaged distributions, embedded Tomcat dependencies, and application server bundles rather than checking only standalone installations. Review web.xml, servlet annotations, and framework-generated deployment descriptors for overlapping security-constraint and http-method/http-method-omission definitions affecting the same URL pattern or extension. Perform authorization regression testing by sending unauthenticated and low-privilege requests to protected endpoints using all supported HTTP methods and confirming consistent denial where required. For externally exposed services, run authenticated and unauthenticated dynamic application tests to verify protected resources cannot be reached through alternate methods.

Typical attack path

1. Identify a target web application hosted on Apache Tomcat.
2. Determine or infer that the Tomcat version is in an affected range.
3. Enumerate application paths, URL extensions, and supported HTTP methods.
4. Probe protected resources with different HTTP methods to find inconsistent authorization behavior.
5. Trigger the duplicate or overlapping method-constraint condition for the same extension or URL pattern.
6. Access data or functions that should require authentication or stronger authorization.
7. Use the unauthorized access to retrieve sensitive information, alter application data, or perform restricted business actions.

How to detect it

To assess possible prior exploitation, review Apache Tomcat access logs, reverse proxy logs, WAF logs, application audit logs, and identity provider logs for protected URLs that returned successful responses to unauthenticated or unexpected low-privilege requests. Focus on time windows before patching and on endpoints governed by servlet security constraints, especially URL patterns or extensions with duplicate method-specific rules. Look for method probing against the same path using GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS; transitions where the same resource returns 401 or 403 for one method but 200, 201, 204, 302, or other successful responses for another; and requests to sensitive extensions or administrative paths from unfamiliar IP addresses. Correlate successful access events with missing authenticated session identifiers, missing Authorization headers, newly created or modified records, unexpected downloads, or application audit events that lack a valid user context. There are no universally reliable file-system artifacts unique to this vulnerability; exploitation evidence is most likely to appear as abnormal HTTP method and authorization outcomes in web and application logs.

• HTTP access log entries with successful 2xx or 3xx responses to protected URLs without an authenticated session
• HTTP method probing against the same protected path using GET, POST, PUT, DELETE, PATCH, HEAD, or OPTIONS
• 401 or 403 responses followed by 200, 201, 204, or 302 responses for the same protected URL from the same source IP using a different HTTP method
• Unauthenticated requests to /manager/html returning HTTP 200 or 302
• Unauthenticated requests to /host-manager/html returning HTTP 200 or 302
• Unexpected successful PUT, DELETE, or PATCH requests to protected application paths
• Access log requests containing HTTP methods OPTIONS or TRACE against sensitive application paths
• web.xml entries containing duplicate <http-method> definitions for the same <url-pattern>
• web.xml entries containing overlapping <security-constraint> definitions for the same <url-pattern>

What your security team should do

• Inventory all Apache Tomcat deployments, including embedded Tomcat in Java applications, container images, appliances, and platform services.
• Prioritize remediation for internet-facing Tomcat instances and applications that rely on Tomcat-managed security constraints for access control.
• Upgrade affected deployments to Tomcat 11.0.22+, 10.1.55+, or 9.0.118+; migrate any 8.5.x or 7.0.x deployments to a supported fixed branch.
• Review application deployment descriptors and servlet security annotations for duplicate or overlapping method constraints on the same URL pattern or extension.
• Add regression tests that verify authorization decisions for every sensitive endpoint across GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS as applicable.
• Temporarily restrict access to sensitive or administrative endpoints with a reverse proxy, WAF, VPN, or identity-aware access layer while patching is underway.
• Monitor access logs for unusual successful requests to protected resources using uncommon HTTP methods or requests that previously returned 401/403 but later returned 200/2xx/3xx.
• Because the issue is high severity but not currently KEV-listed and has low EPSS, treat it as urgent for exposed or authorization-sensitive systems rather than as evidence of active widespread exploitation.