CVE-2026-71257: Apache Wicket: Configured file upload limits are not enforced when the multipart request has already been parsed
Apache Wicket enforces the upload limits configured on a form or upload field while parsing a multipart request with Apache Commons FileUpload. If the request body has already been consumed by another component, Commons FileUpload returns no items and Wicket falls back to reading the upload through HttpServletRequest#getParts(). The per-file size limit (for example Form#setFileMaxSize) and the file count limit (Form#setFileCountMax) are not applied to the parts obtained that way, and no exception is raised, so the upload is processed as though those limits had been satisfied. A remote uploader can therefore submit files that are larger, or more numerous, than the application permits, up to whatever the component that parsed the request allows. A part carrying no Content-Type header is additionally read into memory in full during parsing, so the size of that allocation is determined by the request and bounded only by those same external limits.
The total upload size limit (Form#setMaxSize) is not affected. Commons FileUpload compares the declared Content-Length against it before reading the body, so a request declaring an oversized length is rejected before the fallback is reached.
The fallback is reached in deployments where a servlet or filter has already parsed the request body — for example a servlet annotated with @MultipartConfig, Spring Boot's multipart resolver, or any filter that calls HttpServletRequest#getParameter() on a multipart request. It applies to the Wicket components that accept uploads on that path, including Form with FileUploadField, FileUploadToResourceField and AjaxFileDropBehavior. Applications that configure neither a per-file nor a file-count limit are not affected, as Wicket applies neither by default.
This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0.
Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. As a workaround, configure equivalent limits in the component that parses the request — for example spring.servlet.multipart.max-file-size and max-request-size, or maxFileSize and maxRequestSize in @MultipartConfig or in the web.xml <multipart-config> element.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache Wicketto a version that resolves this vulnerability.Fixed in 8.19.0 - Upgrade
Upgrade
Apache Wicketto a version that resolves this vulnerability.Fixed in 9.24.0 - Upgrade
Upgrade
Apache Wicketto a version that resolves this vulnerability.Fixed in 10.11.0 - Configuration
As a workaround when Wicket file upload limits are not enforced after the multipart request has been parsed, configure equivalent multipart limits in the component that parses the request; set spring.servlet.multipart.max-file-size to the same per-file limit you intend to enforce in Wicket (so Commons FileUpload rejects oversize parts before fallback).
Request multipart parser / server configuration (workaround) spring.servlet.multipart.max-file-size = set an equivalent per-file limit - Configuration
As a workaround when Wicket file upload limits are not enforced after the multipart request has been parsed, configure equivalent multipart limits in the component that parses the request; set spring.servlet.multipart.max-request-size to the same total request size limit you intend to enforce in Wicket.
Request multipart parser / server configuration (workaround) spring.servlet.multipart.max-request-size = set an equivalent total request size limit - Configuration
As a workaround when Wicket file upload limits are not enforced after the multipart request has been parsed, configure equivalent multipart limits in the component that parses the request; set maxFileSize to the same per-file limit to be enforced.
Request multipart parser / Jakarta EE multipart config (workaround) maxFileSize = set an equivalent per-file limit - Configuration
As a workaround when Wicket file upload limits are not enforced after the multipart request has been parsed, configure equivalent multipart limits in the component that parses the request; set maxRequestSize to the same total request size limit to be enforced.
Request multipart parser / Jakarta EE multipart config (workaround) maxRequestSize = set an equivalent total request size limit - Configuration
As a workaround when Wicket file upload limits are not enforced after the multipart request has been parsed, configure equivalent multipart limits in the component that parses the request; set the web.xml <multipart-config> maxFileSize to the same per-file limit to be enforced.
web.xml <multipart-config> (workaround) <multipart-config> maxFileSize = set an equivalent per-file limit - Configuration
As a workaround when Wicket file upload limits are not enforced after the multipart request has been parsed, configure equivalent multipart limits in the component that parses the request; set the web.xml <multipart-config> maxRequestSize to the same total request size limit to be enforced.
web.xml <multipart-config> (workaround) <multipart-config> maxRequestSize = set an equivalent total request size limit
Event History
Frequently Asked Questions
What conditions are required for an attacker to bypass the configured per-file and file-count limits?
A remote uploader must send a multipart request that has already been consumed by another component before Wicket processes it. This causes Wicket to use HttpServletRequest#getParts() instead of Apache Commons FileUpload, bypassing the per-file and file-count checks.
Are all configured upload limits bypassed?
No. The total upload size limit configured with Form#setMaxSize remains enforced because Commons FileUpload checks the declared Content-Length before the fallback path is reached. The affected limits are the per-file size limit and file count limit.
What limits constrain an oversized or excessive upload in the affected path?
The upload is constrained only by limits imposed by the component that parsed the request first. If a part has no Content-Type header, it may also be read fully into memory, with the allocation size bounded only by those same external limits.
Will Wicket report that the configured limits were exceeded?
No. In the fallback path, the upload is processed as though the per-file and file-count limits had been satisfied, and no exception is raised for exceeding those limits.