Skip to main content
EPSS 0.7%top 47%

CVE-2026-71257: CWE-770 Allocation of Resources Without Limits or Throttling in Apache Software Foundation Apache Wicket

0
High
Published: 08/31/2026 (08/31/2026, 11:45:49 UTC)
Source: CVE Database V5
Vendor/Project: Apache Software Foundation
Product: Apache Wicket

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.

CVSS v3.1

Score 7.5high

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Affected software

Apache Software Foundation

Apache Wicket

Affected versions
>=8.0.0 <=8.18.0>=9.0.0 <=9.23.0>=10.0.0 <=10.10.0
Apache Software Foundation/org.apache.wicket:wicket-core
pkg:maven/Apache Software Foundation/org.apache.wicket:wicket-core
Affected versions
>=8.0.0 <=8.18.0>=9.0.0 <=9.23.0>=10.0.0 <=10.10.0

Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.

AI-Powered Analysis

Machine-generated threat intelligence

AILast updated: 09/07/2026, 14:26:23 UTC

Technical Analysis

Apache Wicket enforces configured per-file and file-count upload limits when parsing multipart requests via Apache Commons FileUpload. However, if the request body has already been consumed by another servlet or filter (e.g., via @MultipartConfig or Spring Boot multipart resolver), Commons FileUpload returns no items, causing Wicket to fallback to HttpServletRequest#getParts(). This fallback bypasses the per-file and file-count limits, allowing a remote uploader to submit files exceeding those limits without triggering exceptions. Additionally, parts without a Content-Type header are fully read into memory, potentially causing large memory allocations. The total upload size limit remains enforced by Commons FileUpload before fallback. This 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. The issue is fixed in versions 8.19.0, 9.24.0, and 10.11.0. Users of unsupported versions (7.x and older) should upgrade to supported versions. As a workaround, equivalent limits should be configured in the component that parses the request body first, such as spring.servlet.multipart.max-file-size or max-request-size, or the @MultipartConfig or web.xml multipart-config settings.

Potential Impact

This vulnerability allows remote attackers to bypass configured per-file size and file count upload limits in Apache Wicket when the multipart request body is pre-consumed by another component. This can lead to processing uploads larger or more numerous than intended, potentially causing resource exhaustion or denial of service due to large memory allocations. The total upload size limit remains enforced, limiting the overall request size. No direct confidentiality or integrity impact is described.

Mitigation Recommendations

A fix is available by upgrading Apache Wicket to versions 8.19.0, 9.24.0, or 10.11.0. Users on unsupported versions should upgrade to a supported version. As a workaround, configure equivalent upload limits in the component that parses the request body before Wicket, such as spring.servlet.multipart.max-file-size and max-request-size, or the maxFileSize and maxRequestSize attributes in @MultipartConfig or the web.xml <multipart-config> element. This ensures upload limits are enforced even if Wicket falls back to HttpServletRequest#getParts().

Pro Console: star threats, build custom feeds, automate alerts via Slack, email & webhooks.Upgrade to Pro

Technical Details

Data Version
5.2
Assigner Short Name
apache
Date Reserved
2026-08-05T11:48:12.846Z
State
PUBLISHED

Threat ID: 6a956b1facd9273b490c5d4b

Added to database: 08/31/2026, 11:53:03 UTC

Last enriched: 09/07/2026, 14:26:23 UTC

Last updated: 10/13/2026, 18:48:23 UTC

Views: 83

Community Reviews

0 reviews

Crowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.

Sort by
Loading community insights…

Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.

Actions

PRO

Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.

Please log in to the Console to use AI analysis features.

Need more coverage?

Upgrade to Pro Console for AI refresh and higher limits.

For incident response and remediation, OffSeq services can help resolve threats faster.

Latest Threats

Breach by OffSeqOFFSEQFRIENDS — 25% OFF

Check if your credentials are on the dark web

Instant breach scanning across billions of leaked records. Free tier available.

Scan now
OffSeq TrainingCredly Certified

Lead Pen Test Professional

Technical5-day eLearningPECB Accredited
View courses