org.apache.tomcat:tomcat-catalina@7.0.42 vulnerabilities
-
latest version
11.0.0
-
latest non vulnerable version
-
first published
14 years ago
-
latest version published
2 months ago
-
licenses detected
- [0,)
-
package manager
Direct Vulnerabilities
Known vulnerabilities in the org.apache.tomcat:tomcat-catalina package. This does not include vulnerabilities belonging to this package’s dependencies.
Automatically find and fix vulnerabilities affecting your projects. Snyk scans for vulnerabilities and provides fixes for free.| Vulnerability | Vulnerable Version |
|---|---|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Improper Input Validation. Queries made by the JNDI Realm did not always correctly escape parameters. Parameter values could be sourced from user provided data (e.g., user names) as well as configuration data provided by an administrator. In limited circumstances it was possible for users to authenticate using variations of their user name and/or to bypass some of the protection provided by the LockOut Realm. How to fix Improper Input Validation? Upgrade |
[10.0.0-M1,10.0.6)
[9.0.0.M1,9.0.46)
[8.5.0,8.5.66)
[7.0.0,7.0.109)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Remote Code Execution (RCE). The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue. How to fix Remote Code Execution (RCE)? Upgrade |
[10.0.0-M1,10.0.2)
[9.0.0.M1,9.0.43)
[8.5.0,8.5.63)
[7.0.0,7.0.108)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Information Disclosure. When serving resources from a network location using the NTFS file system, affected versions were susceptible to JSP source code disclosure in some configurations. The root cause was the unexpected behaviour of the JRE API How to fix Information Disclosure? Upgrade |
[10.0.0-M1,10.0.0-M10)
[9.0.0.M1,9.0.40)
[8.5.0,8.5.60)
[7.0.0,7.0.107)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Remote Code Execution (RCE). If an attacker is able to control the contents and name of a file on the server; and the server is configured to use the PersistenceManager with a FileStore; and the PersistenceManager is configured with sessionAttributeValueClassNameFilter="null" (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over; then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control. How to fix Remote Code Execution (RCE)? Upgrade |
[10.0.0-M1,10.0.0-M5)
[9.0.0M1,9.0.35)
[8.5.0,8.5.55)
[7.0.0,7.0.104)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Session Fixation. When using FORM authentication there was a narrow window where an attacker could perform a session fixation attack. The window was considered too narrow for an exploit to be practical but, erring on the side of caution, this issue has been treated as a security vulnerability. How to fix Session Fixation? Upgrade |
[9.0.0.M1,9.0.30)
[8.5.0,8.5.50)
[,7.0.99)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Cross-site Scripting (XSS) via the SSI Note: Server Side Includes (SSI) is disabled by default and is intended for debugging purposes only. How to fix Cross-site Scripting (XSS)? Upgrade |
[9.0.0.M1,9.0.18)
[8.5.0,8.5.40)
[7.0.0,7.0.94)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Remote Code Execution due to a bug in the way the underlying Java Runtime Environment (JRE) passes command line arguments to windows systems when the option The CGI Servlet in Apache Tomcat when enabled, will pass user input to the underlying operating system for command line parsing. However, this process is not consistent and may allow the injection of additional arguments. This misconfiguration could be abused by attackers to execute code on an application's underlying operating system. How to fix Remote Code Execution? Upgrade |
[7.0.0,7.0.94)
[8.5.0,8.5.40)
[9.0.0.M1,9.0.18)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Open Redirect. When the default servlet 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. How to fix Open Redirect? Upgrade |
[7.0.23,7.0.91)
[8.5.0,8.5.34)
[9.0.0,9.0.12)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Insecure Defaults. The defaults settings for the How to fix Insecure Defaults? Upgrade |
[,7.0.89)
[8.0.0,8.0.53)
[8.5.0,8.5.32)
[9.0.0,9.0.9)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Access Restriction Bypass. The URL pattern of (the empty string) which exactly maps to the context root was not correctly handled, 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. How to fix Access Restriction Bypass? Upgrade |
[7.0.0,7.0.85)
[8.0.0.RC1,8.0.50)
[8.5.0,8.5.28)
[9.0.0.M1,9.0.5)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Directory Traversal. Security constraints defined by annotations of Servlets 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. How to fix Directory Traversal? Upgrade |
[9.0.0M1,9.0.5)
[8.5.0,8.5.28)
[8.0.0RC1,8.0.50)
[7.0.0,7.0.85)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Arbitrary Code Execution. When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet 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. This is due to an incomplete fix for CVE-2017-12615. How to fix Arbitrary Code Execution? Upgrade |
[,7.0.82)
[8,8.0.46)
[8.5,8.5.22)
[9.0.0.M1,9.0.1)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Access Restriction Bypass. When using a How to fix Access Restriction Bypass? Upgrade |
[7.0.0,7.0.81)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Arbitrary Code Execution. When running Apache Tomcat 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. The fix for this vulnerability was incomplete, see CVE-2017-12617. How to fix Arbitrary Code Execution? Upgrade |
[7.0.0,7.0.81)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Cache Poisoning. The CORS Filter did not add an HTTP Vary header indicating that the response varies depending on Origin. This permitted client and server side cache poisoning in some circumstances. How to fix Cache Poisoning? Upgrade |
[7.0.0,7.0.79)
[8.0.0RC1,8.0.45)
[8.5.0,8.5.16)
[9.0.0.M1,9.0.0.M22)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Access Restriction Bypass. 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. How to fix Access Restriction Bypass? Upgrade |
[7.0.0,7.0.78)
[8.0.0RC1,8.0.44)
[8.5.0,8.5.15)
[9.0.0.M1,9.0.0.M21)
|
|
[7.0.0,7.0.76)
[8,8.0.42)
[8.5.0,8.5.12)
[9-alpha,9.0.0.M17)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Denial of Service (DoS). It allows remote attackers to cause a denial of service (CPU consumption) via a long boundary string. How to fix Denial of Service (DoS)? Upgrade |
[7.0.0,7.0.70)
[8.0,8.0.36)
[8.5.0,8.5.3)
[9-alpha,9.0.0.M7)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Information Exposure. The refactoring of the Connector code for 8.5.x onwards introduced a regression in the error handling of the send file code for the NIO HTTP connector. An error during send file processing resulted in the current Processor object being added to the Processor cache multiple times. This in turn meant that the same Processor could be used for concurrent requests. Sharing a Processor can result in information leakage between requests including, not not limited to, session ID and the response body. How to fix Information Exposure? Upgrade |
[7,7.0.74)
[8.5.0,8.5.9)
[8.0.0RC1,8.0.40)
[9.0.0M1,9.0.0M15)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Access Restriction Bypass. It was discovered that it was possible for a web application to access any global JNDI resource whether an explicit ResourceLink had been configured or not. How to fix Access Restriction Bypass? Upgrade |
[7.0.0,7.0.72)
[8,8.0.37)
[8.5.0,8.5.5)
[9-alpha,9.0.0.M10)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Timing Attack. The How to fix Timing Attack? Upgrade |
[7.0.0,7.0.72)
[8,8.0.37)
[8.5.0,8.5.5)
[9-alpha,9.0.0.M10)
|
|
[7,7.0.66)
[8,8.0.30)
[9-alpha,9.0.0.M2)
|
|
[7.0.0,7.0.68)
[8,8.0.31)
[9-alpha,9.0.0.M2)
|
|
[7.0.0,7.0.68)
[8,8.0.31)
[9-alpha,9.0.0.M2)
|
|
[7.0.0,7.0.68)
[8,8.0.30)
[9-alpha,9.0.0.M2)
|
|
[7.0.0,7.0.68)
[8,8.0.31)
[9-alpha,9.0.0.M2)
|
|
[7.0.0,7.0.55)
[8,8.0.9)
|
|
[7.0.0,7.0.53)
[8,8.0.4)
|
org.apache.tomcat:tomcat-catalina is a Tomcat Servlet Engine Core Classes and Standard implementations. Affected versions of this package are vulnerable to Arbitrary File Read. Apache Tomcat before 6.0.40, 7.x before 7.0.54, and 8.x before 8.0.6 does not properly constrain the class loader that accesses the XML parser used with an XSLT stylesheet, which allows remote attackers to (1) read arbitrary files via a crafted web application that provides an XML external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue, or (2) read files associated with different web applications on a single Tomcat instance via a crafted web application. How to fix Arbitrary File Read? Upgrade |
[7.0.0,7.0.54)
[8,8.0.6)
|
|
[7.0.0,7.0.50)
[8.0.0-RC1,8.0.0-RC10)
|