NVD Listing: NVD - CVE-2024-38828
Spring MVC controller methods with an @RequestBody byte[] method parameter are vulnerable to a DoS attack.
Tomcat used the same limit for both request parameters and parts in a multipart request. Since uploaded parts also include headers which must be retained, processing multipart requests can result in significantly more memory usage. A specially crafted request that used a large number of parts could trigger excessive memory usage leading to a DoS. The maximum number of parts is now configurable (maxPartCount on the Connector) with a default of 10 parts.
New Configuration Options:
Tomcat now supports two new attributes on the <Connector> element to mitigate excessive memory usage from multipart requests:maxPartCount: Maximum number of parts allowed in a multipart/form-data request. Default: 50.maxPartHeaderSize: Maximum header size (in bytes) allowed per part. Default: 512.
Example Configuration:
Add the following to your server.xml Connector configuration:
<Connector port="8080"protocol="HTTP/1.1"maxPartCount="20"maxPartHeaderSize="1024" ... />
This example limits requests to 20 parts, with each part's headers limited to 1024 bytes.
Expected Error When Limits Are Exceeded:
If a request exceeds either limit, Tomcat will reject the request and respond with:
HTTP Status 500 – Internal Server Error
Org.apache.tomcat.util.http.fileupload.impl.FileCountLimitExceededException: attachment
or
HTTP Status 500 – Internal Server Error
org.apache.tomcat.util.http.fileupload.impl.FileUploadBase$FileUploadIOException: org.apache.tomcat.util.http.fileupload.impl.PartHeaderLimitExceededException: attachment
The error message will indicate whether the part count or header size limit was violated.
Apache Commons FileUpload provided a hard-coded limit of 10kB for the size of the headers associated with a multipart request. A specially crafted request that used a large number of parts with large headers could trigger excessive memory usage leading to a DoS. This limit is now configurable (maxPartHeaderSize on the Connector) with a default of 512 bytes.
New Configuration Options:
Tomcat now supports two new attributes on the <Connector> element to mitigate excessive memory usage from multipart requests:maxPartCount: Maximum number of parts allowed in a multipart/form-data request. Default: 50.maxPartHeaderSize: Maximum header size (in bytes) allowed per part. Default: 512.
Example Configuration:
Add the following to your server.xml Connector configuration:
<Connector port="8080"protocol="HTTP/1.1"maxPartCount="20"maxPartHeaderSize="1024" ... />
This example limits requests to 20 parts, with each part's headers limited to 1024 bytes.
Expected Error When Limits Are Exceeded:
If a request exceeds either limit, Tomcat will reject the request and respond with:
HTTP Status 500 – Internal Server Error
Org.apache.tomcat.util.http.fileupload.impl.FileCountLimitExceededException: attachment
or
HTTP Status 500 – Internal Server Error
org.apache.tomcat.util.http.fileupload.impl.FileUploadBase$FileUploadIOException: org.apache.tomcat.util.http.fileupload.impl.PartHeaderLimitExceededException: attachment
The error message will indicate whether the part count or header size limit was violated.
NVD Listing: NVD - CVE-2025-22235
EndpointRequest.to() creates a matcher for null/** if the actuator endpoint, for which the EndpointRequest has been created, is disabled or not exposed. Your application may be affected by this if all the following conditions are met: * You use Spring Security * EndpointRequest.to() has been used in a Spring Security chain configuration * The endpoint which EndpointRequest references is disabled or not exposed via web * Your application handles requests to /null and this path needs protection You are not affected if any of the following is true: * You don't use Spring Security * You don't use EndpointRequest.to() * The endpoint which EndpointRequest.to() refers to is enabled and is exposed * Your application does not handle requests to /null or this path does not need protection
OL CVE Issue Summary:
Fix improves HTTP/2 connection handling to prevent excessive resource consumption caused by malicious stream lifecycle behavior, such as rapid stream creation and reset patterns. The update strengthens overhead accounting and connection protection
mechanisms to mitigate memory exhaustion and denial-of-service risks, adds safeguards to prevent abnormal client behavior from bypassing connection limits, and reduces the likelihood of Out-Of-Memory (OOM) conditions and connection instability when processing malformed or abusive HTTP/2 traffic.
NVD Listing: NVD - CVE-2024-38807
Applications that use spring-boot-loader or spring-boot-loader-classic and contain custom code that performs signature verification of nested jar files may be vulnerable to signature forgery where content that appears to have been signed by one signer has, in fact, been signed by another.
OL CVE Issue Summary:
Spring Framework could fail to detect security annotations declared on methods in generic superclasses or interfaces,
potentially causing authorization checks to be skipped when using @EnableMethodSecurity. This release corrects annotation resolution across parameterized type hierarchies to ensure method-level security is consistently enforced.
OL CVE Issue Summary:
Apache Kafka: Possible RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration
OL CVE Issue Summary:
Apache Kafka: Possible RCE attack via SASL JAAS LdapLoginModule configuration
OL CVE Issue Summary:
Apache Kafka Client: Arbitrary file read and SSRF vulnerability
