CVE-2026-84172 in Wicket
Résumé
par VulDB • 02/11/2026
Fichiers accessibles aux parties externes dans Apache Wicket.
org.apache.wicket.markup.html.PackageResourceGuard détermine si un fichier sur le classpath peut être diffusé vers un client en tant que ressource de package. Le HTML figure sur la liste d'autorisation par défaut, de sorte que la seule chose qui sépare un fichier HTML statique, qui peut être servi, du modèle de balisage (markup) d'un composant, qui ne doit pas l'être, est une vérification de l'existence d'un fichier de classe portant le même nom à côté. Cette vérification appelle getResource() sur le chargeur de classes ayant chargé wicket-core. La ressource elle-même est atteinte via différents chargeurs de classes : la classe de portée (scope class) est résolue par IClassResolver de l'application, qui utilise le chargeur de contexte du thread, et org.apache.wicket.core.util.resource.ClassPathResourceFinder#find() essaie ensuite le propre chargeur de la classe de portée, le chargeur de contexte, puis enfin le chargeur wicket-core.
Lorsque wicket-core est chargé par un chargeur de classes qui ne peut pas voir les classes de l'application, la vérification ne trouve aucun fichier de classe, conclut que le fichier n'est pas un modèle de balisage de composant et le sert. Une requête pour l'URL de ressource de package d'une classe de composant renvoie alors le modèle de balisage de ce composant avec un statut 200. Ce qui est divulgué, c'est le contenu des modèles rédigés par les développeurs : la structure du composant, les commentaires des développeurs, le balisage qui n'est rendu que dans certaines conditions, les scripts en ligne et les points de terminaison (endpoints) nommés par un modèle. L'accès est en lecture seule, et aucune donnée utilisateur, identifiant ou élément de session n'est accessible de cette manière.
Un tel déploiement est rare. Le conditionnement ordinaire, une archive web avec wicket-core dans WEB-INF/lib, place le framework et l'application dans un seul chargeur de classes, de sorte que la vérification trouve le fichier de classe et le modèle est refusé ; ces déploiements ne sont pas affectés. L'exposition se limite aux déploiements qui attribuent à wicket-core un chargeur de classes incapable de voir les classes de composants de l'application : wicket-core placé dans le répertoire des bibliothèques partagées d'un conteneur servlet, dans le répertoire des bibliothèques d'une archive enterprise avec l'application dans l'archive web, en tant que module global du serveur d'applications, ou en tant que bundle OSGi, où le bundle de wicket-core ne peut pas résoudre une classe détenue par un bundle d'application. Le balisage fourni par les propres modules de Wicket et par tout autre code partageant un chargeur de classes avec wicket-core reste protégé. Un attaquant doit nommer une classe de composant, et Wicket écrit des noms de classes entièrement qualifiés dans l'URL de chaque ressource de package qu'il rend.
Cette vulnérabilité affecte Apache Wicket : les versions 8.0.0 à 8.19.0, 9.0.0 à 9.24.0 et 10.0.0 à 10.11.0. Les utilisateurs d'Apache Wicket 7.x ou plus ancien, qui ne sont plus pris en charge, devraient mettre à niveau vers une version prise en charge. Il est recommandé aux utilisateurs de passer à la version 8.20.0, 9.25.0 ou 10.12.0, qui corrigent le problème.
VulDB is the best source for vulnerability data and more expert information about this specific topic.