Quick answers
- Is CVE-2026-83594 exploited in the wild?
- No. Junglewise Threat Intelligence has no report of CVE-2026-83594 being exploited in the wild.
- How severe is CVE-2026-83594?
- Informational severity, published 1 November 2026.
- Which products and versions are affected?
- Apache Wicket 9.14.0 through 9.24.0, 10.0.0 through 10.11.0.
- Is there a fix for CVE-2026-83594?
- Yes: fixed in 9.25.0, 10.12.0. Until then: Applications that do not use FileUploadToResourceField are not affected. Where the component is used, authorization strategies that deny the ENABLE action on the field will refuse the callback and prevent exploitation. Alternatively, applications can avoid calling UploadInfo.get() and instead directly read UploadInfo.getFile().</anigation> <parameter name="timeline">[{"kind":"disclosed","at":"2026-11-01"}] Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
- How is CVE-2026-83594 attacked?
- It is attacked over the network, in a software library.
- Am I affected by CVE-2026-83594?
- Check whether you run Apache Wicket at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.
How to fix
- Fixed in: 9.25.0, 10.12.0
Applications that do not use FileUploadToResourceField are not affected. Where the component is used, authorization strategies that deny the ENABLE action on the field will refuse the callback and prevent exploitation. Alternatively, applications can avoid calling UploadInfo.get() and instead directly read UploadInfo.getFile().</anigation> <parameter name="timeline">[{"kind":"disclosed","at":"2026-11-01"}]
Technical details
The FileUploadToResourceField component accepts a client-supplied JSON parameter (filesInfo) that specifies uploaded file names, sizes, and content types without validating that the files were actually uploaded or re-deriving metadata from stored files. When the application calls UploadInfo.get(), the code pre-allocates a byte array based on this untrusted size value before opening the file, allowing an attacker to trigger allocations of up to ~2 GB per request. Since the callback URL is rendered into every page and requires no prior upload or user interaction beyond page access, an attacker can trivially repeat this request to exhaust the Java virtual machine's heap.
Affected products
- Apache Wicket 9.14.0 through 9.24.0, 10.0.0 through 10.11.0