dbcve.org
TomcatWeb server / proxy · Apache

CVE-2017-5664

HIGH · 7.5 CVSS v3.0 Published 2017-06-06
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
84/100
Remediation priority · High
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

The Apache Tomcat Default Servlet (versions 7.0.0-7.0.77, 8.0.0.RC1-8.0.43, 8.5.0-8.5.14, 9.0.0.M1-9.0.0.M20) does not properly handle static error page serving when the original request uses a non-GET HTTP method. When an error occurs and forwards to a static error page, Tomcat forwards the original HTTP method instead of treating it as a GET request. This can lead to unexpected behavior including potential modification or removal of static error files if the DefaultServlet is configured to allow writes.

MitigationUpgrade to Apache Tomcat 7.0.78+, 8.0.44+, 8.5.15+, or 9.0.0.M21+. As a workaround, ensure custom error Servlets and JSPs explicitly handle any error dispatch as a GET request regardless of the original HTTP method.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
TomcatWeb server / proxy
Affected:= 7.0.0= 7.0.1= 7.0.2= 7.0.3= 7.0.4= 7.0.5= 7.0.6= 7.0.7= 7.0.8= 7.0.9= 7.0.10= 7.0.11

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify installed Tomcat version
    Check the server's Tomcat version (e.g., from $CATALINA_HOME/README.txt, the server info, or the jar file name in the lib folder). Compare this version against the affected ranges: 7.0.0-7.0.77, 8.0.0.RC1-8.0.43, 8.5.0-8.5.14, or 9.0.0.M1-9.0.0.M20.
    Affected if The installed version falls within any of the affected version ranges.
  2. Locate custom error page configurations
    Review the application's web.xml and the conf/web.xml file for <error-page> entries that point to static resources (e.g., <error-code>404</error-code> pointing to an HTML file).
    Affected if Static error pages (HTML files) are configured for error handling.
  3. Verify DefaultServlet write permissions
    Check the conf/web.xml or application web.xml for the DefaultServlet servlet definition. Look for the 'readonly' init parameter - if set to 'false', writes are permitted.
    Affected if The DefaultServlet is configured with readonly=false, allowing write operations.
  4. Confirm static error page location is writable
    Verify that the directory containing static error pages (as referenced in the error-page configuration) is writable by the Tomcat process user.
    Affected if Static error pages reside in a directory writable by the Tomcat process.

You are affected if your Tomcat version is within the vulnerable range AND you have static error pages configured AND the DefaultServlet permits writes (readonly=false), because a non-GET request triggering an error could modify or delete those static error pages.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

From vendor data
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Upgrade to Apache Tomcat 7.0.78+, 8.0.44+, 8.5.15+, or 9.0.0.M21+. As a workaround, ensure custom error Servlets and JSPs explicitly handle any error dispatch as a GET request regardless of the original HTTP method.

Fix this in Tomcat Scoped from the published advisory
  • Consultation2.0 h
  • Implementation3.0 h
  • Testing3.0 h
  • Review / QA2.0 h
10.0 hours of engineering $1,750
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,800.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2017-5664 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2017-5664 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data