Apache Wicket up to 8.19.0/9.24.0/10.11.0 ListenerRequestHandler org.apache.wicket.Component.canCallListener improper authorization

Summaryinfo

A vulnerability marked as critical has been reported in Apache Wicket up to 8.19.0/9.24.0/10.11.0. This vulnerability affects the function org.apache.wicket.Component.canCallListener of the component ListenerRequestHandler. This manipulation causes improper authorization. This vulnerability is registered as CVE-2026-82704. Remote exploitation of the attack is possible. No exploit is available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability was found in Apache Wicket up to 8.19.0/9.24.0/10.11.0. It has been declared as critical. Affected by this vulnerability is the function org.apache.wicket.Component.canCallListener of the component ListenerRequestHandler. 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. The summary by CVE is:

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.

The advisory is shared at lists.apache.org. This vulnerability is known as CVE-2026-82704 since 08/30/2026. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 11/01/2026). MITRE ATT&CK project uses the attack technique T1548.002 for this issue.

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

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

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

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion