PT-2026-83787

CVE-2026-71257

·

Published

2026-08-31

·

Updated

2026-09-01

Description by

CVSS 3.1
7.5
High
MetricsAV: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.
Exploitability
Fix
Impacts
Researchers
Vendors
Affected products
Related identifiers
Found an issue in the description? Have something to add? Feel free to write us 👾