Apache Wicket: Memory Allocation with Excessive Size Value
CVE-2026-83594 is a high-severity memory allocation with excessive size value vulnerability in Apache Wicket from Apache, with a CVSS 4.0 base score of 8.3 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. Affected Apache Wicket versions: 9.14.0 through 9.24.0; 10.0.0 through 10.11.0. The record does not name a fixed version, so check the vendor advisory. There is no confirmed exploitation so far. EPSS estimates a 0.29% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Check which version of Apache Wicket you run against the affected versions below, and install the vendor's latest release.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Apache | Apache Wicket | 9.14.0 through 9.24.0; 10.0.0 through 10.11.0 | Not stated |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Attack requirements
- PresentThe target must be in a specific state or configuration for the attack to work.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- NoneNo action by a victim is required.
- Confidentiality (vulnerable system)
- NoneNo loss of confidentiality on the vulnerable system.
- Integrity (vulnerable system)
- LowLimited loss of integrity on the vulnerable system.
- Availability (vulnerable system)
- HighSerious loss of availability on the vulnerable system.
- Confidentiality (other systems)
- NoneNo loss of confidentiality on systems beyond the vulnerable one.
- Integrity (other systems)
- NoneNo loss of integrity on systems beyond the vulnerable one.
- Availability (other systems)
- NoneNo loss of availability on systems beyond the vulnerable one.
Vector: 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. Scored by CNA (apache.org).
Official description
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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Memory Allocation with Excessive Size Value
The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.
How developers prevent this class of flaw
- Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
- Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.
More Memory Allocation with Excessive Size Value vulnerabilities (CWE-789)
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: partial).
- Record last changed materially (score, affected products, status or references).
References
Other references
Other vulnerabilities in Apache Wicket
- 7.6 High severity
- 7.4 High severity
- 8.3 High severity
- 7.4 High severity
- 7.4 High severity
- 7.6 High severity
Recent Memory Allocation with Excessive Size Value vulnerabilities
- 7.5 High severity
- 8.9 High severity
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
Spotted an error? Tell us.