CVE-2026-82705 in Wicket
Summary
by MITRE • 11/02/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
A critical authorization bypass vulnerability exists within Apache Wicket versions ranging from 8.0.0 through 10.11.0, specifically affecting components that serve resources via direct IResource instances rather than ResourceReferences. The flaw stems from an inconsistency in how the framework enforces access controls defined by the org.apache.wicket.authorization.IAuthorizationStrategy interface or @AuthorizeResource annotations. When a resource is accessed directly through its mounted URL using the ResourceRequestHandler, the authorization strategy is correctly consulted to verify permissions. However, when the same IResource instance is passed to specific UI components such as ResourceLink, Image, ImageButton, or AjaxDownloadBehavior, these components invoke the respond method on the resource directly from their own request listeners. This direct invocation bypasses the central enforcement point in ResourceRequestHandler, resulting in a complete lack of authorization checks for those requests.
The operational impact is significant because it allows unauthenticated or unauthorized users to access sensitive resources that were intended to be protected. The vulnerability manifests differently depending on how the component is instantiated and rendered. For instance, components like Image and ImageButton embed the resource URL directly into the src attribute of HTML tags. This means browsers automatically request these resources upon page load without any explicit user interaction, potentially exposing private data or triggering side effects in an unauthorized context. Similarly, AjaxDownloadBehavior allows for background downloads that bypass security controls. The issue is not limited to custom application code; it also affects standard framework components like the ExportToolbar in wicket-extensions, which constructs export links using IResource instances, thereby exposing exported data from data tables without proper authorization checks.
This vulnerability aligns with CWE-285, Improper Authorization, as the software does not perform or incorrectly performs an authorization check when a user attempts to access a resource. From a tactical perspective, this flaw can be leveraged in attacks categorized under MITRE ATT&CK techniques such as T1078, Valid Accounts, if combined with credential theft, or more broadly as part of unauthorized data exfiltration where sensitive files are downloaded by attackers who lack the necessary privileges to view them through normal application interfaces. The severity is heightened because the bypass occurs transparently during standard page rendering and AJAX interactions, making it difficult for developers to detect without rigorous code review focused on resource handling patterns.
To mitigate this risk, applications must ensure that all resources requiring authorization are accessed via their ResourceReference rather than directly as IResource instances within component constructors. By registering the resource in the application's shared resources and passing the resulting ResourceReference to components like ResourceLink or Image, requests are routed through the correct handler that enforces the configured authorization strategy. This ensures that every access attempt is validated against the defined security policies. Immediate action should be taken by upgrading Apache Wicket to version 8.20.0, 9.25.0, or 10.12.0, where this architectural inconsistency has been resolved and all resource requests are consistently subject to authorization checks regardless of how they are invoked within the framework.