CVE-2026-71257 is a flaw in Apache Wicket where per-file and file-count upload limits are not enforced when another component already parsed the request. The record scores it high (CVSS 7.5) and Apache rates it moderate. Upgrade to Wicket 8.19.0, 9.24.0 or 10.11.0.
What's affected
Apache Wicket (org.apache.wicket:wicket-core) 8.0.0 through 8.18.0, 9.0.0 through 9.23.0 and 10.0.0 through 10.10.0. Apache recommends upgrading to 8.19.0, 9.24.0 or 10.11.0. Users of Wicket 7.x or older should move to a supported version.
The weakness is CWE-770, allocation of resources without limits. Wicket normally enforces limits such as Form#setFileMaxSize and Form#setFileCountMax while parsing with Apache Commons FileUpload. If another component has already consumed the body, Commons FileUpload returns nothing and Wicket falls back to HttpServletRequest#getParts(), where those two limits are not applied and no error is raised. A part without a Content-Type header is also read fully into memory.
The total size limit (Form#setMaxSize) is not affected. The fallback is reached when a servlet or filter has already parsed the request, for example @MultipartConfig, Spring Boot's multipart resolver, or a filter calling getParameter() on a multipart request. Applications that set neither per-file nor file-count limits are not affected.
Severity differs by source: the record scores 7.5 high, and the Apache announcement says moderate.
How to check if you're exposed
Check the Wicket version in your build:
mvn dependency:tree -Dincludes=org.apache.wicket:wicket-core
For Gradle, run gradle dependencies and search for wicket-core. Versions in the three ranges above are affected.
Then check whether the fallback path applies. Search your code and configuration for Form#setFileMaxSize or setFileCountMax, which are the limits that stop being enforced. Then look for anything that reads multipart bodies earlier: a servlet with @MultipartConfig, Spring Boot multipart settings, or filters that call getParameter().
free in-browser dependency scan reads a pom.xml or lockfile in the browser and flags the vulnerable wicket-core version.
What to do now
- Find the wicket-core version with mvn dependency:tree or gradle dependencies.
- Upgrade to 8.19.0, 9.24.0 or 10.11.0, whichever matches your major line.
- If you cannot upgrade, set equivalent limits where the request is parsed, such as spring.servlet.multipart.max-file-size and max-request-size, or maxFileSize and maxRequestSize in @MultipartConfig, as Apache suggests.
- Check for filters that parse multipart bodies before Wicket does.
- Move off Wicket 7.x or older if you still run it.
Why it matters
CWE-770 is simple: a limit that exists in configuration does not hold on every code path. Here the limit lives in one parser, and a second path reaches the same data with no limit and no error. The developer sees the setting, the reviewer sees the setting, and the setting is quietly bypassed.
The effect is mostly denial of service. Larger or more numerous uploads than allowed can exhaust disk or memory, and a part without a content type is held in memory in full. The advisory notes that the declared total length check still works, so the worst case is bounded by external limits.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does the fix need code changes?
Apache recommends upgrading to 8.19.0, 9.24.0 or 10.11.0. As a workaround you can set equivalent limits in the component that parses the request.
Sources
Last reviewed: 18 October 2026.
