CVE-2026-71257
HighCVSS 7.5Exploitation Probability (EPSS)
Elevated risk53th percentile - higher than 53% of all known CVEs
Summary
A vulnerability in Apache Wicket allows bypassing file size and count limits when a multipart request has already been consumed by another component. Wicket then reads uploads via HttpServletRequest#getParts() without applying per-file and file-count limits, allowing larger or more numerous files than permitted. Additionally, a part without a Content-Type header is fully read into memory, potentially causing excessive resource consumption.
Risk Assessment
An attacker can upload files exceeding application limits, potentially leading to memory or disk exhaustion and violation of security policies. This could enable DoS attacks or unauthorized upload of malicious files.
Recommendation
Upgrade Apache Wicket to version 8.19.0, 9.24.0, or 10.11.0 immediately. If upgrading is not possible, configure equivalent limits in the request-parsing component (e.g., spring.servlet.multipart.max-file-size, maxFileSize in @MultipartConfig).
Other vulnerabilities in Apache Wicket
See all- CVE-2026-43646High
Apache Wicket has a vulnerability that exposes sensitive information to unauthorized actors. This affects versions from 8.0.0 to 8.17.0, from 9.0.0 to 9.22.0, and from 10.0.0 to 10.8.0.
- CVE-2014-3526High
Apache Wicket before 1.5.12, 6.x before 6.17.0, and 7.x before 7.0.0-M3 might allow remote attackers to obtain sensitive information via identifiers for storing page markup for temporary user sessions.
- CVE-2016-6806High
Apache Wicket versions 6.x before 6.25.0, 7.x before 7.5.0, and 8.0.0-M1 contain a security vulnerability that improperly handles CSRF prevention, failing to detect some cross-origin requests. The issue also involves not checking all Wicket server-side targets.
- CVE-2014-7808High
Apache Wicket before 1.5.13, 6.x before 6.19.0, and 7.x before 7.0.0-M5 make it easier for attackers to defeat a cryptographic protection mechanism and predict encrypted URLs by leveraging use of CryptoMapper as the default encryption provider.
- CVE-2016-6793Critical
The DiskFileItem class in Apache Wicket 6.x before 6.25.0 and 1.5.x before 1.5.17 allows remote attackers to cause a denial of service (infinite loop) and write to, move, and delete files with the permissions of DiskFileItem. Additionally, if running on a Java VM before 1.3.1, it can execute arbitrary code via a crafted serialized Java object.
- CVE-2026-76986Medium
A cross-site scripting (XSS) vulnerability was found in Apache Wicket in AbstractSingleSelectChoice (base class of DropDownChoice). The default option body is written without escaping, while other options are escaped. Applications overriding getNullValidDisplayValue() or getNullKeyDisplayValue() with attacker-influenced data are affected. Versions 8.0.0-8.18.0, 9.0.0-9.23.0, 10.0.0-10.10.0 are affected.
- CVE-2026-76985Medium
A cross-site scripting (XSS) vulnerability was found in Apache Wicket in AbstractOptions (renders option lists in Palette). Attribute names and values from getAdditionalAttributes are written without escaping. Applications overriding getAdditionalAttributesForChoices, getAdditionalAttributesForSelection, or getAdditionalAttributes with attacker-influenced data are affected. Versions 8.0.0-8.18.0, 9.0.0-9.23.0, 10.0.0-10.10.0 are affected.
- CVE-2026-76984Medium
In Apache Wicket, the MetaDataHeaderItem component improperly neutralizes input during web page generation. Attribute values in <meta> and <link> tags are not properly escaped, allowing injection of additional attributes. Affects versions from 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0.
- CVE-2026-76983Medium
In Apache Wicket, the <wicket:label> tag is rendered without escaping, allowing HTML injection if the label comes from a model containing attacker-controlled data. Affects versions from 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0.
- CVE-2026-76982Medium
XSS vulnerability in Apache Wicket affects the Button component rendered as a <button> element. The constructor clears the escape-model-strings flag, so the model is not encoded when written to the element body, allowing markup injection.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS