CVE-2026-71257
published 2026-08-31CVE-2026-71257: 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…
PriorityP348high7.5CVSS 3.1
AVNACLPRNUINSUCNINAH
EPSS
0.78%
53.5th percentile
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
Affected
6 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| apache | wicket | >= 10.0.0 < 10.11.0 | 10.11.0 |
| apache | wicket | >= 8.0.0 < 8.19.0 | 8.19.0 |
| apache | wicket | >= 9.0.0 < 9.24.0 | 9.24.0 |
| apache_software_foundation | apache_wicket | 10.0.0 – 10.10.0 | — |
| apache_software_foundation | apache_wicket | 8.0.0 – 8.18.0 | — |
| apache_software_foundation | apache_wicket | 9.0.0 – 9.23.0 | — |
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
Apache Wicket enforces the upload limits configured on a form or upload field while parsing a multipart request with Apache Commons FileUpload.
ghsa_unreviewed·2026-08-31
CVE-2026-71257 CWE-770 Apache Wicket enforces the upload limits configured on a form or upload field while parsing a multipart request with Apache Commons FileUpload.
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 addi
VulDB
Apache Wicket unrestricted upload
vuldb·2026-08-30
CVE-2026-71257 [CRITICAL] Apache Wicket unrestricted upload
A vulnerability was found in Apache Wicket. It has been rated as critical. This affects an unknown part. This manipulation causes unrestricted upload.
This vulnerability is handled as CVE-2026-71257. The attack can be initiated remotely. There is not any exploit available.
Suricata
ET WEB_SPECIFIC_APPS BMC FootPrints SEC_TOKEN Extraction Authentication Bypass Attempted (CVE-2025-71257)
suricata·2026-03-18·CVSS 6.9
CVE-2025-71257 [MEDIUM] ET WEB_SPECIFIC_APPS BMC FootPrints SEC_TOKEN Extraction Authentication Bypass Attempted (CVE-2025-71257)
ET WEB_SPECIFIC_APPS BMC FootPrints SEC_TOKEN Extraction Authentication Bypass Attempted (CVE-2025-71257)
Rule: alert http any any -> $HOME_NET any (msg:"ET WEB_SPECIFIC_APPS BMC FootPrints SEC_TOKEN Extraction Authentication Bypass Attempted (CVE-2025-71257)"; flow:established,to_server; http.method; content:"GET"; http.uri; bsize:46; content:"/footprints/servicedesk/passwordreset/request/"; fast_pattern; reference:url,labs.watchtowr.com/thanks-itsms-threat-actors-have-never-been-so-organized-bmc-footprints-pre-auth-remote-code-execution-chains/; reference:cve,2025-71257; classtype:attempted-admin; sid:2068317; rev:1; metadata:affected_product BMC_FootPrints, attack_target Server, tls_state TLSDecrypt, created_at 2026_03_18, cve CVE_2025_71257, deployment Perimeter, deployment Internal,
No public exploits indexed.
No writeups or analysis indexed.
2026-08-31
Published