Apache Wicket CVE-2026-83594

Exploitation requires an application that deliberately extends and mounts org.apache.wicket.markup.html.form.upload.resource.FileUploadToResourceField - this is NOT the ordinary FileUploadField/Form upload path - AND that calls UploadInfo#get() to obtain upload bytes rather than reading UploadInfo#getFile() itself; absent the get() call the oversized allocation does not occur. No prior upload, no user interaction, and no authentication beyond whatever the hosting page itself requires are needed (PR:N); both GET and POST reach the callback, whose URL is rendered into the page. Exploitation is refused where the application's authorization strategy denies the ENABLE action on the field. Affected: Wicket 9.14.0 through 9.24.0 and 10.0.0 through 10.11.0; the 8.x line does not contain this component and is not affected. A size value that the int conversion turns negative instead raises an uncaught NegativeArraySizeException that escapes into the application.

The source assigns CVSS 4.0 of 8.3 (High) with vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H, which correctly frames this as a network-reachable, low-complexity availability (DoS) issue rather than a confidentiality breach - note the 'Information Disclosure' tag conflicts with VC:N and CWE-789 (memory allocation with excessive size) and appears mislabeled. The vuln.today decision label is 'this_week' (prompt, not emergency). No EPSS score, no CISA KEV listing, and no PoC/exploit reference were supplied - the only reference is the Apache advisory thread - so there is no public exploit identified at time of analysis and no evidence of active exploitation. The AT:P (attack requirements present) metric reflects the real limiter: exploitation only works where an application has deliberately extended and mounted FileUploadToResourceField AND calls UploadInfo#get(), which is not the ordinary FileUploadField/Form upload path. Net: a genuinely high-severity DoS when the preconditions hold, but real-world exposure is narrowed sharply by the uncommon component usage, so this is a prioritize-but-not-drop-everything item consistent with the 'this_week' label rather than a mass-exploitation emergency.

An attacker loads any page of a Wicket application that mounts FileUploadToResourceField, reads the callback URL rendered into that page, and sends a crafted request whose filesInfo JSON declares a file (never actually uploaded) with a size near two gigabytes. If the application then calls UploadInfo#get(), the server allocates that oversized byte array up front; repeating a few such trivial requests exhausts the JVM heap and denies service to all requests. No published PoC exploit code was provided in the input.