Severity: moderate
CVSS 4.0: 6.3 (medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Affected versions:
- Apache Wicket (org.apache.wicket:wicket-core) 8.0.0 through 8.19.0
- Apache Wicket (org.apache.wicket:wicket-core) 9.0.0 through 9.24.0
- Apache Wicket (org.apache.wicket:wicket-core) 10.0.0 through 10.11.0
Description:
Missing authorization in Apache Wicket.
org.apache.wicket.authorization.IAuthorizationStrategy declares
isResourceAuthorized(), and that method has a single enforcement point in the
framework: org.apache.wicket.request.handler.resource.ResourceRequestHandler,
the handler that serves a resource reached through a mounted or shared
ResourceReference. Components that are handed an
org.apache.wicket.request.resource.IResource instance instead call
IResource#respond() themselves from their own request listener and never
construct that handler. In wicket-core these are
org.apache.wicket.markup.html.link.ResourceLink,
org.apache.wicket.markup.html.image.Image and
org.apache.wicket.markup.html.form.ImageButton; in wicket-extensions it is
org.apache.wicket.extensions.ajax.AjaxDownloadBehavior. A resource restricted
by a custom isResourceAuthorized() implementation, or by an @AuthorizeResource
annotation from wicket-auth-roles, is therefore enforced when it is requested
through its own resource URL and is not enforced when the same instance is
served through the component that holds it.
Which of the two happens is decided by the constructor the application used,
and not by anything the application can see in the rendered page.
ResourceLink(String, ResourceReference) renders a resource URL and the request
is authorized; ResourceLink(String, IResource) renders a component listener URL
and it is not. Image, ImageButton and AjaxDownloadBehavior each offer the same
pair of constructors and behave the same way. Image and ImageButton write that
listener URL into the src attribute of the tag they render, so a browser
requests it without any action by the user, and the resource an Image serves
may also come from the component's model.
An application is affected where it restricts a resource through
IAuthorizationStrategy#isResourceAuthorized() or an @AuthorizeResource
annotation and then hands that same resource to one of those components as an
IResource. An application that does not restrict resources at all is not
affected, and neither is a resource that is only mounted or registered as a
shared resource. The pattern does not have to be written by the application
itself:
org.apache.wicket.extensions.markup.html.repeater.data.table.export.ExportToolbar
builds each of its export links from an IResource instance, so the exported
contents of a data table are served without the resource check in any
application that adds that toolbar.
As a workaround, register the resource in the application's shared resources
and pass the resulting ResourceReference to the component instead of the
IResource, so that the request is routed through the handler that consults the
authorization strategy.
This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through
9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to
version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
Credit:
Emond Papegaaij (finder)
References:
https://wicket.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-82705
