Apache Wicket CVE-2026-82705

Exploitation requires that the application (a) restricts a resource via IAuthorizationStrategy#isResourceAuthorized() or a wicket-auth-roles @AuthorizeResource annotation, AND (b) hands that same restricted resource to a component as an IResource instance rather than as a ResourceReference - specifically ResourceLink(String, IResource), Image, ImageButton, or wicket-extensions AjaxDownloadBehavior, or any use of ExportToolbar (which internally builds export links from IResource). The decisive factor is which constructor the application used, which is invisible in the rendered page. For Image and ImageButton the listener URL is written into the tag's src attribute, so no user interaction is needed - the browser fetches it automatically. Explicit limiting factors stated in the advisory: applications that do not restrict resources at all are not affected, and resources that are only mounted or registered as shared resources (served through ResourceRequestHandler) are not affected because that handler does consult the authorization strategy.

The vendor-supplied CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N, base 6.3, medium) is the only quantitative signal in the input: EPSS is not provided and the issue is not listed in CISA KEV, so there is no public-exploitation telemetry to weigh. AV:N/PR:N/UI:N means a remote, unauthenticated request can reach the flaw, and AC:L means the attacker side is simple; the moderating factor is AT:P (an attack requirement), which here corresponds to the fact that the target application must have been written using the vulnerable IResource-constructor pattern against an authorization-restricted resource - the condition is a property of the deployed application, not something the attacker controls or something visible in the rendered page. Impact is deliberately scored low (VC:L/VI:L, VA:N): the flaw exposes or serves a resource that should have been authorization-checked (e.g. data-table exports, model-backed images), not full system compromise. The vuln.today decision label is 'this_month' rather than 'act_now' or 'emergency', and there is no public exploit reference, so this is a genuine but conditional authorization-enforcement gap of moderate priority - not a drop-everything issue, but one that matters specifically for Wicket applications that rely on isResourceAuthorized()/@AuthorizeResource. Missing signals to note: no EPSS score and no KEV entry were supplied, so widespread or active exploitation can neither be confirmed nor ruled out from this data.

A Wicket application protects a resource (for example data-table exports via @AuthorizeResource, or a model-backed Image) with a custom isResourceAuthorized() check, but hands that same resource to a component as an IResource - such as ExportToolbar, which builds every export link from an IResource instance. Because Image/ImageButton write the component-listener URL into the rendered src attribute, an unauthenticated attacker (or even a victim browser) can request that listener URL directly and receive the resource's contents without the authorization strategy ever being consulted. No public exploit was identified at time of analysis.