Apache Jackrabbit CVE-2026-92414 (9.1) : réutilisation de session sur le serveur WebDAV, corrigé en 2.23.6, 2.22.5 et 2.20.18

Le 7 octobre 2026, NVD a publié CVE-2026-92414 sur Apache Jackrabbit, l'implémentation de référence de l'API Java Content Repository (JCR). Notée 9.1, elle touche le serveur WebDAV de Jackrabbit : une requête peut se voir rattacher la session authentifiée d'un autre utilisateur.

Ce que fait la faille

Apache classe la faille comme une fixation / réutilisation de session entre utilisateurs (Session Fixation / Session Reuse across Users). NVD la décrit ainsi :

Jackrabbit WebDAV server attaches a cached authenticated session [...] with no credential check.

WebDAV utilise des jetons pour suivre des états qui durent plus d'une requête : verrous, transactions, abonnements. Pour éviter de rouvrir une session à chaque requête, le serveur Jackrabbit garde en cache des sessions authentifiées associées à ces jetons. Le défaut : quand une requête présente un jeton qui correspond, le serveur lui rattache la session en cache sans revérifier les identifiants de celui qui envoie la requête.

Autrement dit, le jeton devient de fait une preuve d'authentification, alors qu'il n'a jamais été conçu pour ça.

Pourquoi c'est grave

• Pas d'authentification requise (PR:N) : l'attaquant n'a pas besoin de compte.
• Pas d'interaction (UI:N) : la victime n'a rien à faire, il suffit qu'une session soit en cache.
• Impact en confidentialité et intégrité élevé : l'attaquant agit avec les droits de l'utilisateur dont il récupère la session. Si c'est un compte éditeur ou administrateur du dépôt, il peut lire et modifier le contenu.

Le vecteur ne mentionne pas d'impact en disponibilité.

Jackrabbit est souvent là où tu ne l'attends pas

Jackrabbit n'est pas seulement un produit qu'on installe tel quel. C'est aussi une bibliothèque : plusieurs CMS, outils de gestion documentaire et applications Java l'embarquent comme dépôt de contenu, parfois sans que ses administrateurs le sachent.

Je ne vais pas citer de produit précis : NVD ne liste que Apache Jackrabbit, et l'exposition d'un produit dépend de la façon dont il intègre le composant (version embarquée, serveur WebDAV activé ou non). Ce qui compte, c'est de vérifier :

• si tes applications Java ont Jackrabbit dans leurs dépendances, directes ou transitives ;
• si le serveur WebDAV de Jackrabbit y est activé et exposé ;
• quelle version est embarquée.

Si un éditeur intègre Jackrabbit dans son produit, c'est son avis à lui qui dira quelle version du produit corrige la faille.

Versions

Selon la description NVD, les versions affectées sont :

Apache recommande explicitement de passer à 2.23.6, 2.22.5 ou 2.20.18. Pour les branches plus anciennes, la description NVD ne dit rien : consulte l'avis Apache.

Détection

• Dépendances : mvn dependency:tree ou gradle dependencies pour repérer jackrabbit-* (en particulier les modules WebDAV) dans tes projets, et un SBOM ou un scanner de composants pour les applications livrées sous forme binaire.
• Exposition : le point d'accès WebDAV est-il joignable depuis Internet ou depuis des réseaux non maîtrisés ?
• Journaux d'accès : requêtes WebDAV réussies sans authentification préalable visible, ou actions attribuées à un utilisateur depuis une adresse IP qu'il n'utilise pas.
• Contenu du dépôt : modifications ou suppressions récentes sans action connue de l'utilisateur à qui elles sont attribuées.

Mitigation

1. Mettre à jour Apache Jackrabbit vers 2.23.6, 2.22.5 ou 2.20.18 selon ta branche, ou ultérieure.
2. Pour un produit tiers qui embarque Jackrabbit : appliquer le correctif de l'éditeur dès qu'il est publié, et lui demander s'il est concerné si son avis ne le précise pas.
3. Désactiver le serveur WebDAV si tu ne t'en sers pas.
4. Restreindre l'accès WebDAV au réseau interne ou derrière un proxy authentifiant.
5. En cas de doute sur une exploitation : redémarrer le service pour vider le cache de sessions après la mise à jour, examiner les modifications de contenu de la période et réinitialiser les mots de passe des comptes privilégiés.

Pourquoi surveiller en continu tes dépendances Java

Une dépendance transitive ne se voit pas dans la liste des produits installés. Pourtant, c'est elle qui ouvre la porte quand une CVE comme celle-ci tombe. L'inventaire des composants, pas seulement des applications, est ce qui permet de savoir si tu es concerné.

Avec cveo.tech, déclare tes applications et leurs composants avec leur version, et reçois une alerte dès qu'une CVE critique les concerne.