CVE-2026-43515 - Apache Tomcat security constraints authorization bypass

CVE-2026-43515 is an Apache Tomcat authorization bypass in security constraint processing. When a web application defines multiple HTTP method constraints for the same extension pattern, affected Tomcat versions apply only the first method constraint. That can leave later method-specific protections ineffective for routes such as *.jsp, *.do, *.action, *.api, or other extension mapped endpoints.

This recipe is for code owners who control Tomcat libraries, embedded Tomcat runtimes, web.xml, Servlet security annotations, Spring Boot packaging, container images, or deployment manifests. A mergeable fix upgrades the runtime, proves that protected methods are still denied for low-privilege users, and removes ambiguous duplicate extension constraints where the application owns them.

When to use it

Use this recipe when a Java web application runs Apache Tomcat directly, embeds Tomcat through a framework, or declares Servlet security constraints in web.xml or annotations. It supports source-code remediation, route-level authorization review, method constraint consolidation, and audit evidence that protected extension-mapped endpoints deny unauthorized HTTP methods.

Inputs

  • Tomcat version, embedded runtime version, web.xml, Servlet annotations, Spring Boot packaging, reverse proxy rules, and protected route inventory.
  • Source/config paths that define extension patterns, method-specific constraints, auth roles, filters, interceptors, and deployment descriptors.
  • Regression fixtures for every protected method on affected patterns, denied anonymous users, denied wrong-role users, and allowed authorized users.
  • Boundary evidence: sensitive endpoints, admin/API routes, tenant routes, authentication mechanism, and CI/deployment artifact versions.

Affected versions

Surface Vulnerable versions Fixed versions
Apache Tomcat 11 11.0.0-M1 through 11.0.21 11.0.22+
Apache Tomcat 10.1 10.1.0-M1 through 10.1.54 10.1.55+
Apache Tomcat 9 9.0.0.M1 through 9.0.117 9.0.118+
org.apache.tomcat.embed:tomcat-embed-core <9.0.118, 10.1.0-M1 through <10.1.55, 11.0.0-M1 through <11.0.22 9.0.118+, 10.1.55+, 11.0.22+
org.apache.tomcat:tomcat / org.apache.tomcat:tomcat-catalina same affected Tomcat lines same fixed Tomcat lines

NVD also lists unsupported Tomcat 8.5.0 through 8.5.100 and 7.0.0 through 7.0.109 as affected. Do not keep those lines in service as a long-term mitigation; migrate to a supported fixed 9, 10.1, or 11 line.

Indicator-of-exposure

  • The repository resolves embedded Tomcat, Tomcat distribution images, WAR deployment images, or vendor packages below 9.0.118, 10.1.55, or 11.0.22.
  • The application uses web.xml security constraints, Servlet security annotations, generated deployment descriptors, framework-generated Tomcat constraints, or container-managed authentication.
  • Multiple constraints define HTTP method handling for the same extension pattern, for example *.jsp, *.do, *.action, *.api, *.json, or a framework extension route.
  • Protected methods such as POST, PUT, PATCH, DELETE, or OPTIONS rely on Tomcat’s constraint processing rather than application-level authorization.
  • Tests only check one method or one role and do not prove every protected method remains denied for anonymous and low-privilege users after deployment.

Quick checks:

rg -n "tomcat|tomcat-embed-core|tomcat-catalina|security-constraint|web-resource-collection|http-method|ServletSecurity|HttpMethodConstraint|\\*\\.[A-Za-z0-9_-]+" .
mvn -q dependency:tree "-Dincludes=org.apache.tomcat*:*,org.apache.tomcat.embed:*"
./gradlew dependencies --configuration runtimeClasspath

Windows:

rg -n "tomcat|tomcat-embed-core|tomcat-catalina|security-constraint|web-resource-collection|http-method|ServletSecurity|HttpMethodConstraint|\*\.[A-Za-z0-9_-]+" .
mvn -q dependency:tree "-Dincludes=org.apache.tomcat*:*,org.apache.tomcat.embed:*"
.\gradlew dependencies --configuration runtimeClasspath

