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 jackson-databind 2.x in versions prior to 2.9.10.4. The interaction between serialization gadgets and typing is mishandled. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind 2.x in versions prior to 2.9.10.4. The interaction between serialization gadgets and typing is mishandled. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind 2.x. FasterXML jackson-databind 2.x 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 2.x prior to version 2.9.10.4. The interaction between serialization gadgets and typing is mishandled in the bus-proxy. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind 2.x in versions prior to 2.9.10.4. The interaction between serialization gadgets and typing is mishandled. The highest threat from this vulnerability is to data confidentiality.

A flaw was found in jackson-databind 2.x in versions prior to 2.9.10.4. FasterXML jackson-databind 2.x 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 2.x in versions prior to 2.9.10.4. FasterXML jackson-databind 2.x 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 2.x in versions prior to 2.9.10.4. The interaction between serialization gadgets and typing is mishandled. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind 2.x in versions prior to 2.9.10.4. FasterXML jackson-databind 2.x 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 2.x in versions prior to 2.9.10.5. FasterXML jackson-databind 2.x 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 2.x in versions prior to 2.9.10.5. FasterXML jackson-databind 2.x 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 2.x in versions prior to 2.9.10.5. The interaction between serialization gadgets and typing is mishandled. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind 2.x in versions prior to 2.9.10.5. FasterXML jackson-databind 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 discovered in the jetty-server, where if an exception is thrown from the SessionListener#sessionDestroyed() method, then the session ID is not invalidated in the session ID manager. On deployments with clustered sessions and multiple contexts, this could result in a session not being invalidated and a shared-computer application being left logged in. The highest threat from this vulnerability is to data confidentiality and integrity.

Apache CXF could allow a remote attacker to obtain sensitive information, caused by a flaw when ships with OpenId Connect JWK Keys service. By accessing the JWK keystore file, an attacker could exploit this vulnerability to obtain the public keys in JWK format, and use this information to launch further attacks against the affected system.

A vulnerability in the JsonMapObjectReaderWriter of Apache CXF allows an attacker to submit malformed JSON to a web service, which results in the thread getting stuck in an infinite loop, consuming CPU indefinitely. This issue affects Apache CXF versions prior to 3.4.4; Apache CXF versions prior to 3.3.11.

Apache CXF is vulnerable to a denial of service, caused by improper validation of requesturi parameter by the OAuth 2 authorization service. By sending a specially-crafted request, a remote attacker could exploit this vulnerability to cause a denial of service condition on the authorization server.

Apache HTTP Server versions 2.4.20 to 2.4.43. A specially crafted value for the 'Cache-Digest' header in a HTTP/2 request would result in a crash when the server actually tries to HTTP/2 PUSH a resource afterwards. Configuring the HTTP/2 feature via "H2Push off" will mitigate this vulnerability for unpatched servers.

Apache CXF has the ability to integrate with JMX by registering an InstrumentationManager extension with the CXF bus. If the createMBServerConnectorFactory property of the default InstrumentationManagerImpl is not disabled, then it is vulnerable to a man-in-the-middle (MITM) style attack. An attacker on the same host can connect to the registry and rebind the entry to another server, thus acting as a proxy to the original. They are then able to gain access to all of the information that is sent and received over JMX.

A flaw was found in Apache httpd in versions 2.4.20 to 2.4.43. Logging using the wrong pool by modhttp2 at debug/trace log level may lead to potential crashes and denial of service. The highest threat from this vulnerability is to system availability.

A flaw was found in Apache httpd in versions 2.4.32 to 2.4.46. The uwsgi protocol does not serialize more than 16K of HTTP header leading to resource exhaustion and denial of service. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Last updated 18 August 2025

Impact When using SSL/TLS with Jetty, either with HTTP/1.1, HTTP/2, or WebSocket, the server may receive an invalid large (greater than 17408) TLS frame that is incorrectly handled, causing CPU resources to eventually reach 100% usage.

Workarounds

The problem can be worked around by compiling the following class: java package org.eclipse.jetty.server.ssl.fix6072;

import java.nio.ByteBuffer; import javax.net.ssl.SSLEngine; import javax.net.ssl.SSLEngineResult; import javax.net.ssl.SSLException; import javax.net.ssl.SSLHandshakeException;

import org.eclipse.jetty.io.EndPoint; import org.eclipse.jetty.io.ssl.SslConnection; import org.eclipse.jetty.server.Connector; import org.eclipse.jetty.server.SslConnectionFactory; import org.eclipse.jetty.util.BufferUtil; import org.eclipse.jetty.util.annotation.Name; import org.eclipse.jetty.util.ssl.SslContextFactory;

public class SpaceCheckingSslConnectionFactory extends SslConnectionFactory { public SpaceCheckingSslConnectionFactory(@Name("sslContextFactory") SslContextFactory factory, @Name("next") String nextProtocol) { super(factory, nextProtocol); }

@Override protected SslConnection newSslConnection(Connector connector, EndPoint endPoint, SSLEngine engine) { return new SslConnection(connector.getByteBufferPool(), connector.getExecutor(), endPoint, engine, isDirectBuffersForEncryption(), isDirectBuffersForDecryption()) { @Override protected SSLEngineResult unwrap(SSLEngine sslEngine, ByteBuffer input, ByteBuffer output) throws SSLException { SSLEngineResult results = super.unwrap(sslEngine, input, output);

if ((results.getStatus() == SSLEngineResult.Status.BUFFERUNDERFLOW || results.getStatus() == SSLEngineResult.Status.OK && results.bytesConsumed() == 0 && results.bytesProduced() == 0) && BufferUtil.space(input) == 0) { BufferUtil.clear(input); throw new SSLHandshakeException("Encrypted buffer max length exceeded"); } return results; } }; } } This class can be deployed by: + The resulting class file should be put into a jar file (eg sslfix6072.jar) + The jar file should be made available to the server. For a normal distribution this can be done by putting the file into ${jetty.base}/lib + Copy the file ${jetty.home}/modules/ssl.mod to ${jetty.base}/modules + Edit the ${jetty.base}/modules/ssl.mod file to have the following section:

[lib] lib/sslfix6072.jar

+ Copy the file ${jetty.home}/etc/jetty-https.xml and${jetty.home}/etc/jetty-http2.xml to ${jetty.base}/etc + Edit files ${jetty.base}/etc/jetty-https.xml and ${jetty.base}/etc/jetty-http2.xml, changing any reference of org.eclipse.jetty.server.SslConnectionFactory to org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory. For example: xml <Call name="addIfAbsentConnectionFactory"> <Arg> <New class="org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory"> <Arg name="next">http/1.1</Arg> <Arg name="sslContextFactory"><Ref refid="sslContextFactory"/></Arg> </New> </Arg> </Call> + Restart Jetty

Eclipse Jetty could allow a remote authenticated attacker to obtain sensitive information, caused by a flaw when the ${jetty.base} directory or the ${jetty.base}/webapps directory is a symlink. By sending a specially-crafted request, an attacker could exploit this vulnerability to obtain webapp directory contents information, and use this information to launch further attacks against the affected system.

A resource consumption vulnerability was discovered in apache-commons-compress in the way NioZipEncoding encodes filenames. Applications that use Compress to create archives, with one of the filenames within the archive being controlled by the user, may be vulnerable to this flaw. A remote attacker could exploit this flaw to cause an infinite loop during the archive creation, thus leading to a denial of service.