A deserialization flaw was discovered in Apache Tomcat's use of a FileStore. An attacker can exploit the flaw if all of the following are true: An attacker is able to control the contents and name of a file on the server. The server is configured to use the PersistenceManager with a FileStore. 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. The attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over. If all these conditions are true, the attacker can use a specifically crafted request to trigger Remote Code Execution through deserialization of the file under their control.

This flaw affects the following Tomcat versions: 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54, and 7.0.0 to 7.0.103.

Upstream commits:

Tomcat 10.0: https://github.com/apache/tomcat/commit/bb33048e3f9b4f2b70e4da2e6c4e34ca89023b1b Tomcat 9.0: https://github.com/apache/tomcat/commit/3aa8f28db7efb311cdd1b6fe15a9cd3b167a2222 Tomcat 8.5: https://github.com/apache/tomcat/commit/ec08af18d0f9ddca3f2d800ef66fe7fd20afef2f Tomcat 7.0: https://github.com/apache/tomcat/commit/53e30390943c18fca0c9e57dbcc14f1c623cfd06

A flaw was found in Apache Tomcat, where the payload length in a WebSocket frame was not correctly validated. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service. The highest threat from this vulnerability is to system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A vulnerability was found in Hibernate-Validator. The SafeHtml validator annotation fails to properly sanitize payloads consisting of potentially malicious code in HTML comments and instructions. This vulnerability can result in an XSS attack.

Last updated 2 August 2024

A flaw was found in Apache Tomcat. When responding to new h2c connection requests, Apache Tomcat could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request. The highest threat from this vulnerability is to data confidentiality.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Apache Tomcat 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46 and 8.5.0 to 8.5.66 did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility to request smuggling when used with a reverse proxy. Specifically: - Tomcat incorrectly ignored the transfer encoding header if the client declared it would only accept an HTTP/1.0 response; - Tomcat honoured the identify encoding; and - Tomcat did not ensure that, if present, the chunked encoding was the final encoding.

In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "limited" path traversal), if the calling code would use the result to construct a path value.

References:

https://www.openwall.com/lists/oss-security/2021/04/12/1 https://issues.apache.org/jira/browse/IO-556

In SQLite before 3.32.3 select.c mishandles query-flattener optimization leading to a multiSelectOrderBy heap overflow because of misuse of transitive properties for constant propagation.

In the Jakarta Expression Language implementation 3.0.3 and earlier, a bug in the ELParserTokenManager enables invalid EL expressions to be evaluated as if they were valid.

In JUnit4 before version 4.13.1, the test rule TemporaryFolder contains a local information disclosure vulnerability. On Unix like systems, the system's temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system. This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability. This vulnerability impacts you if the JUnit tests write sensitive information, like API keys or passwords, into the temporary folder, and the JUnit tests execute in an environment where the OS has other untrusted users. Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using. For Java 1.7 and higher users: this vulnerability is fixed in 4.13.1. For Java 1.6 and lower users: no patch is available, you must use the workaround below. If you are unable to patch, or are stuck running on Java 1.6, specifying the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability. For more information, including an example of vulnerable code, see the referenced GitHub Security Advisory.

References https://github.com/junit-team/junit4/blob/7852b90cfe1cea1e0cdaa19d490c83f0d8684b50/doc/ReleaseNotes4.13.1.md https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp https://junit.org/junit4/javadoc/4.13/org/junit/rules/TemporaryFolder.html

A flaw was found in xstream, a simple library used to serialize objects to XML and back again. This flaw allows a remote attacker to load and execute arbitrary code from a remote host by manipulating the processed input stream.

A flaw was found in velocity. An attacker, able to modify Velocity templates, may execute arbitrary Java code or run arbitrary system commands with the same privileges as the account running the Servlet container. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

In Spring Framework, versions 5.2.x prior to 5.2.15 and versions 5.3.x prior to 5.3.7, a WebFlux application is vulnerable to a privilege escalation: by (re)creating the temporary storage directory, a locally authenticated malicious user can read or modify files that have been uploaded to the WebFlux application, or overwrite arbitrary files with multipart request data.

Impact If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.

In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked.

An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like:

POST / HTTP/2 :authority:: externaldomain.com Content-Length: 4

asdfGET /evilRedirect HTTP/1.1 Host: internaldomain.com

Users are only affected if all of this is true: HTTP2MultiplexCodec or Http2FrameCodec is used Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects These HTTP/1.1 objects are forwarded to another remote peer.

Patches This has been patched in 4.1.60.Final

Workarounds The user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec.

References Related change to workaround the problem: https://github.com/Netflix/zuul/pull/980

Impact The content-length header is not correctly validated if the request only use a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1

This is a followup of https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpj which did miss to fix this one case.

Patches This was fixed as part of 4.1.61.Final

Workarounds Validation can be done by the user before proxy the request by validating the header.

A vulnerability was found in lz4, where a potential memory corruption due to an integer overflow bug which caused one of the memmove arguments to become negative. Depending on how the library was compiled this will hit an assert() inside the library and dump core, leaving a 4GB core file, or it wil go into libc and crash inside the memmove() function.

Reference: https://github.com/lz4/lz4/pull/972