Do not validate exposure by trying to bypass production authorization. Use local test fixtures and non-sensitive routes.

Remediation strategy

  • Upgrade every controlled Tomcat runtime and embedded dependency to 9.0.118+, 10.1.55+, or 11.0.22+, matching the repository’s active Servlet/Jakarta EE line.
  • Refresh lockfiles, Maven dependency management, Gradle version catalogs, BOMs, Docker base images, Helm charts, SBOMs, deployment manifests, and generated dependency reports that pin Tomcat.
  • Collapse duplicate extension-pattern method constraints into one explicit constraint block where the application owns web.xml or generated descriptor output. Prefer clear deny-by-default coverage over relying on overlapping method blocks.
  • Add route-level regression tests for every protected extension pattern and method. Anonymous and low-privilege callers must be denied before controller, filter, servlet, or business logic runs.
  • Confirm framework configuration still maps authentication, authorization, and role checks consistently after the Tomcat upgrade. This is especially important for Spring Boot, custom WAR overlays, legacy web.xml, and Servlet annotations generated by code.
  • If immediate upgrade is blocked, temporarily remove duplicate extension method constraints, deny risky methods at the gateway, or disable affected extension routes until a fixed Tomcat runtime is deployed.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-43515 / GHSA-5m62-pw8w-7w9f, an Apache Tomcat
authorization bypass where multiple HTTP method constraints for the same
extension pattern can cause only the first method constraint to apply. Produce
exactly one output:

- A reviewer-ready PR/change request that upgrades every controlled Tomcat
  runtime, removes or normalizes ambiguous extension method constraints, adds
  safe authorization regression tests, refreshes generated artifacts, and
  documents deployment/operator actions, or
- TRIAGE.md if this repository does not control an affected Tomcat runtime,
  embedded dependency, container image, deployment descriptor, or route
  authorization boundary.

## Rules

- Scope only CVE-2026-43515 and directly related Tomcat versions, embedded
  dependencies, Servlet security constraints, extension patterns, HTTP method
  authorization, generated descriptors, container images, and deployment
  artifacts.
- Treat authentication state, session cookies, bearer tokens, CSRF tokens,
  tenant IDs, private routes, admin paths, request bodies, logs, and production
  URLs as sensitive.
- Do not test by bypassing authorization on production or shared staging.
- Do not remove authentication, role checks, CSRF protection, audit logging, or
  controller tests to silence failures.
- Do not auto-merge.

## Steps

1. Inventory every Tomcat runtime controlled by this repository: Maven and
   Gradle manifests, BOMs, lockfiles, Spring Boot parent/BOM versions, WAR
   overlays, Dockerfiles, base images, compose files, Helm charts, Kubernetes
   manifests, CI images, SBOMs, deployment render output, and runbooks.
2. Resolve every Tomcat version. A target is vulnerable if it resolves to:
   - Tomcat 11 `11.0.0-M1` through `11.0.21`;
   - Tomcat 10.1 `10.1.0-M1` through `10.1.54`;
   - Tomcat 9 `9.0.0.M1` through `9.0.117`;
   - unsupported Tomcat 8.5 or 7 versions identified by scanner output;
   - embedded packages such as `org.apache.tomcat.embed:tomcat-embed-core`,
     `org.apache.tomcat:tomcat`, or `org.apache.tomcat:tomcat-catalina` in
     those ranges.
3. Inventory authorization surfaces that rely on Tomcat security constraints:
   `web.xml`, `web-fragment.xml`, generated deployment descriptors,
   `@ServletSecurity`, `@HttpConstraint`, `@HttpMethodConstraint`, Spring Boot
   Tomcat customization, reverse-proxy method filtering, and extension-mapped
   controllers or servlets.
4. Search for duplicate extension-pattern method constraints. Flag any
   extension pattern that has more than one method-specific block, especially
   for `POST`, `PUT`, `PATCH`, `DELETE`, `OPTIONS`, admin routes, upload
   routes, export routes, tenant APIs, or state-changing endpoints.
