Apache Wicket up to 8.19.0/9.24.0/10.11.0 ResourceLink isResourceAuthorized improper authorization

Summaryinfo

A vulnerability classified as critical was found in Apache Wicket up to 8.19.0/9.24.0/10.11.0. The affected element is the function isResourceAuthorized of the component ResourceLink. Executing a manipulation can lead to improper authorization. This vulnerability appears as CVE-2026-82705. The attack may be performed from remote. There is no available exploit. Upgrading the affected component is advised.

Detailsinfo

A vulnerability classified as critical was found in Apache Wicket up to 8.19.0/9.24.0/10.11.0. This vulnerability affects the function isResourceAuthorized of the component ResourceLink. The manipulation with an unknown input leads to a improper authorization vulnerability. The CWE definition for the vulnerability is CWE-285. The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. As an impact it is known to affect confidentiality, integrity, and availability. CVE summarizes:

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.

The advisory is shared for download at lists.apache.org. This vulnerability was named CVE-2026-82705 since 08/30/2026. The exploitation appears to be easy. The attack can be initiated remotely. No form of authentication is required for a successful exploitation. Successful exploitation requires user interaction by the victim. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 11/01/2026). The MITRE ATT&CK project declares the attack technique as T1548.002.

Upgrading to version 8.20.0, 9.25.0 or 10.12.0 eliminates this vulnerability.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Productinfo

Vendor

• Apache

Name

• Wicket

Version

• 8.0
• 8.1
• 8.2
• 8.3
• 8.4
• 8.5
• 8.6
• 8.7
• 8.8
• 8.9
• 8.10
• 8.11
• 8.12
• 8.13
• 8.14
• 8.15
• 8.16
• 8.17
• 8.18
• 8.19.0
• 9.0
• 9.1
• 9.2
• 9.3
• 9.4
• 9.5
• 9.6
• 9.7
• 9.8
• 9.9
• 9.10
• 9.11
• 9.12
• 9.13
• 9.14
• 9.15
• 9.16
• 9.17
• 9.18
• 9.19
• 9.20
• 9.21
• 9.22
• 9.23
• 9.24.0
• 10.0
• 10.1
• 10.2
• 10.3
• 10.4
• 10.5
• 10.6
• 10.7
• 10.8
• 10.9
• 10.10
• 10.11.0

License

• open-source

Website

• Vendor: https://www.apache.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Discussion