Read the docs
TI-2026-83655 Aliases CVE-2026-84170GHSA-w478-29fp-9q59

Apache Wicket file upload resource ignores configured upload limits

Priority LOW 36CWE-770Published · Updated

Key facts

Attack vector
Network
Privileges required
None
User interaction
None
Attack complexity
Low
Attack requirements
Present
Impact type
Denial of service
Confidentiality · integrity · availability
None · Low · High
Fix status
No fix listed

Attack profile from CVSS 4.0 · CNA. Fix status from CNA. Impact type from CWE-770.

Summary

Apache Wicket versions from 9.14.0 through 9.24.0 and from 10.0.0 through 10.9.1 are affected. The standalone file upload resource reads its total size, per-part size and part-count limits from request parameters, so limits the application configured are ignored when a client supplies its own values (CWE-770). A remote attacker without authentication can send requests that consume as much disk space or heap memory as the client chooses. Only applications that use FileUploadToResourceField or mount FileUploadResourceReference are affected.

Written with Claude Haiku 5.5 from the sources below · 2026-11-02

Description from the CNA

Allocation of resources without limits or throttling in Apache Wicket. org.apache.wicket.markup.html.form.upload.resource.AbstractFileUploadResource is the server side of the form-less upload offered by FileUploadToResourceField, which posts the selected files to a separately mounted resource rather than through a Form. The resource is an application-wide singleton with no component to consult, so newResourceResponse() takes the three limits that bound the upload - the total request size, the maximum size of a single part and the maximum number of parts - from the request parameters maxSize, fileMaxSize and fileCountMax, and hands them to the multipart parser as they arrive. Nothing binds those numbers to the field that is supposed to be uploading. A request naming a very large maxSize is therefore parsed with no effective ceiling on the total size, and omitting fileMaxSize and fileCountMax leaves the per-part and part-count limits unset as well. The values the application configured through FileUploadToResourceField#setMaxSize(), #setFileMaxSize() and #setFileCountMax() are consulted only when the client omits the corresponding parameter, so against a client that supplies one they have no effect at all. Parts above the parser's in-memory threshold are spooled to the container's temporary directory, and the file parts are then copied into the folder the application's IUploadsFileManager owns, under a sub-folder the request names, where they remain. A part that is not a file is read into the heap in full while the request is parsed. One request, repeatable, can therefore consume as much disk or as much heap as the client chooses to send. The resource carries no authorization annotation and the default authorization strategy permits every resource request, so unless the application authorizes the resource itself the request needs no authentication, no session, no prior page view and no user interaction. An application is affected where it uses FileUploadToResourceField, or mounts FileUploadResourceReference itself. This is not the ordinary upload path: the resource is a singleton that has to be created and mounted deliberately. An application that configures no upload limit at all loses nothing, because Wicket applies no total-size limit of its own by default; what the defect removes is a limit the application set. Uploads through Form with FileUploadField, and through AjaxFileDropBehavior, are not affected, because both read their limits from the component rather than from the request. The upload resource does not exist in the 8.x line. This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.9.1. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue.

Why it matters now

Exploitation None reported CISA SSVC · not in CISA KEV
EPSS 0.00345 28th percentileScored 2026-11-07
Fix No fix listed No fixed version in the sources yet

SSVC decision points

CISA ADP · SSVC 2.0.3

Exploitation
None
Automatable
No
Technical impact
Partial

The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.

Affected products

VendorProductAffected versionsFixed inStatusSource
ApacheApache Wicket9.14.0 – 9.24.0; 10.0.0 – 10.9.1—No fix listedCNA
  • Apache Wicket VendorApache Affected 9.14.0 – 9.24.0; 10.0.0 – 10.9.1 Fixed in — No fix listed CNA

CPE names Threatist (inferred) · 1

Inferred from how NVD named this product before; not given by a source.

CPEVersionsRoleVendor
cpe:2.3:a:apache:wicket:*:*:*:*:*:*:*:*——Apache
  • cpe:2.3:a:apache:wicket:*:*:*:*:*:*:*:* Versions — — ·Apache

Remediation

Upgrade Apache Wicket 9.x to version 9.25.0 and Apache Wicket 10.x to version 10.12.0, which fix the issue.

Written with Claude Haiku 5.5 from the sources below · 2026-11-02

Timeline

  1. 2026-11-01 Threatist record created from CVE-2026-84170
  2. 2026-11-02 Alias added: GHSA-w478-29fp-9q59
  3. 2026-11-04 Priority changed: MEDIUM → LOW
  4. 2026-11-06 CISA SSVC decision points changed

References

  • TI-2025-18529 Apache Tomcat: Potential RCE and/or information disclosure and/or information corruption with partial PUT KEVCVSS 3.1CRITICAL 10.0
  • TI-2024-30292 Apache OFBiz: Confused controller-view authorization logic (forced browsing) KEVCVSS 3.1CRITICAL 9.8
  • TI-2024-26062 Apache OFBiz: Unauthenticated endpoint could allow execution of screen rendering code KEVCVSS 3.1CRITICAL 9.8
  • TI-2024-21190 Apache OFBiz: Path traversal leading to RCE KEVCVSS 3.1CRITICAL 9.8
  • TI-2024-18186 Apache HugeGraph-Server: Command execution in gremlin KEVCVSS 3.1CRITICAL 9.8
  • TI-2023-25106 Deserialization of untrusted data in Apache ActiveMQ KEVCVSS 3.1CRITICAL 10.0
See all 4053 →

Sources