CVE-2026-84181 — camel-shiro : contournement d'authentification via un sujet lié au thread

Reproducteur de preuve de concept exécutable pour la vulnérabilité Apache Camel où le processeur de sécurité Shiro ignorait la vérification des identifiants lorsque le Subject Shiro déjà lié au thread courant portait le même principal que l'échange entrant. Étant donné que le thread qui transporte un échange Camel provient d'un pool et est réutilisé entre les échanges, un sujet laissé lié par un échange antérieur authentifié pouvait satisfaire la vérification pour un échange ultérieur qui ne présentait aucun identifiant valide propre — le mot de passe de cet échange ultérieur n'était jamais vérifié. L' attaquant n'a besoin de rien de plus que d'envoyer une requête nommant un principal actuellement utilisé.

Runtime	Répertoire	Pile
Camel Spring Boot	`camel-spring-boot/`	Spring Boot 3.5.13 + camel-shiro 4.22.0 (affecté ; corrigé en 4.22.1)
Camel Quarkus	`camel-quarkus/`	Quarkus 3.29.0 + camel-quarkus-shiro (Camel 4.15.0, affecté ; contrôle corrigé CQ 3.40.0 / Camel 4.22.1)

Les deux modules démontrent le comportement affecté et le comportement corrigé.

Ce que cela démontre

Une route est protégée par une ShiroSecurityPolicy construite avec alwaysReauthenticate=false — le mode documenté dans lequel le sujet authentifié est délibérément maintenu lié au thread de travail (mis en pool, réutilisé) entre les échanges. Le pilote d'exploitation, au sein d'un seul thread de travail HTTP, exécute deux échanges dans l'ordre :

une requête légitime par ringo avec le bon mot de passe starr — elle s'authentifie et laisse le sujet Shiro lié à ce thread (comme le ferait une requête authentifiée antérieure dans un service occupé) ;
une requête attaquante nommant le même utilisateur ringo mais avec un mauvais mot de passe not-starr, sur le même thread.

Affecté : le second échange est accepté sans vérifier son mot de passe — il profite du sujet laissé lié au thread par l'étape 1 — et atteint la logique protégée. Contournement d'authentification.
Corrigé : les identifiants du second échange sont vérifiés pour eux-mêmes et il est rejeté avec une AuthenticationException, même si le même utilisateur est toujours lié au thread.

# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected: wrong password reaches protected logic; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-84181-shiro-auth-bypass-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: wrong password rejected; >>> Not exploited

# Camel Quarkus
cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected (Camel 4.15.0): wrong password reaches protected logic
docker compose down
# Patched control: CQ 3.40.0 ships Camel 4.22.1
mvn clean package -Dcamel-quarkus.version=3.40.0 -Dquarkus.platform.version=3.40.0
java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: wrong password rejected

Résumé de la vulnérabilité

Propriété	Valeur
Composant	`camel-shiro` (`ShiroSecurityProcessor.authenticateUser`)
CWE	CWE-287 (Authentification incorrecte)
Gravité	MOYENNE
Vecteur d'attaque	Une requête nommant un principal actuellement lié à un thread de travail réutilisé, ne portant aucune information d'identification valide propre
Impact	Contournement d'authentification : une requête non authentifiée est acceptée comme un principal déjà lié ; son mot de passe n'est jamais vérifié
Versions affectées	À partir de 4.0.0 avant 4.18.5, à partir de 4.19.0 avant 4.22.1
Versions corrigées	4.18.5, 4.22.1, 4.23.0
JIRA	CAMEL-24439
Crédit	Claude Security Scan Tool

Avis : https://camel.apache.org/security/CVE-2026-84181.html

Le correctif

ShiroSecurityProcessor.authenticateUser ne saute plus la connexion lorsque le sujet lié au thread porte déjà le même principal. Le code précédent court-circuitait sur currentUser.isAuthenticated() && username.equals(currentUser.getPrincipal()) ; un nom d'utilisateur correspondant ne dit rien sur le mot de passe présenté avec cet échange. Le processeur appelle désormais currentUser.login(token) à chaque échange, de sorte que les informations d'identification présentées sont toujours vérifiées. alwaysReauthenticate contrôle toujours la longévité rememberMe du sujet, mais ne conditionne plus la vérification du mot de passe.

Atténuation si vous ne pouvez pas mettre à jour

Assurez-vous que le sujet Shiro est effacé du thread à la fin de chaque échange (afin qu'aucun sujet ne puisse être hérité par un échange ultérieur) — par exemple avec un onCompletion/processeur qui appelle ThreadContext.unbindSubject() de Shiro — jusqu'à ce que vous puissiez mettre à jour.

Avertissement

Ce dépôt est publié à des fins éducatives et défensives : pour aider les utilisateurs d'Apache Camel à comprendre la vulnérabilité, vérifier s'ils sont affectés, et confirmer que la mise à jour la résout. Les utilisateurs, mots de passe et clés présents ici sont des données locales inertes. N'utilisez pas ce matériel contre des systèmes que vous ne possédez pas ou n'exploitez pas.

CVE-2026-84181