CVE-2026-71257: Apache Wicket File Upload DoS Vulnerability

CVE-2026-71257 Overview

Apache Wicket contains a resource consumption vulnerability [CWE-770] in its multipart request handling. When another servlet or filter has already consumed the request body, Apache Commons FileUpload returns no items and Wicket falls back to HttpServletRequest#getParts(). The fallback path does not enforce Form#setFileMaxSize or Form#setFileCountMax, allowing remote attackers to upload files larger and more numerous than the application permits. Additionally, parts without a Content-Type header are read fully into memory, with allocation size controlled by the request. The issue affects Apache Wicket versions 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0.

Critical Impact
Remote attackers can bypass configured per-file and file-count upload limits, exhausting server memory and disk resources without authentication.

Affected Products

Apache Wicket 8.0.0 through 8.18.0
Apache Wicket 9.0.0 through 9.23.0
Apache Wicket 10.0.0 through 10.10.0

Discovery Timeline

2026-08-31 - CVE-2026-71257 published to NVD
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-71257

Vulnerability Analysis

Apache Wicket enforces upload limits by parsing multipart requests through Apache Commons FileUpload. Commons FileUpload compares the declared Content-Length header against Form#setMaxSize before reading the body, so this total-size check remains effective. However, when a different component in the servlet chain has already consumed the request body, Commons FileUpload returns an empty item list.

Wicket then falls back to reading uploads via HttpServletRequest#getParts(). This fallback path fails to apply the per-file size limit (Form#setFileMaxSize) and file-count limit (Form#setFileCountMax). No exception is raised, and the upload proceeds as if limits were satisfied. Parts lacking a Content-Type header are additionally buffered into memory in full during parsing.

The issue affects Form components using FileUploadField, FileUploadToResourceField, and AjaxFileDropBehavior. Applications that configure neither a per-file nor a file-count limit are unaffected because Wicket applies neither by default.

Root Cause

The Wicket fallback path relies on the servlet container's multipart parser rather than re-applying application-level limits. Because the container's getParts() implementation only honors its own configuration (for example @MultipartConfig values or Spring Boot's spring.servlet.multipart settings), Wicket-level restrictions are silently ignored on this code path.

Attack Vector

The vulnerability is reachable in deployments where another servlet or filter parses the request body first. Common triggers include a servlet annotated with @MultipartConfig, Spring Boot's multipart resolver, or any filter that calls HttpServletRequest#getParameter() on a multipart request. A remote attacker sends a multipart POST to a vulnerable Wicket upload endpoint with a Content-Length under Form#setMaxSize but containing many parts or oversized individual files. The upload is accepted, driving memory and disk consumption toward container-level limits and enabling denial of service.

Refer to the Apache Mailing List Thread and the OpenWall OSS-Security Post for the vendor's technical description.

Detection Methods for CVE-2026-71257

Indicators of Compromise

Multipart POST requests to Wicket upload endpoints containing more file parts than the application's documented Form#setFileCountMax value.
Individual multipart parts exceeding Form#setFileMaxSize but with an aggregate Content-Length below Form#setMaxSize.
Multipart parts submitted without a Content-Type header that correspond to large in-memory allocations in the JVM.

Detection Strategies

Inventory applications for Apache Wicket versions in the affected ranges and cross-reference deployments that also use @MultipartConfig, Spring Boot multipart, or filters invoking getParameter() on multipart requests.
Instrument JVM heap and garbage collection metrics on Wicket application servers to flag sudden allocation spikes during upload processing.
Inspect application server access logs for repeated multipart POSTs to FileUploadField, FileUploadToResourceField, or AjaxFileDropBehavior endpoints from the same source.

Monitoring Recommendations

Alert on HTTP 200 responses to upload endpoints where the request contained an unusually high number of Content-Disposition: form-data; name= boundaries.
Correlate application memory pressure and OOM events with upstream multipart request patterns using a centralized log platform.
Track servlet container multipart configuration drift so limits imposed at the container level do not silently exceed application expectations.

How to Mitigate CVE-2026-71257

Immediate Actions Required

Upgrade Apache Wicket to version 8.19.0, 9.24.0, or 10.11.0, which fix the fallback path.
Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported and patched branch.
Audit servlet and filter chains to identify components that parse multipart request bodies before Wicket receives them.

Patch Information

Apache has released fixed versions 8.19.0, 9.24.0, and 10.11.0. See the Apache Mailing List Thread for the official announcement. The patches ensure per-file size and file-count limits are enforced on the HttpServletRequest#getParts() fallback path.

Workarounds

Configure equivalent per-file and total-request limits in the component that parses the request, such as spring.servlet.multipart.max-file-size and spring.servlet.multipart.max-request-size for Spring Boot.
Set maxFileSize and maxRequestSize in the @MultipartConfig annotation or the <multipart-config> element of web.xml to match the intended Wicket limits.
Remove or reorder filters that call HttpServletRequest#getParameter() on multipart requests when they are not required upstream of Wicket.

bash

# Example web.xml multipart-config workaround aligning container limits with Wicket expectations
<multipart-config>
    <max-file-size>10485760</max-file-size>
    <max-request-size>52428800</max-request-size>
    <file-size-threshold>0</file-size-threshold>
</multipart-config>