oscerd/cve-2026-84178Reproducteur de preuve de concept exécutable pour CVE-2026-84178, une CSRF de connexion dans le callback du code d'autorisation de camel-oauth d'Apache Camel qui échange les codes sans vérifier l'état.
state manquant)Reproducteur de preuve de concept exécutable pour la vulnérabilité Apache Camel où le callback OAuth authorization-code
ne portait pas de paramètre state le liant à la requête d'autorisation qui a initié le flux, et n'en vérifiait pas.
Un code d'autorisation obtenu dans n'importe quel navigateur pouvait donc être échangé au niveau du callback et associé
à la session qui le présentait — cross-site request forgery de connexion : une victime est silencieusement connectée avec une
identité contrôlée par l'attaquant, de sorte que les actions et données ultérieures de la victime aboutissent dans le compte de l'attaquant. (Le
même callback non validé permettait également d'influencer la cible de redirection post-authentification — une redirection ouverte.)
Comme le note l'avis, la vérification du state s'exécute avant l'échange du code, la différence est donc atteignable sans
aucune interaction avec le fournisseur d'identité.
| Runtime | Répertoire | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-oauth 4.22.0 (affecté ; corrigé en 4.22.1), callback via camel-undertow |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.39.0 + camel-quarkus-oauth 3.39.0 (Camel 4.22.0, affecté ; contrôle corrigé 3.40.0 / Camel 4.22.1), callback via camel-quarkus-platform-http |
Les deux modules démontrent le comportement affecté ainsi que le comportement corrigé.
Le processeur réel et non modifié OAuthCodeFlowCallback gère le point de terminaison de callback. Un stub OAuth minimal est
enregistré dans le registre Camel afin que le callback s'exécute sans fournisseur d'identité actif — il ne remplace que
l'IdP, et enregistre le moment où un code d'autorisation est échangé (ce qui, dans le flux réel, lie l'identité résultante à la
session présentatrice). L'attaquant se contente d'appeler le callback avec un code et aucun state correspondant :
state
correspondant à la requête d'autorisation initiée par cette session) — le code n'est jamais échangé.cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
Sortie attendue sur le build affecté :
Request: GET /callback?code=ATTACKER-SUPPLIED-AUTH-CODE (no 'state' parameter)
Callback HTTP status: 302
>>> PROVEN: the callback redeemed the authorization code ... WITHOUT verifying a state parameter ... login CSRF.
| Propriété | Valeur |
|---|---|
| Composant | camel-oauth (callback authorization-code, OAuthCodeFlowCallback) |
| CWE | CWE-352 (Cross-Site Request Forgery) |
| Sévérité | MOYENNE |
| Vecteur d'attaque | Une requête de callback transportant un code d'autorisation sans state lié à la requête d'autorisation de la session |
| Impact | CSRF de connexion (la victime est connectée avec une identité contrôlée par l'attaquant) ; redirection ouverte depuis une origine de confiance |
| Versions affectées | À partir de 4.11.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-24437 |
| Crédit | Claude Security Scan Tool |
Avis : https://camel.apache.org/security/CVE-2026-84178.html
Le callback transporte désormais et vérifie un paramètre state à usage unique lié à la requête d'autorisation que la session
a initiée : expectedState = session.removeValue(OAUTH_STATE), comparé (en temps constant) au paramètre de requête
state. Si aucun flux n'est en cours, ou si le state ne correspond pas, le callback rejette la requête avant
d'échanger le code.
Placez le callback derrière un composant qui impose une liaison CSRF state, ou ne vous appuyez pas sur le callback
du flux de code OAuth pour l'établissement de session, jusqu'à ce que vous puissiez mettre à jour.
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. Le fournisseur d'identité factice et le « code de l'attaquant » sont des fixtures locales inertes. N'utilisez pas ce matériel contre des systèmes que vous ne possédez pas ou n'exploitez pas.