Apache Wicket: Excessive memory allocation via FileUploadToResourceField
Summary
Apache Wicket versions 9.14.0 to 9.24.0 and 10.0.0 to 10.11.0 contain a flaw in the FileUploadToResourceField component. Its Ajax callback accepts client-supplied file information and UploadInfo#get() allocates a byte array sized by that unverified value, even for files never uploaded. An unauthenticated remote attacker can exhaust the server heap with small repeated requests, and a negative size causes an unhandled NegativeArraySizeException. The issue only applies if the application uses this non-default component and calls UploadInfo#get().
Affected
- Apache Wicket 9.14.0 through 9.24.0
- Apache Wicket 10.0.0 through 10.11.0
- Not affected: Apache Wicket 8.x, which does not contain this component
- Applications must use FileUploadToResourceField and call UploadInfo#get()
Fixed in
- Apache Wicket 9.25.0
- Apache Wicket 10.12.0
Workaround
- Deny the ENABLE action on the FileUploadToResourceField through the authorization strategy, which refuses the callback
- Remove the component or leave it unmounted if the application does not use it
- No independently published workaround found
Exploitation
- Not known to be exploited (OffSeq rating)
- No public proof of concept, CISA KEV entry or GitHub advisory found at the time of research
- Same-day record, so the status may change
Our recommendation
- Search the codebase for FileUploadToResourceField and calls to UploadInfo#get(); if neither exists, the flaw is not reachable
- For affected applications, upgrade to 9.25.0 or 10.12.0 in the next regular maintenance window
- If upgrading is delayed, apply the ENABLE authorization restriction or remove the component
- Plan the move off 9.x, which is reaching end of life; Wicket 10 LTS is recommended
- Note the severity disagreement: NVD gives CVSS 4.0 8.3, VulDB gives 4.3 Medium; plan using the CNA score
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- Apache Wicket mailing list advisory lists.apache.org
- Wicket 9.24.0 release notes wicket.apache.org
- VulDB entry 429692 vuldb.com
- CVE mirror entry CVE-2026-83594 cve.threatint.com
- OffSeq radar entry CVE-2026-83594 radar.offseq.com
- Apache Wicket home page wicket.apache.org
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)
Memory allocation with an excessive size value in Apache Wicket. org.apache.wicket.markup.html.form.upload.resource.FileUploadToResourceField uploads files to a separately mounted resource rather than through a form, and is told the outcome afterwards over its own Ajax callback. That callback reads the request parameter filesInfo, a JSON array carrying a client file name, a size and a content type for each file, and turns it into the list of FileUploadToResourceField.UploadInfo that onUploadSuccess() receives. Nothing binds that JSON to an upload the resource performed and nothing re-derives it from the stored files, so the number of entries and every value in them are whatever the request supplied. The callback URL is rendered into the page, no prior upload is required, and both GET and POST reach it, so any client that can load the page can have the component report files that were never uploaded, without authenticating beyond whatever the page itself requires and without any user interaction. UploadInfo#get(), which the class offers as the way to obtain the bytes of an upload, allocates a byte array from UploadInfo#getSize() before it opens the file. The array is therefore sized by the number the request supplied, and the allocation happens even for a file that was never stored. One small request can cost the server close to two gigabytes of heap, and the request is trivially repeatable, so a few of them exhaust the heap for every request the Java virtual machine is serving. A size that the conversion to int turns negative instead throws NegativeArraySizeException, which the exception handler inside that method does not cover, so it escapes into the application. An application is affected where it uses FileUploadToResourceField, which is not the ordinary upload path through FileUploadField and Form and has to be extended and mounted deliberately. The allocation additionally requires the application to call UploadInfo#get() rather than reading UploadInfo#getFile() itself. Where the application denies the ENABLE action on the field through its authorization strategy, the callback is refused like any other listener. The 8.x line does not contain this component and is not affected. This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.11.0. 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:
- NVD (NIST) – CVEs, rating (CVSS), affected products
- CISA KEV – vulnerabilities confirmed by CISA as actively exploited
- CISA Vulnrichment – CISA assessment (SSVC) in the official CVE record
- FIRST EPSS – probability of exploitation
- Microsoft MSRC – Patch Tuesday: vulnerabilities, severity, updates
- PoC-in-GitHub – public proof-of-concept repositories
- Metasploit (Rapid7) – modules of the Metasploit Framework
- Exploit-DB (OffSec) – archive of public exploits (links only)
- Patch days: official vendor pages (linked per vendor) (Vendor patch days)
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.
