CVE-2026-83594
Received Received - Intake

Memory Corruption in Apache Wicket File Upload

Vulnerability report for CVE-2026-83594, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-11-01

Last updated on: 2026-11-01

Assigner: Apache Software Foundation

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-11-01
Last Modified
2026-11-01
Generated
2026-11-02
AI Q&A
2026-11-02
EPSS Evaluated
N/A
NVD

Affected Vendors & Products

Showing 2 associated CPEs

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-789 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.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This is a memory allocation vulnerability in Apache Wicket where a malicious client can send a request with an excessively large file size value. The server allocates a byte array based on this size before verifying the file, leading to potential heap exhaustion. The issue affects versions 9.14.0 through 9.24.0 and 10.0.0 through 10.11.0.

Detection Guidance

Detecting this vulnerability requires checking if your Apache Wicket version is within the affected range (9.14.0 to 9.24.0 or 10.0.0 to 10.11.0) and if your application uses FileUploadToResourceField with UploadInfo#get(). Review server logs for repeated requests to the callback URL or heap exhaustion errors.

Impact Analysis

An attacker can repeatedly send requests with large file sizes, causing the server to allocate nearly 2GB of heap per request. This can exhaust server memory, leading to crashes or denial of service for all applications running on the same Java virtual machine.

Compliance Impact

This vulnerability primarily causes denial-of-service by exhausting server memory, which could disrupt availability of systems handling personal or sensitive data. For GDPR, this may impact the right to access or rectify data if services are unavailable. For HIPAA, it could affect the availability of ePHI processing systems. However, the vulnerability does not directly expose or leak data, so primary compliance concerns relate to service disruption rather than data breaches.

Mitigation Strategies

Upgrade Apache Wicket to version 9.25.0 or 10.12.0 or later. If upgrading is not immediately possible, restrict access to the callback URL through network policies or application-level authorization. Disable FileUploadToResourceField if not in use.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-83594. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart

Security Radar

News mentioning this vulnerability
Loading related security news...