Severity: important
CVSS 4.0: 8.3 (high)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
Affected versions:
- Apache Wicket (org.apache.wicket:wicket-core) 9.14.0 through 9.24.0
- Apache Wicket (org.apache.wicket:wicket-core) 10.0.0 through 10.9.1
Description:
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.
Credit:
Emond Papegaaij (finder)
References:
https://wicket.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-84170
