PT-2026-83787
CVE-2026-71257
·
Published
2026-08-31
·
Updated
2026-09-01
Description by
CVSS 3.1
7.5
HighMetricsAV: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. Found an issue in the description? Have something to add? Feel free to write us 👾