PT-2026-83787 · Vmware+1 · Spring Boot+1

·

CVE-2026-71257

·

Published

2026-08-31

·

Updated

2026-09-01

CVSS v3.1

7.5

High

VectorAV: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

CVE-2026-71257

Affected Products

Apache Wicket
Spring Boot