Apache Wicket EUVD-2026-114898

Exploitable only where the application deliberately uses FileUploadToResourceField or itself mounts FileUploadResourceReference - this is not the ordinary Form/FileUploadField or AjaxFileDropBehavior path, which read limits from the component and are unaffected; the 8.x line lacks the resource entirely. The defect only removes protection if the application actually configured a limit via setMaxSize()/setFileMaxSize()/setFileCountMax(); an application that set no total-size limit loses nothing because Wicket imposes none by default. The trigger is a client-supplied maxSize (and omitted fileMaxSize/fileCountMax) request parameter overriding the configured value. Per CVSS PR:N and the default authorization strategy permitting all resource requests, no authentication, session, prior page view or user interaction is required - unless the application explicitly authorizes the resource, which would then gate access.

This is a CWE-770 resource-exhaustion (denial-of-service) flaw in Apache Wicket's form-less upload resource, rated CVSS 4.0 8.3 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H). The network vector, low complexity and PR:N indicate that where the vulnerable resource is mounted, a remote unauthenticated attacker can trigger it against default authorization. The decisive limiter is AT:P (attack requirements present), which here is not a race or timing condition but the deployment precondition: the application must deliberately use FileUploadToResourceField or mount FileUploadResourceReference, AND must have configured an upload limit for the defect to remove anything - an app that sets no limit loses nothing. No EPSS score and no KEV listing are provided, and the sole reference is an Apache advisory, so there is no public exploit identified at time of analysis. The vuln.today decision label is this_week, consistent with a serious but conditional DoS rather than an emergency: impact is primarily availability (VA:H, heap/disk exhaustion) with limited integrity (VI:L, attacker-named files written to the uploads folder) and no confidentiality impact. Net: a genuine priority for the specific minority of Wicket applications using this upload resource with configured limits, but not a mass-exploitation threat given the deliberate, non-default deployment requirement.

An application mounts Wicket's FileUploadToResourceField / FileUploadResourceReference and relies on setMaxSize()/setFileMaxSize()/setFileCountMax() to cap uploads. A remote unauthenticated attacker POSTs a multipart request to that resource endpoint supplying its own huge maxSize parameter (and omitting fileMaxSize/fileCountMax), so the server-configured ceilings are ignored and the parser applies no effective limit. Repeating the request spools arbitrarily large file parts to disk and reads non-file parts fully into the heap, exhausting disk or memory; no public exploit code is identified, but the technique follows directly from the advisory.