Description
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.
Published: 2026-08-31
Score: 7.5 High
EPSS: < 1% Very Low
KEV: No
Impact: Large or numerous file uploads bypass application limits
Action: Patch Immediately
AI Analysis

Impact

Apache Wicket ignores per‑file and per‑count upload limits when the multipart request has already been parsed by another component. The framework falls back to HttpServletRequest#getParts(), which does not enforce the configured limits and does not raise an exception, allowing an attacker to upload files larger or more numerous than the application intends. A part without a Content‑Type header is read entirely into memory, creating a memory allocation that is only bounded by external limits. This weakness corresponds to insufficient resource allocation and can lead to resource exhaustion or denial of service.

Affected Systems

Apache Software Foundation’s Apache Wicket component is affected. The vulnerability exists in all supported releases from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, and from 10.0.0 through 10.10.0. Apache Wicket 7.x or older releases are not impacted by this CVE.

Risk and Exploitability

EPSS is reported as < 1% and the vulnerability is not listed in CISA KEV. The CVSS score is 7.5, indicating a high likelihood of successful remote attacks. The flaw permits remote actors to bypass configured upload restrictions whenever another servlet, filter, or framework component—such as a Spring Boot multipart resolver—parses the multipart request before Wicket processes it. The attacker can then upload arbitrarily sized or numerous files up to the limits imposed by the initial parser, while the total upload size limit remains enforced. This combination of conditions creates a realistic risk of resource exhaustion or denial of service in affected deployments.

Generated by OpenCVE AI on September 2, 2026 at 02:22 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade Apache Wicket to 8.19.0, 9.24.0, or 10.11.0 or later to apply the vendor fix.
  • Configure equivalent file size and count limits in any component that parses multipart requests first, such as Spring Boot’s multipart resolver or the @MultipartConfig annotation.
  • Implement monitoring or defensive controls to detect abnormal upload volumes, and consider blocking or throttling large uploads before they reach the application.

Generated by OpenCVE AI on September 2, 2026 at 02:22 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 02 Sep 2026 08:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Tue, 01 Sep 2026 22:00:00 +0000

Type Values Removed Values Added
CPEs cpe:2.3:a:apache:wicket:*:*:*:*:*:*:*:*
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

Mon, 31 Aug 2026 21:45:00 +0000

Type Values Removed Values Added
First Time appeared Apache
Apache wicket
Vendors & Products Apache
Apache wicket

Mon, 31 Aug 2026 13:30:00 +0000

Type Values Removed Values Added
References

Mon, 31 Aug 2026 12:00:00 +0000

Type Values Removed Values Added
Description 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.
Title Apache Wicket: Configured file upload limits are not enforced when the multipart request has already been parsed
Weaknesses CWE-770
References

Subscriptions

Apache Wicket
cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-09-01T18:01:24.791Z

Reserved: 2026-08-05T11:48:12.846Z

Link: CVE-2026-71257

cve-icon Vulnrichment

Updated: 2026-08-31T12:16:28.466Z

cve-icon NVD

Status : Modified

Published: 2026-08-31T12:17:56.643

Modified: 2026-09-01T19:17:26.407

Link: CVE-2026-71257

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-02T02:30:04Z

Weaknesses
  • CWE-770

    Allocation of Resources Without Limits or Throttling