CVE-2026-82705
Publiée le 2026-11-01 · Dernière modification le 2026-11-02
Les versions 8.0.0–8.19.0, 9.0.0–9.24.0 et 10.0.0–10.11.0 d'Apache Wicket sont concernées. Ce framework Java est utilisé pour créer des applications web, et la faille existe car certains composants — comme des images ou des liens de téléchargement — contournent les contrôles d'autorisation du système lorsqu'ils sont configurés à l'aide d'un constructeur spécifique. Essentiellement, le contrôle de sécurité est appliqué si la ressource est demandée via sa propre URL, mais il est ignoré si elle est servie par le composant qui la détient.
Un attaquant non authentifié disposant d'un accès réseau peut exploiter cette faille pour contourner les contrôles d'accès prévus et télécharger des fichiers ou des données restreintes. Cela compromet la confidentialité et l'intégrité des ressources spécifiques servies. Comme l'attaque ne nécessite qu'une requête web standard vers une URL vulnérable, elle est relativement facile à exécuter sans aucune interaction de l'utilisateur.
DÉTAIL DU VECTEUR CVSS
RÉFÉRENCES
Description officielle du NVD (en anglais)
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.