CVE-2026-55956 is an Apache Tomcat authorization bug in a place many teams do not review carefully enough: security constraints mapped to the default servlet. The flaw is not a remote code execution issue by itself. It is not proof that every Tomcat server with a public banner is exposed. It is a method-level authorization correctness issue. When security constraints were specified for Tomcat’s default servlet, an affected Tomcat version could ignore the http-method または http-method-omission part of the constraint, meaning the access-control behavior could differ from what the deployment descriptor actually said. Apache lists the issue as Moderate and says it was fixed in Apache Tomcat 11.0.23, 10.1.56, and 9.0.119.(tomcat.apache.org)
The safest way to triage CVE-2026-55956 is not to start with exploit code. Start with version, configuration, and method behavior. A host running an affected Tomcat build matters more when the application has a security constraint on the default servlet’s / mapping and that constraint depends on HTTP method selection. A host that does not use method-specific security constraints around the default servlet may still need an upgrade, but it is not the same exposure story as a Java application that used method constraints to separate public reads from restricted writes or privileged operations. NVD’s record lists the affected version ranges, recommends upgrades to 11.0.23, 10.1.56, or 9.0.119, assigns CWE-285, and includes CISA-ADP data with CVSS 3.1 score 6.5 and SSVC values of exploitation: none, automatable: yesそして technicalImpact: partial.(NVD)
CVE-2026-55956 at a glance
| フィールド | Current public information |
|---|---|
| CVE | CVE-2026-55956 |
| 製品 | Apache Tomcat |
| コンポーネント | Default servlet security constraint handling |
| 脆弱性クラス | Improper Authorization |
| CWE | CWE-285 |
| Apache severity | 中程度 |
| NVD/CISA-ADP CVSS 3.1 | 6.5, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N |
| Public disclosure | June 29, 2026 |
| Reported to Tomcat security team | June 15, 2026 |
| 修正版 | Apache Tomcat 11.0.23, 10.1.56, 9.0.119 |
| Main condition to investigate | Security constraints for the default servlet that use http-method または http-method-omission |
| Primary risk | Method-specific authorization rules may not behave as configured |
| What it is not | Not described by Apache or NVD as direct RCE |
| First response | Upgrade, then verify method-level authorization behavior against the actual deployment descriptor |
The important phrase is “method-specific.” Servlet security constraints can be broad, covering a URL pattern for every method, or narrow, covering only named methods or all methods except named omissions. CVE-2026-55956 lives in the gap between those models. A team may have believed that one method was public and another method required a role. Or it may have believed that every method except GET was denied. In affected Tomcat versions, when that logic was tied to the default servlet mapping, the method filter could be ignored. That creates authorization uncertainty even when the XML looks correct.
What Tomcat’s default servlet does
Tomcat’s default servlet is not an exotic feature. It is the servlet that serves static resources, and it can also serve directory listings if directory listings are enabled. Tomcat’s own default servlet reference says the default servlet is declared globally in $CATALINA_BASE/conf/web.xml and is mapped by default to /. The same documentation shows directory listings disabled by default and explains that applications can override the default servlet configuration in /WEB-INF/web.xml or Tomcat’s /WEB-INF/tomcat-web.xml.(tomcat.apache.org)
That default / mapping matters because it is the weakest servlet URL pattern. It catches requests that do not match a more specific servlet mapping. In many applications, this is ordinary and safe: static CSS, JavaScript, images, documentation files, or downloadable assets flow through the default servlet. In older enterprise applications, however, static-resource paths sometimes become more sensitive than they look. They may serve exports, reports, generated files, internal manuals, packaged artifacts, public upload areas, or vendor-managed UI resources. Once a team adds security constraints to those paths, the default servlet is no longer “just static content.” It is part of the authorization boundary.
The default servlet also has settings that can change risk sharply. Tomcat documents readonly as the setting that determines whether the context is read only and whether HTTP commands such as PUT and DELETE are rejected; the default is true. It also documents allowPartialPut, default true, and allowPostAsGet, default true, as behavior that affects how certain methods are handled for static resources.(tomcat.apache.org) Those settings are not the direct root cause of CVE-2026-55956, but they explain why defenders should not evaluate the default servlet only as a passive file server. Method handling and default servlet behavior have been security-relevant in Tomcat before.
How Servlet security constraints are supposed to work
A Java web application can declare access-control rules in web.xml through security-constraint. A constraint usually combines a URL pattern, optional HTTP method selection, an authorization requirement, and optionally a transport guarantee. Jakarta’s tutorial describes a security constraint as a way to define access privileges for a collection of resources using URL mapping. It also explains that http-method そして http-method-omission determine which methods are protected by a web resource collection.(jakarta.ee)
The method rules are subtle enough that they regularly cause mistakes. Oracle’s Java EE security tutorial states that when HTTP methods are listed inside a constraint, the protection applies only to those listed methods. When no HTTP methods are listed, the protection applies to the complete set of HTTP methods, including extension methods. It also warns that not listing methods is often the simplest way to avoid leaving methods unprotected.(Oracle Docs)
A simplified all-methods constraint looks like this:
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected reports</web-resource-name>
<url-pattern>/reports/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>report-viewer</role-name>
</auth-constraint>
</security-constraint>
That rule is easy to reason about. Every HTTP method matching /reports/* needs a user in the report-viewer role. There is no method split and no uncovered method hiding in the background.
A method-specific rule is more fragile:
<security-constraint>
<web-resource-collection>
<web-resource-name>Read-only public resources</web-resource-name>
<url-pattern>/</url-pattern>
<http-method>GET</http-method>
<http-method>HEAD</http-method>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Non-read methods require an operator</web-resource-name>
<url-pattern>/</url-pattern>
<http-method-omission>GET</http-method-omission>
<http-method-omission>HEAD</http-method-omission>
</web-resource-collection>
<auth-constraint>
<role-name>operator</role-name>
</auth-constraint>
</security-constraint>
The intended policy is clear: allow ordinary reads, but require an operator for methods other than GET and HEAD. CVE-2026-55956 is exactly the kind of bug that makes this style dangerous on the default servlet path in affected versions. If the container does not honor the method or omission filter when choosing constraints for /, the live authorization behavior no longer matches the XML.
That mismatch is the real issue. Some deployments may see unexpected denial, because a constraint meant for one method is applied too broadly. Other deployments may see unexpected access, because the combination and selection of constraints no longer lines up with the intended policy. Either way, a method-specific boundary is unreliable until the server is fixed and the behavior is retested.
The root cause in the Apache fix
Apache’s public Tomcat 11 security page describes CVE-2026-55956 in one sentence: if security constraints were specified for the default servlet, any method or method omission configured as part of the constraint was ignored. The same page says the issue was reported to the Tomcat security team on June 15, 2026, made public on June 29, 2026, and fixed with commit 3f6bd2ba for Tomcat 11.(tomcat.apache.org)
The commit title is unusually clear: “Don’t ignore methods on security constraints mapped to /.” In RealmBase.java, the patch changes the matching logic so that the special / pattern is treated as matched only when securityCollection.findMethod(method) also returns true. The added test creates constraints where GET should be allowed and POST should require a specific role, then verifies that Tomcat applies the right behavior for each method.(ギットハブ)
That one-line logic change tells defenders a lot. The vulnerable behavior was not a parser failure where Tomcat failed to read XML. It was not a problem where the administrator forgot to specify roles. It was a request-time constraint-selection problem. The configuration could look right, but the runtime method check on the default servlet mapping was wrong.
This is also why generic scanner output is not enough. A scanner may detect an affected Tomcat version. It may even say “Apache Tomcat CVE-2026-55956.” But the operational question is narrower: does this application use method-specific security constraints mapped to the default servlet path, and did those constraints protect something that matters?
Affected versions and fixed versions
NVD lists CVE-2026-55956 as affecting Apache Tomcat 11.0.0-M1 through 11.0.22, 10.1.0-M1 through 10.1.55, 9.0.0.M1 through 9.0.118, 8.5.0 through 8.5.100, and 7.0.0 through 7.0.109. It recommends upgrading to 11.0.23, 10.1.56, or 9.0.119. The oss-security advisory from Apache’s Mark Thomas lists the same affected ranges and fixed versions.(NVD)
| Tomcat line | Affected range | Fixed or practical remediation path |
|---|---|---|
| Tomcat 11 | 11.0.0-M1 through 11.0.22 | Upgrade to 11.0.23 or later |
| Tomcat 10.1 | 10.1.0-M1 through 10.1.55 | Upgrade to 10.1.56 or later |
| Tomcat 9 | 9.0.0.M1 through 9.0.118 | Upgrade to 9.0.119 or later |
| Tomcat 8.5 | 8.5.0 through 8.5.100 | Upstream line is EOL; migrate to a supported line or use vendor-supported maintenance while isolating risk |
| Tomcat 7 | 7.0.0 through 7.0.109 | Upstream line is EOL; migrate |
The EOL distinction matters. Apache’s “Which Version Do I Want?” page says Tomcat 8.5 has reached end of life and that users of Tomcat 8.5.x should upgrade to Tomcat 9.x or later. The same page says Tomcat 7 is archived and users should upgrade to Tomcat 9.x or later.(tomcat.apache.org) If a vendor appliance or legacy internal system still embeds Tomcat 7 or 8.5, CVE-2026-55956 should trigger a platform conversation, not only a single patch ticket.
A supported Tomcat 9, 10.1, or 11 system can usually follow the normal maintenance-release path. A legacy Tomcat 7 or 8.5 system may need a different response: isolation, reverse-proxy method restrictions, removal of risky method-based constraints, vendor escalation, emergency replacement, or an extended-support path if migration cannot happen immediately. None of those is as clean as upgrading to a current upstream branch, but they are better than leaving a known authorization bug unresolved in an archived runtime.
Why the CVSS score does not settle the priority question
The CVSS score for CVE-2026-55956 is moderate, but the score should not be read as “ignore this.” NVD’s change history shows CISA-ADP assigning AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N, which produces a 6.5 base score. That vector means the issue is network reachable, has low attack complexity, requires no privileges and no user interaction, but the modeled confidentiality and integrity impact is low and availability impact is none. NVD’s SSVC values also state exploitation none, automatable yes, and partial technical impact.(NVD)
That is a reasonable generic score for the public facts. It is also incomplete for your environment. CVSS does not know whether the affected default servlet path protects public images or regulated exports. It does not know whether non-GET methods are blocked at a proxy before Tomcat sees them. It does not know whether the constraint sits in a forgotten vendor webapp or a heavily used internal admin workflow. It does not know whether the application has another post-authentication or post-authorization flaw that becomes reachable when method handling is wrong.
The practical priority question is therefore configuration-driven:
| Question | なぜそれが重要なのか |
|---|---|
| Is the Tomcat version in an affected range? | Version confirms whether the code path may contain the bug. |
Is there a security constraint mapped to / or the default servlet path? | The bug concerns default servlet constraints, not every Tomcat request. |
Does the constraint use http-method または http-method-omission? | Method filtering is the broken part. |
| Does the protected path serve sensitive resources or operations? | Business impact depends on what the constraint was meant to protect. |
| Can untrusted users reach the affected path? | Internal exposure may still matter, but reachability changes urgency. |
| Are non-read methods accepted at any layer? | Method exposure changes the usefulness of the bypass. |
| Is the runtime EOL? | EOL Tomcat is a lifecycle risk beyond one CVE. |
A moderate CVE on a low-value static path can be a routine maintenance item. The same CVE on an internal document export service that uses method-specific authorization around static resources deserves faster handling. The vulnerability class is the same. The business risk is not.
The most realistic abuse paths
CVE-2026-55956 is best understood as a policy confusion bug, not as a one-shot exploit. An attacker does not get code execution simply by knowing the CVE number. The attacker needs a reachable application where the security policy depends on the method-specific constraint that Tomcat mishandles.
One realistic pattern is a public-read, restricted-write design. An application may serve static files publicly through the default servlet while trying to require a role for POST, PUT, DELETE, or WebDAV-like methods. In an affected version, the live behavior may not match the intended split. That does not automatically mean writes are possible; the default servlet’s readonly setting, reverse-proxy policy, application mappings, and method support still matter. But if the application owner believed the security constraint was the control that separated public and restricted methods, that belief needs to be tested.
Another pattern is an internal enterprise webapp where static-looking paths are not truly low value. Many older Java applications generate reports, user exports, cached documents, or attachment views and then serve them through conventional web resource paths. If the team used method-specific constraints to restrict who can perform non-read operations or access certain method flows, CVE-2026-55956 can become relevant even without a dramatic public exploit.
A third pattern involves inconsistent proxy and backend policy. The reverse proxy may allow only GET and HEAD for some paths, while Tomcat configuration tries to enforce finer-grained method rules. Or the proxy may pass OPTIONS, POST, PUT, and DELETE to the backend because another application needs them. When the backend authorization layer is wrong, the proxy configuration becomes part of the exploitability question. A proxy can reduce exposure, but only if it is actually enforcing the intended method policy for the exact path before the request reaches Tomcat.
A fourth pattern is attack-chain amplification. CVE-2026-55956 is not RCE. But authorization bugs rarely need to be the final step to matter. If a method-specific authorization failure lets an attacker reach a file operation, a static upload path, a legacy WebDAV-like behavior, or an internal function that was supposed to require a role, the downstream application decides the impact. This is why remediation should include method testing and not only version replacement.
What CVE-2026-55956 is not
It is not the same as CVE-2025-24813. CVE-2025-24813 involved Apache Tomcat’s default servlet, partial PUT behavior, write-enabled default servlet conditions, and possible remote code execution or information disclosure under a specific set of conditions. NVD’s description for CVE-2025-24813 explicitly lists requirements such as writes enabled for the default servlet, partial PUT support, file-based session persistence for the RCE case, and a deserialization-capable library.(NVD) CVE-2026-55956 is about authorization constraints ignoring method or method omission on the default servlet. Both issues touch the default servlet, but their mechanics and risk conditions are different.
It is not proof that readonly=false is present. You should check readonly, because write-enabled default servlet configurations have security history and can increase downstream impact. But CVE-2026-55956 itself is not “PUT is enabled.” It is “the method portion of a default-servlet security constraint was ignored.”
It is not a generic Tomcat authentication bypass. A different Tomcat issue disclosed in the same broad period, CVE-2026-55957, concerns JNDIRealm configured to authenticate binds using GSSAPI and is described as allowing attackers to authenticate without the correct password.(NVD) CVE-2026-55956 is authorization constraint handling for the default servlet. The shared lesson is that Tomcat identity and authorization boundaries need configuration-aware testing, not banner-based panic.
It is not something you can fully assess from the internet-facing version string alone. Version detection is necessary, but the decisive evidence sits in deployment descriptors, effective configuration, method exposure, and before-and-after access behavior.
How to find exposed configurations
Start with runtime inventory. Tomcat may be installed directly, embedded in Spring Boot or another Java service, bundled inside a vendor product, packaged in a container image, or hidden behind a reverse proxy that masks the backend. You need the actual runtime version, not only the Server header. Many production systems suppress or rewrite server banners.
For a standalone Tomcat host, common commands include:
# Standalone Tomcat
$CATALINA_HOME/bin/version.sh
# Package-managed Linux systems
dpkg -l | grep -i tomcat || true
rpm -qa | grep -i tomcat || true
# Running process hints
ps aux | grep -i '[o]rg.apache.catalina.startup.Bootstrap'
# Container image hints
docker images | grep -i tomcat
docker inspect <container_id> | grep -i tomcat
For embedded Tomcat in Java applications, inspect dependencies and build artifacts:
# Maven dependency tree
mvn dependency:tree | grep -E 'tomcat|catalina|tomcat-embed'
# Gradle dependency tree
./gradlew dependencies | grep -E 'tomcat|catalina|tomcat-embed'
# Inspect packaged JARs
jar tf app.jar | grep -E 'tomcat-embed-core|catalina'
Then search deployment descriptors. The target pattern is a security constraint that maps to / and uses http-method または http-method-omission. Check global Tomcat config, application web descriptors, and Tomcat-specific descriptors:
BASES=(
"$CATALINA_BASE/conf"
"$CATALINA_HOME/conf"
"/opt"
"/srv"
"/var/lib"
)
for base in "${BASES[@]}"; do
[ -d "$base" ] || continue
find "$base" -type f \( -name "web.xml" -o -name "tomcat-web.xml" \) 2>/dev/null \
-print \
-exec grep -nE "<url-pattern>/</url-pattern>|<http-method>|<http-method-omission>|DefaultServlet|readonly" {} \;
done
That grep is intentionally broad. It will produce false positives, but it helps you find the files worth reading. Do not stop at the first match. A web application may have both global defaults and app-specific overrides. Vendor products may generate descriptors during deployment. Containers may bake one configuration into the image and mount another at runtime.
A more structured parser can highlight constraints that deserve manual review:
#!/usr/bin/env python3
"""
Find web.xml security constraints that map to "/" and use http-method
or http-method-omission. This is a triage helper, not a vulnerability
scanner. Review every hit manually.
"""
import sys
import xml.etree.ElementTree as ET
from pathlib import Path
def strip_ns(tag: str) -> str:
return tag.split("}", 1)[-1] if "}" in tag else tag
def children_named(node, name):
return [c for c in list(node) if strip_ns(c.tag) == name]
def text_of(node):
return (node.text or "").strip()
def analyze(path: Path):
try:
root = ET.parse(path).getroot()
except Exception as exc:
print(f"[!] Could not parse {path}: {exc}")
return
for sc in root.iter():
if strip_ns(sc.tag) != "security-constraint":
continue
for wrc in children_named(sc, "web-resource-collection"):
patterns = [text_of(x) for x in children_named(wrc, "url-pattern")]
methods = [text_of(x) for x in children_named(wrc, "http-method")]
omissions = [text_of(x) for x in children_named(wrc, "http-method-omission")]
if "/" in patterns and (methods or omissions):
print(f"\n[review] {path}")
print(f" url-patterns: {patterns}")
print(f" http-method: {methods or 'none'}")
print(f" http-method-omission: {omissions or 'none'}")
auth = children_named(sc, "auth-constraint")
if not auth:
print(" auth-constraint: none, request may be permitted if this constraint applies")
else:
roles = []
for a in auth:
roles.extend(text_of(r) for r in children_named(a, "role-name"))
print(f" auth roles: {roles or 'empty auth-constraint, deny access if this constraint applies'}")
if __name__ == "__main__":
if len(sys.argv) < 2:
print("usage: find_default_servlet_method_constraints.py <web.xml> [more files...]")
sys.exit(2)
for arg in sys.argv[1:]:
analyze(Path(arg))
A hit does not prove exploitation. It proves that the application uses the kind of method-specific default-servlet constraint that deserves testing and upgrade verification. The strongest evidence combines version, descriptor, method matrix, and post-upgrade retest.
Safe method testing without destructive behavior
Method testing should be done only in systems you are authorized to test, ideally staging first. The goal is not to “attack Tomcat.” The goal is to verify whether the configured method-level policy is enforced. Use a harmless static resource and a known test account. Avoid uploading, deleting, or modifying files in production.
A basic status matrix can be collected like this:
BASE="https://staging.example.com/app"
RESOURCE="/static/probe.txt"
# Unauthenticated requests
for method in GET HEAD OPTIONS POST PUT DELETE TRACE; do
printf "%-8s " "$method"
curl -ks -o /dev/null -w "%{http_code}\n" -X "$method" "$BASE$RESOURCE"
done
Then repeat with a user that should have the required role:
BASE="https://staging.example.com/app"
RESOURCE="/static/probe.txt"
COOKIE="JSESSIONID=<test-session-cookie>"
for method in GET HEAD OPTIONS POST PUT DELETE TRACE; do
printf "%-8s " "$method"
curl -ks -o /dev/null -w "%{http_code}\n" \
-H "Cookie: $COOKIE" \
-X "$method" \
"$BASE$RESOURCE"
done
Interpret status codes carefully:
| Observation | Possible meaning | What to verify next |
|---|---|---|
| GET returns 200 unauthenticated | May be expected if GET is public | Confirm the descriptor intentionally permits GET |
| POST returns 401 or 403 unauthenticated | Method-level restriction may be working | Confirm authorized role behavior and retest after patch |
| POST returns 405 unauthenticated | Request may have reached servlet method handling instead of auth, or method may be unsupported before authorization | Compare with descriptor and authenticated behavior |
| PUT returns 403 | Could be authorization or default servlet readonly rejection | チェック readonly, proxy policy, and server logs |
| DELETE returns 405 | Method unsupported or blocked later in the stack | Do not assume authorization worked without role comparison |
| OPTIONS reveals PUT or DELETE | May indicate allowed-method exposure but not authorization by itself | Confirm proxy, Tomcat, and app behavior |
| Wrong-role user behaves like right-role user | Suspicious role enforcement failure | Compare constraints and effective role mapping |
| Behavior changes after Tomcat upgrade | Strong evidence the CVE fix affected the path | Preserve before-and-after artifacts |
A common mistake is treating 405 as proof of safety. It is not. A 405 means the method is not allowed by the target resource handler at that point in the request flow. If the policy says unauthenticated POST should be rejected before reaching the servlet, a 405 may mean the request bypassed the authorization rule and was rejected later for a different reason. That may still reduce immediate risk, but it is not the same as confirming the security constraint worked.
Another mistake is testing only with a valid user. Authorization bugs often show up in negative paths: unauthenticated user, wrong role, wrong method, wrong path, missing cookie, expired session. A remediation report that says “valid user can still download the static file” tells you little. A stronger report says “unauthenticated POST to /static/probe.txt returned 403 before and after upgrade, wrong-role user returned 403, correct-role user reached the expected application behavior, and GET remained public as configured.”
Reviewing web.xml for high-risk patterns
The highest-risk configurations are usually not long. They are small, plausible snippets created for convenience years ago. A risky pattern may look like this:
<security-constraint>
<web-resource-collection>
<web-resource-name>Public static reads</web-resource-name>
<url-pattern>/</url-pattern>
<http-method>GET</http-method>
<http-method>HEAD</http-method>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Block or restrict non-read methods</web-resource-name>
<url-pattern>/</url-pattern>
<http-method-omission>GET</http-method-omission>
<http-method-omission>HEAD</http-method-omission>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
A safer design often separates paths rather than relying on method-level differences at /:
<!-- Public static assets are public by path. -->
<!-- No security-constraint for /assets/* if truly public. -->
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected downloads</web-resource-name>
<url-pattern>/protected-downloads/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>download-user</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Admin operations</web-resource-name>
<url-pattern>/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
Path separation is not always possible in legacy systems, but it is easier to test and reason about. If a static file is public, make it public by path. If a file is sensitive, place it under a protected path. If an operation changes state, keep it out of the default servlet path and implement it through an application endpoint with explicit authorization checks, CSRF protections where relevant, audit logging, and tests.
If method-level security is truly required, cover every intended method and deny the rest. Oracle’s guidance explicitly warns that listing methods in constraints can leave unlisted methods unprotected, and it recommends careful coverage when different methods need different protection.(Oracle Docs) In modern environments, deny-uncovered-http-methods can also help, but it should not be used as a blind checkbox. IBM’s Servlet 3.1 security documentation explains that deny-uncovered-http-methods denies uncovered methods for the best-matching URL pattern and returns 403, which is useful precisely because uncovered methods are otherwise easy to miss.(IBM)
Reverse proxies and WAFs can reduce exposure, but they are not a fix
A reverse proxy can block methods before they reach Tomcat. That is useful. It can also create a false sense of security if the policy is incomplete, path matching differs from Tomcat’s mapping, or internal traffic bypasses the proxy.
For NGINX, a narrow method policy for static resources might look like this:
location /app/static/ {
limit_except GET HEAD {
deny all;
}
proxy_pass http://tomcat_backend;
}
For Apache HTTP Server in front of Tomcat, a method restriction might look like this:
<Location "/app/static/">
<LimitExcept GET HEAD>
Require all denied
</LimitExcept>
ProxyPass "http://tomcat-backend/app/static/"
ProxyPassReverse "http://tomcat-backend/app/static/"
</Location>
These controls can be good compensating measures while an upgrade is being scheduled, especially for EOL Tomcat systems. They do not remove the vulnerable code from Tomcat. They also do not protect paths that bypass the proxy, internal service-to-service calls, alternate virtual hosts, management ports, direct pod access in Kubernetes, or a second connector exposed for health checks or legacy clients.
A useful test is to validate both layers:
# Test through the public proxy
curl -ks -o /dev/null -w "%{http_code}\n" -X PUT https://public.example.com/app/static/probe.txt
# Test from a trusted internal network path that reaches Tomcat directly
curl -ks -o /dev/null -w "%{http_code}\n" -X PUT http://tomcat-internal:8080/app/static/probe.txt
If the proxy blocks PUT but Tomcat accepts or mishandles the request internally, the risk may still matter for attackers who gain a foothold inside the network. That is not theoretical. Many Tomcat deployments serve internal line-of-business applications. Internal does not mean trusted. VPN users, contractors, compromised endpoints, CI systems, monitoring agents, and partner networks all expand the set of clients that may reach a backend.
Detection is mostly behavioral and configuration-driven
Do not expect a neat IOC for CVE-2026-55956. There is no universal exploit URI. There is no single malicious header. There is no reliable payload string. A suspicious request depends on the application path and method policy.
The most useful logs are access logs, reverse-proxy logs, application logs, authentication logs, and any audit trail that records role decisions. Look for non-standard or unexpected methods against static-resource paths:
awk '{print $6, $7, $9}' access.log \
| sed 's/"//g' \
| awk '$1 !~ /^(GET|HEAD)$/ {print}' \
| head -100
A slightly more useful report groups method, path prefix, and status:
awk '{
method=$6; gsub(/"/, "", method);
path=$7;
status=$9;
split(path, parts, "/");
prefix="/" parts[2] "/" parts[3];
key=method " " prefix " " status;
count[key]++;
}
END {
for (k in count) print count[k], k;
}' access.log | sort -nr | head -50
Signals worth reviewing include:
| 信号 | なぜそれが重要なのか | 制限 |
|---|---|---|
| POST, PUT, DELETE, TRACE, or unusual extension methods against static paths | Attackers and scanners often probe method handling | Some monitoring tools use OPTIONS or HEAD legitimately |
| 405 responses on paths expected to be authorization-protected | May mean request reached servlet handling rather than auth | Needs comparison with configured policy |
| 200 or 3xx responses for unexpected methods | Could indicate method confusion or application-specific behavior | Some frameworks treat POST as GET intentionally |
| Difference between proxy status and backend status | May show inconsistent enforcement | Requires correlated logs |
| Wrong-role access to method-specific paths | Stronger authorization concern | Requires test accounts and role mapping |
Affected Tomcat version plus / method constraints | High-value triage evidence | Still needs runtime reachability analysis |
Access logs alone cannot prove safety. They can show probing, unexpected method exposure, or suspicious behavior. They cannot tell you whether a constraint was supposed to apply unless you compare them with the descriptor and role model.
Remediation playbook
The direct remediation is to upgrade. Use 11.0.23 or later for Tomcat 11, 10.1.56 or later for Tomcat 10.1, and 9.0.119 or later for Tomcat 9. Apache’s security pages and the NVD record identify those fixed releases for CVE-2026-55956.(tomcat.apache.org)
A practical remediation plan should look like this:
| ステップ | アクション | Evidence to preserve |
|---|---|---|
| 1 | Identify Tomcat runtime versions across standalone, embedded, containerized, and vendor-managed deployments | Version output, package metadata, image digest, dependency tree |
| 2 | Search for default servlet constraints using http-method または http-method-omission | Relevant web.xml snippets with file paths |
| 3 | Map affected paths to business value | Owner, data type, user population, exposure path |
| 4 | Check proxy and connector method policy | Reverse-proxy config, connector exposure, direct-backend reachability |
| 5 | Upgrade to fixed version | New version output, release artifact, deployment record |
| 6 | Run negative and positive method tests | Method matrix before and after upgrade |
| 7 | Review logs for unexpected methods | Access-log summary, security-log notes |
| 8 | Simplify configuration where possible | Pull request, config diff, owner approval |
| 9 | Track EOL systems separately | Exception, migration owner, deadline, compensating controls |
The post-upgrade test matters. Many teams treat patching as the end of the story. For an authorization bug, patching without negative testing leaves uncertainty. You want proof that the method-specific behavior now matches the descriptor, especially if the application uses unusual method splits.
Hardening beyond the patch
CVE-2026-55956 is a good reason to simplify security design around static resources.
Prefer path-based authorization over method-based authorization where possible. /public/* is easier to reason about than “GET is public but other methods require a role on /." /admin/* is easier to audit than a default servlet constraint that depends on omissions. Separate paths also help reverse proxies, WAF rules, CDN behavior, tests, and human reviewers align around the same boundary.
Keep the default servlet read-only unless there is a very specific, reviewed reason to change it. Tomcat documents readonly as true by default, rejecting commands such as PUT and DELETE.(tomcat.apache.org) Write-enabled default servlet configurations have a history of serious downstream risk, including CVE-2025-24813 and older PUT-related Tomcat issues. If an application needs uploads, implement them through application code with authentication, authorization, size limits, content validation, storage isolation, malware scanning where appropriate, audit logging, and tests.
Disable unneeded HTTP methods at the edge and the backend. Do not assume that a proxy blocks a method unless you have tested the exact path. Do not assume that OPTIONS output is authoritative for authorization. Do not assume that a method rejected by the servlet is rejected for the right reason.
Add regression tests for security constraints. A small integration test that sends unauthenticated and wrong-role requests for GET, HEAD, POST, PUT, DELETE, and OPTIONS can catch configuration drift. For Java teams, these tests often deliver more value than another static XML review because they validate runtime behavior.
用途 deny-uncovered-http-methods where it fits your Servlet version and container behavior, but test it. The purpose is to avoid silently accessible methods that the deployment descriptor did not cover. It is not a substitute for clear path boundaries, role tests, or upgrades.
Related Tomcat CVEs that sharpen the lesson
CVE-2026-55956 is not the only Tomcat issue where a small boundary assumption changed the security outcome. The useful lesson is not “Tomcat is unsafe.” The useful lesson is that Java web security relies on many layers: servlet mapping, default servlet behavior, Realms, connector settings, HTTP methods, certificate validation, reverse proxies, and deployment descriptors. When any layer interprets a boundary differently from the operator’s intent, access control can fail.
CVE-2025-24813 is the closest default servlet comparison. It involved Tomcat’s default servlet, partial PUT, and write-enabled conditions that could lead to remote code execution, information disclosure, or content modification under specific conditions. NVD’s description makes clear that writes enabled for the default servlet were disabled by default, and that the RCE case also required file-based session persistence with the default storage location plus a library usable in a deserialization attack.(NVD) The relevance to CVE-2026-55956 is not that the two bugs are the same. They are not. The relevance is that default servlet configuration details can drastically change impact.
CVE-2026-43515 is another method-constraint lesson. Apache’s Tomcat 11 security page says that when multiple security constraints defined an HTTP method constraint for the same extension pattern, only the first method constraint was applied. It was fixed before CVE-2026-55956 and affected Tomcat 11.0.0-M1 to 11.0.21 in that branch.(tomcat.apache.org) That issue and CVE-2026-55956 point to the same defensive habit: if access control depends on method-specific constraint merging, test every method and every role.
CVE-2026-55957 is a different kind of boundary failure in the same ecosystem. NVD describes it as a Missing Critical Step in Authentication issue where Tomcat JNDIRealm configured to authenticate binds using GSSAPI allowed attackers to authenticate without the correct password.(NVD) That bug is not about the default servlet. But it is a reminder that Tomcat vulnerability response should be configuration-aware. A Realm bug matters when the vulnerable Realm path is configured. A default servlet constraint bug matters when the affected constraint pattern is configured.
CVE-2017-12617 is older but still instructive. Apache’s Tomcat 9 security history describes it as remote code execution when HTTP PUTs were enabled through the non-default readonly=false setting of the Default servlet, allowing a JSP file to be uploaded and then executed.(tomcat.apache.org) That older issue reinforces a simple rule: do not turn the default servlet into a write surface casually.
| CVE | Area | なぜここが重要なのか | Defensive takeaway |
|---|---|---|---|
| CVE-2026-55956 | Default servlet method constraints | Direct issue: method or omission ignored on default servlet constraints | Upgrade and retest method-specific authorization |
| CVE-2026-43515 | Method constraints on extension patterns | Another Tomcat method-constraint correctness issue | Avoid fragile constraint combinations when simpler path boundaries work |
| CVE-2025-24813 | Default servlet partial PUT and write-enabled paths | Shows how default servlet settings can escalate impact | Keep default servlet read-only and isolate upload logic |
| CVE-2026-55957 | JNDIRealm GSSAPI authentication | Same broader Tomcat response theme: configuration decides exposure | Do configuration-aware triage, not banner-only triage |
| CVE-2017-12617 | PUT-enabled Default servlet RCE | Older proof that write-enabled Default servlet is dangerous | Do not enable PUT on default servlet without a hard security case |
Reporting the issue internally
A useful internal report should avoid both extremes. Do not write “critical Tomcat RCE” if you do not have evidence. Do not write “moderate, no action” just because the score is 6.5. Write the actual exposure.
A strong report includes:
Finding:
Apache Tomcat CVE-2026-55956, default servlet method constraints ignored
Affected asset:
app-prod-12, Tomcat 10.1.52, behind nginx ingress, internal VPN exposed
Evidence:
- Runtime version: Apache Tomcat/10.1.52
- web.xml contains security-constraint mapped to /
- Constraint uses http-method-omission GET and HEAD
- Non-read methods are intended to require role operator
- Reverse proxy passes OPTIONS and POST to backend
- Pre-upgrade test showed inconsistent method behavior against /static/probe.txt
Risk:
Method-level authorization around default servlet resources may not match
the configured deployment descriptor. Impact depends on the protected
resources and allowed methods.
Remediation:
Upgrade to Tomcat 10.1.56 or later.
Retest unauthenticated, wrong-role, and correct-role behavior for GET,
HEAD, POST, PUT, DELETE, OPTIONS.
Post-fix evidence required:
- Tomcat version output
- Config diff
- Method matrix after upgrade
- Owner confirmation that sensitive static paths are protected by path,
not only method split on /
That kind of report gives engineering something concrete to fix. It also gives compliance, incident response, and management a defensible record. The point is not to produce a scanner screenshot. The point is to prove whether the configured boundary worked before and after the fix.
For teams running repeated authorized validation across many Java applications, evidence discipline matters more than a one-line vulnerability label. A platform such as Penligent can support that workflow when used to preserve target scope, commands, observations, reproduction steps, and post-fix retest evidence, but the vulnerability facts should still come from Apache, NVD, and other authoritative sources. Penligent’s broader site describes the product context, and its adjacent Tomcat write-up on CVE-2026-55957 is a useful companion for teams triaging the June 2026 Tomcat batch because it treats Tomcat exposure as a configuration-specific question rather than a banner match.(寡黙)
Common mistakes during response
The first mistake is treating CVE-2026-55956 as if every Tomcat instance is equally exposed. The affected version range is broad, but the vulnerable configuration pattern is narrower. Prioritize hosts where default servlet constraints use method-specific selection.
The second mistake is ignoring legacy Tomcat because it is “only internal.” Internal Java applications often protect sensitive workflows: HR documents, finance exports, admin dashboards, vendor portals, manufacturing systems, support tooling, or identity-adjacent utilities. If a compromised endpoint or VPN account can reach the application, method-level authorization errors can still matter.
The third mistake is assuming static files are harmless. Static delivery can expose sensitive generated files, bundled configuration, customer exports, or internal documentation. If a team added constraints around a static path, it probably had a reason.
The fourth mistake is relying on a WAF alone. WAF and reverse-proxy method restrictions are useful, but they must be tested against the exact path, host, and internal route. If service-to-service traffic bypasses the edge, the backend behavior still matters.
The fifth mistake is patching without testing wrong-role behavior. For authorization issues, negative tests are essential. A valid user seeing a valid file is not proof of security. A wrong-role user being denied for the right method and path is much stronger evidence.
The sixth mistake is keeping fragile XML because “the patch fixed it.” The patch fixes Tomcat behavior. It does not make a complicated method-based authorization design easy to maintain. Where possible, simplify the design.
A safe validation checklist
Use this checklist after upgrading or while preparing an exception for a legacy system:
| チェック | Pass condition |
|---|---|
| Runtime version confirmed | Tomcat reports 11.0.23+, 10.1.56+, or 9.0.119+ for supported branches |
| Descriptor reviewed | No unreviewed method-specific constraints on / or default servlet paths |
| Default servlet write status checked | readonly remains true unless there is an approved exception |
| Method matrix tested | GET, HEAD, OPTIONS, POST, PUT, DELETE, TRACE tested against representative paths |
| Role matrix tested | Unauthenticated, wrong-role, and correct-role users behave as intended |
| Proxy behavior tested | Public and internal routes enforce the same intended method policy |
| Logs reviewed | Unexpected methods against static paths are investigated |
| EOL systems tracked | Tomcat 7 and 8.5 systems have owners, isolation, and migration deadlines |
| Report evidence preserved | Version, config snippet, request results, and post-fix status are attached |
This is deliberately more than “upgrade and close.” CVE-2026-55956 is an access-control correctness issue. Closing it properly means confirming that the rule the team thought it had is the rule the system now enforces.
よくあるご質問
Does CVE-2026-55956 affect every Apache Tomcat server?
- No. The affected version ranges are broad, but the practical exposure depends on configuration.
- The key pattern is a security constraint for the default servlet, especially a
/URL pattern, that useshttp-methodまたはhttp-method-omission. - A Tomcat server that does not use method-specific security constraints around the default servlet still needs normal security maintenance, but it may not have the vulnerable policy path.
- Embedded Tomcat and vendor-bundled Tomcat should still be checked because the runtime version and descriptors may not be obvious from the public banner.
Is CVE-2026-55956 remote code execution?
- Apache and NVD describe CVE-2026-55956 as Improper Authorization, not direct remote code execution.
- The direct issue is that method or method omission settings in default servlet security constraints could be ignored.
- Downstream impact depends on what the affected method-specific rule was protecting.
- Do not label it RCE unless a separate application-specific chain proves code execution.
Which Tomcat versions should I upgrade to?
- Tomcat 11 users should upgrade to 11.0.23 or later.
- Tomcat 10.1 users should upgrade to 10.1.56 or later.
- Tomcat 9 users should upgrade to 9.0.119 or later.
- Tomcat 8.5 and Tomcat 7 are legacy or EOL paths in upstream guidance; plan migration, isolation, or vendor-supported maintenance rather than waiting for a normal upstream branch fix.(NVD)
How do I know whether my application depends on the vulnerable path?
- Search
web.xmlそしてtomcat-web.xmlにとってurl-patternset to/. - Within those constraints, look for
http-methodそしてhttp-method-omission. - Confirm whether the path is served by Tomcat’s default servlet rather than a custom servlet or framework route.
- Test unauthenticated, wrong-role, and correct-role behavior for each method in staging.
- Preserve the exact descriptor snippet and request results as evidence.
Can a reverse proxy or WAF fully mitigate CVE-2026-55956?
- A proxy can reduce exposure if it blocks risky methods before they reach Tomcat.
- It is not a full fix for the vulnerable Tomcat code.
- Internal routes, service-to-service paths, alternate connectors, and direct backend access may bypass the proxy.
- Use proxy restrictions as a compensating control while upgrading, not as a permanent replacement for upgrading.
What should I test after upgrading?
- Confirm the runtime version changed to a fixed release.
- Retest GET, HEAD, OPTIONS, POST, PUT, DELETE, and TRACE against representative default-servlet resources.
- Compare unauthenticated, wrong-role, and correct-role users.
- Confirm the observed behavior matches the deployment descriptor.
- Review logs for unexpected method traffic and update regression tests so the behavior stays correct.
How is CVE-2026-55956 different from CVE-2025-24813?
- CVE-2026-55956 is about method-specific security constraints on the default servlet being ignored.
- CVE-2025-24813 involved the default servlet, partial PUT, write-enabled conditions, and possible RCE or information disclosure under specific prerequisites.
- CVE-2025-24813 risk depends heavily on write-enabled default servlet behavior and other conditions such as file-based session persistence for the RCE case.
- The shared lesson is that Tomcat default servlet configuration deserves careful review, especially when methods and writes are involved.(NVD)
Is there evidence of active exploitation?
- NVD’s CISA-ADP SSVC data for CVE-2026-55956 listed
exploitation: nonein the change history reviewed here. - The same SSVC data marked the issue as
automatable: yes, so defenders should not treat lack of known exploitation as a reason to ignore it. - Practical priority should be based on affected version, method-specific default servlet constraints, reachability, and protected resource value.
- Monitor access logs for unusual methods against static-resource paths, but do not rely on logs alone to prove exposure or safety.(NVD)
クロージング
CVE-2026-55956 is a clean example of a vulnerability that becomes serious only when defenders understand the configuration. The bug is not a generic Tomcat panic button. It is also not harmless. If an application relied on method-specific constraints around the default servlet, affected Tomcat versions could enforce a different policy from the one written in web.xml.
The right response is direct: upgrade to a fixed supported Tomcat release, identify default servlet constraints that use method selection, test the negative paths, and simplify fragile method-based designs where possible. For legacy Tomcat 7 and 8.5 systems, treat the issue as part of a larger lifecycle risk. A modern patch closes this specific bug. A clear path model, minimal method exposure, and repeatable authorization tests keep the same class of mistake from coming back.
Japanese 
English 
German 
French 
Spanish 
Portuguese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew