IT SBIT Services
Schneeberger
DEEN
CVE tracker

Apache Wicket: Unbounded resource consumption in standalone file upload resource

CVE-2026-84170High 8.3

← All vulnerabilities

Summary

The standalone file upload resource of Apache Wicket takes the upload limits (total size, single part size, part count) from request parameters instead of the application configuration, so configured limits have no effect when the client sends its own values. An unauthenticated remote attacker can send large uploads that fill the container temporary directory, the uploads folder and the heap, causing denial of service and leaving files in the uploads folder. The issue only applies to applications that use FileUploadToResourceField or mount FileUploadResourceReference.

Affected

  • Apache Wicket 9.14.0 through 9.24.0
  • Apache Wicket 10.0.0 through 10.9.1
  • Applications using FileUploadToResourceField or FileUploadResourceReference
  • Apache Wicket 8.x is not affected (the component does not exist there)
  • Form with FileUploadField and AjaxFileDropBehavior are not affected

Fixed in

  • Apache Wicket 9.25.0 (note: 9.x is end-of-life after this release)
  • Apache Wicket 10.12.0 (LTS)
  • Apache Wicket 9.24.0 does not fix this CVE

Workaround

  • Authorize the upload resource in the application so that anonymous requests are rejected
  • Limit the request body size for the upload mount path at the reverse proxy or servlet container
  • Monitor the container temporary directory and the uploads folder for unusual growth

Exploitation

  • Not known to be exploited in the wild according to available sources
  • No public proof of concept found in the research performed
  • CVSS 4.0 base score 8.3 (CNA score); NVD enrichment pending

Our recommendation

  • Search the codebase for FileUploadToResourceField and FileUploadResourceReference; if neither is used, no action is needed for this CVE
  • If affected, upgrade to Apache Wicket 10.12.0 for 10.x, or move to 10.12.0 from 9.x because 9.x is end-of-life
  • Until the upgrade is done, authorize the upload resource and cap the request size at the reverse proxy
  • Monitor disk and heap usage of the affected application

Public exploits

PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.

Research sources

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 2 Nov 2026, 00:21.

Original description (NVD)

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.

NVD references (1)

Sources

The tracker combines official, freely usable data sources – updated continuously:

This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.

Affected? We can help.

We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.