5. If this repository does not control Tomcat or the descriptor/configuration
   that defines the affected constraints, stop with `TRIAGE.md` listing files
   checked, observed versions, runtime owner, required fixed versions, and any
   temporary gateway deny rules.
6. Upgrade controlled Tomcat runtimes to `9.0.118+`, `10.1.55+`, or
   `11.0.22+` on the active line. Update Spring Boot, BOMs, dependency
   management, images, package locks, SBOMs, generated reports, and deployment
   artifacts consistently.
7. Where this repository owns affected constraints, normalize them:
   - combine duplicate extension-pattern method constraints into one clear
     block;
   - make allowed and denied methods explicit;
   - prefer deny-by-default for state-changing methods;
   - keep role names and auth schemes unchanged unless a product/security
     owner approves the change;
   - document any intentionally public extension route.
8. Add safe regression coverage with local fixtures:
   - anonymous users are denied for each protected method and extension;
   - low-privilege authenticated users are denied for admin or tenant-private
     methods;
   - allowed roles still reach intended routes;
   - denied requests fail before controller, servlet, filter side effects, or
     business logic;
   - CSRF and audit behavior still fires where applicable;
   - dependency policy rejects vulnerable Tomcat versions.
9. Add a PR body section named `CVE-2026-43515 operator actions` that states:
   - Tomcat versions before and after;
   - each duplicate extension-pattern constraint found and how it changed;
   - whether protected methods were externally reachable;
   - which gateway, WAF, or proxy containment is temporary;
   - whether sessions, auth tokens, tenant data, or admin actions need log
     review because an affected route was exposed;
   - validation commands that passed.
10. Run available validation: dependency resolution, lockfile consistency,
    unit tests, servlet/security integration tests, route authorization tests,
    CSRF tests, container build, deployment render, SBOM refresh, and
    dependency/security scans.
11. Use PR title:
    `fix(sec): remediate CVE-2026-43515 in Tomcat authorization`

## Stop conditions

- No affected Tomcat runtime, embedded dependency, image, deployment artifact,
  descriptor, Servlet annotation, or extension-mapped route is controlled by
  this repository.
- The vulnerable Tomcat runtime is owned by a platform team and cannot be
  upgraded here; document the owner and temporary route containment.
- The application intentionally depends on overlapping extension method
  constraints and no product/security owner is available to approve the new
  authorization shape.
- Safe verification would require production bypass testing, real sessions,
  tenant data, admin credentials, or sensitive route bodies.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades Tomcat, collapses or clarifies ambiguous constraints, adds route-level authorization tests, and documents deployment rollout.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, affected constraints, protected route boundary, required fix, and residual risk.
  • The output must include exact validation commands and must not probe production admin/API routes or expose credentials, cookies, or tenant data.

Verification - what the reviewer looks for

  • No controlled manifest, lockfile, BOM, image, SBOM, or deployment artifact resolves Tomcat below 9.0.118, 10.1.55, or 11.0.22.
  • Duplicate extension-pattern method constraints are removed or normalized in owned descriptors and generated outputs.
  • Tests prove anonymous and low-privilege users cannot reach every protected method for affected extension patterns.
  • Tests prove allowed roles still work, so the fix does not silently break legitimate traffic.
  • Operator notes identify any externally reachable protected methods and any temporary edge controls that must remain until deployment finishes.

Watch for

  • Upgrading tomcat-embed-core while a Spring Boot BOM, WAR base image, or container distribution still resolves an older Tomcat line.
  • Fixing only web.xml while generated descriptors, overlay WARs, Helm charts, or image layers still contain duplicate constraints.
  • Replacing Tomcat security constraints with permissive application code to make tests pass.
  • Testing only GET while the risk is method-specific protection for POST, PUT, PATCH, DELETE, or OPTIONS.
  • Treating Apache’s moderate label as proof that route-specific impact is low. GitHub and CISA-ADP score the advisory as critical when protected methods expose confidential or state-changing resources.

References