PT-2026-83787 · Vmware+1 · Spring Boot+1
CVSS v3.1
7.5
High
| Vector | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
Name of the Vulnerable Software and Affected Versions
Apache Wicket versions 8.0.0 through 8.18.0
Apache Wicket versions 9.0.0 through 9.23.0
Apache Wicket versions 10.0.0 through 10.10.0
Description
An issue exists when parsing multipart requests where the request body has already been consumed by another component, such as a servlet annotated with
@MultipartConfig, Spring Boot's multipart resolver, or a filter calling HttpServletRequest#getParameter(). In these scenarios, the system falls back to reading uploads via HttpServletRequest#getParts(), which bypasses the per-file size limit configured via Form#setFileMaxSize() and the file count limit configured via Form#setFileCountMax(). Consequently, a remote uploader can submit files that exceed the application's permitted size or quantity. Additionally, parts lacking a Content-Type header are read entirely into memory, with the allocation size determined by the request and limited only by external constraints. This affects components that accept uploads, including Form with FileUploadField, FileUploadToResourceField, and AjaxFileDropBehavior.Recommendations
Upgrade Apache Wicket versions 8.0.0 through 8.18.0 to version 8.19.0.
Upgrade Apache Wicket versions 9.0.0 through 9.23.0 to version 9.24.0.
Upgrade Apache Wicket versions 10.0.0 through 10.10.0 to version 10.11.0.
As a workaround, configure equivalent limits in the component that parses the request, such as
spring.servlet.multipart.max-file-size and max-request-size, or maxFileSize and maxRequestSize within @MultipartConfig or the web.xml <multipart-config> element.Fix
DoS
Allocation of Resources Without Limits
Found an issue in the description? Have something to add? Feel free to write us 👾
Weakness Enumeration
Related Identifiers
Affected Products
Apache Wicket
Spring Boot