CVE-2026-82705
Received Received - Intake

Missing Authorization in Apache Wicket

Publication date: 2026-11-01

Last updated on: 2026-11-01

Assigner: Apache Software Foundation

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-11-01
Last Modified
2026-11-01
Generated
2026-11-02
AI Q&A
2026-11-02
EPSS Evaluated
N/A
NVD
CVE-2026-82705

Affected Vendors & Products

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-862 The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in Apache Wicket involves missing authorization checks when serving resources. The issue occurs when a resource restricted by a custom authorization strategy or annotation is passed to certain components like ResourceLink, Image, ImageButton, or AjaxDownloadBehavior as an IResource instance instead of a ResourceReference. This bypasses the authorization check because the resource is served through a component listener URL rather than a resource URL.

Detection Guidance

To detect this vulnerability, check if your Apache Wicket application uses components like ResourceLink, Image, ImageButton, or AjaxDownloadBehavior with IResource instances instead of ResourceReference. Inspect application code for these patterns and verify if authorization checks are bypassed when resources are served through these components.

Impact Analysis

An attacker could access restricted resources if an application uses the vulnerable pattern. This includes resources protected by IAuthorizationStrategy or @AuthorizeResource annotations. The impact depends on what the exposed resource contains, such as sensitive data or functionality not meant for public access.

Compliance Impact

This vulnerability allows unauthorized access to restricted resources due to missing authorization checks in Apache Wicket. For compliance standards like GDPR and HIPAA, which require strict access controls and data protection, this could lead to unauthorized data exposure or breaches. Unauthorized access to sensitive resources may violate confidentiality requirements under these regulations.

Mitigation Strategies

Upgrade Apache Wicket to version 8.20.0, 9.25.0, or 10.12.0 or later to fix the missing authorization issue.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-82705. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart

Security Radar

News mentioning this vulnerability
Loading related security news...