Page generated: 09 Nov 2026, 11:41 UTC
← Dashboard

CVE-2026-84170

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 mou…

Read full 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.
CVSS 8.3 (HIGH)

Attention and evidence

HYPE SCORE
0.0/10
REALITY · THREAT PRIORITY
2.9/10
General review priority; not probability

Evidence confidence: Insufficient evidence

Why this priority?
  • Technical severity: CVSS 8.3: +2.91
  • Fresh EPSS: 0.34%: +0.01

General review priority, not probability, victim count or asset-specific risk. A range covers missing CVSS/EPSS inputs within the current evidence state.

Sources: 1 documents and public datasets.

Hype components

Headline sample (25%)
0/100
Press, 30 days (60%)
0/100
Grounded branding (15%)
0/100
HYPE TOTAL0/100

Sources and documents

Latest Vulnerabilities
Technical advisory · 01 Nov 2026, 22:22 · CVE-2026-84170 - Apache Wicket: Configured upload limits are not enforced by the standalone file upload resource

Score evolution

● Hype   ● Reality

Earlier evidence-support scores are retained in history; this chart shows only the current priority definition.

0.01.02.03.04.05.002 Nov 2026 · INSUFFICIENT DATAHype 0.0Reality 2.903 Nov 2026 · BELOW THRESHOLDSHype 0.0Reality 2.9Nov 2Nov 3

━ Hype Score (Perceived)  ━ Reality threat priority. Definition changes are not new attacks.

Public exploit evidence

0

Public exploit entries / repo candidates

Evidence context and dated references

Reality is general threat/review priority, combining observed exploitation, CVSS severity and fresh EPSS. Evidence confidence is separate. This is not calibrated risk, a victim count or an asset-specific assessment. A range reflects missing numeric inputs. Published 7 days ago. Exploitation evidence usually takes weeks to show up: a low reality score can mean there is no data yet, not that the flaw is mild.

Evidence in context

Confidence in exploitation evidence
Insufficient evidence
Priority basis
Exploitation in attacks unconfirmed; CVSS 8.3; EPSS 0.3%
Attention, last 30 days
0 distinct story titles; 0 press documents; 0 publisher domains.
Technical potential
network access, no prior privileges, no user interaction, additional attack conditions.
Observed activity
No exploitation observation is recorded.
Known scale
Not quantified.
Evidence confidence basis
Insufficient evidence

Score evaluated: 2026-11-05 14:00:28.370038+00:00 · EPSS snapshot: 2026-11-05T12:03:04Z

Source event timeline
Published
01 Nov 2026, 22:22
Score calculated
05 Nov 2026, 14:00