CVE-2026-82704
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.core.request.handler.ListenerRequestHandler invokes an IRequestListener only when org.apache.wicket.Component#canCallListener() allows it, and that method is isEnabledInHierarchy() && isVisibleInHierarchy(). The visibility half reads a flag that carries the outcome of IAuthorizationStrategy#isActionAuthorized() for the Component.RENDER action, and that flag is written in one place only, Component#configure(), during the render phase. A listener URL built by a subclass of org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper carries the page identifier and the component path in a single parameter, and the page identifier may be empty. When it is, a new page instance is constructed, PageProvider#wasExpired() is false because no identifier was supplied, and PageAndComponentProvider#getComponent() finds the component directly on the new instance, so neither a render pass nor Component#configure() runs before the listener is invoked. The flag therefore still holds its constructor default, the component counts as visible, and the listener of a component the authorization strategy denied RENDER for is executed. The same request also skips Component#onConfigure(), so visibility and enablement an application sets there are not applied either. There are two ways to reach this, and neither requires anything but a request. On a page that is stateful, the caller omits the page identifier from a listener URL that would otherwise carry it. On a page that Wicket considers stateless, nothing has to be altered at all: Wicket itself writes listener URLs without a page identifier for such pages, and a component the strategy denies RENDER for is treated as stateless and therefore does not keep the page stateful, so denying RENDER can itself produce the page-id-less form. The second route has never been refused. The ENABLE decision of IAuthorizationStrategy is consulted on every invocation and still refuses, as does a request that supplies the real identifier of a page instance that has already been rendered; a component the application disabled in Component#onConfigure() is protected by neither, because that callback has not run. An application is affected where it withholds an individual component from the caller, either by denying the RENDER action through IAuthorizationStrategy, including through the MetaDataRoleAuthorizationStrategy and AuthorizeAction facilities of wicket-auth-roles, or by setting the component's visibility or enabled flag in Component#onConfigure(), the callback Wicket's own documentation directs applications to use for both. The page carrying such a component has to be constructible from a bookmarkable or mounted URL, which requires a public constructor taking either no arguments or a PageParameters argument. Behaviours pass through the same gate, so an AJAX behaviour attached to such a component is equally exposed. Separately, and whether or not any component is withheld, a listener on a page Wicket considers stateful is invoked on an instance the request itself constructed, so it acts on models built from page parameters the caller supplied rather than on the state the application last rendered. Instantiation authorization is unaffected: IAuthorizationStrategy#isInstantiationAuthorized() is still consulted when the new page instance is created, so a guard placed on the page rather than on the individual component continues to hold. 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-82704

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 allows unauthorized execution of listener methods due to missing authorization checks. It occurs when a component's visibility flag, which should be set based on authorization, is not properly initialized before listener invocation. This happens because the flag is only set during the render phase, but listener URLs can bypass this by omitting the page identifier, skipping the render phase entirely.

Detection Guidance

This vulnerability is specific to Apache Wicket versions 8.0.0 through 8.19.0, 9.0.0 through 9.24.0, and 10.0.0 through 10.11.0. Detection involves checking the installed Wicket version and verifying if affected components are exposed. No direct commands are provided in the context, but you can inspect Wicket dependencies in your project or server logs for version information.

Impact Analysis

An attacker could exploit this to invoke restricted listener methods or AJAX behaviors on components that should be inaccessible. This could lead to unauthorized actions, data exposure, or manipulation of application state. The impact depends on the application's use of authorization strategies and component visibility settings.

Compliance Impact

This vulnerability could potentially impact compliance with standards like GDPR and HIPAA by allowing unauthorized access to components that should be restricted. If an application relies on authorization checks to protect sensitive data or functionality, the missing authorization flaw might expose protected components to unauthorized users, violating data protection requirements.

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-82704. 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...