Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
79 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Security constraints defined by annotations of Servlets in Apache Tomcat 9.0.0.M1 to 9.0.4, 8.5.0 to 8.5.27, 8.0.0.RC1 to 8.0.49 and 7.0.0 to 7.0.84 were only applied once a Servlet had been loaded. Because security constraints defined in this way apply to the URL pattern and any URLs below that point, it was possible - depending on the order Servlets were loaded - for some security constraints not to be applied. This could have exposed resources to users who were not authorised to access them.
Recommended action: Upgrade to 9.0.5, 8.5.28 or 7.0.85 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The URL pattern of "" (the empty string) which exactly maps to the context root was not correctly handled in Apache Tomcat 9.0.0.M1 to 9.0.4, 8.5.0 to 8.5.27, 8.0.0.RC1 to 8.0.49 and 7.0.0 to 7.0.84 when used as part of a security constraint definition. This caused the constraint to be ignored. It was, therefore, possible for unauthorised users to gain access to web application resources that should have been protected. Only security constraints with a URL pattern of the empty string were affected.
Recommended action: Upgrade to 9.0.5, 8.5.28, 8.0.51 or 7.0.86 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When the default servlet in Apache Tomcat versions 9.0.0.M1 to 9.0.11, 8.5.0 to 8.5.33 and 7.0.23 to 7.0.90 returned a redirect to a directory (e.g. redirecting to '/foo/' when the user requested '/foo') a specially crafted URL could be used to cause the redirect to be generated to any URI of the attackers choice.
Recommended action: Upgrade to 9.0.12, 8.5.34 or 7.0.91 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When running Apache Tomcat 7.0.0 to 7.0.79 on Windows with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.
Recommended action: Upgrade to 7.0.79 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.