oscerd/cve-2026-84178Riproduttore proof-of-concept eseguibile per CVE-2026-84178, una CSRF di login nel callback authorization-code di camel-oauth di Apache Camel che riscatta i codici senza verificare lo state.
state mancante)Reproduttore proof-of-concept eseguibile per la vulnerabilità di Apache Camel in cui il callback OAuth authorization-code
non trasportava un parametro state che lo legasse alla richiesta di autorizzazione che aveva avviato il flusso, e non ne
verificava alcuno. Un authorization code ottenuto in qualsiasi browser poteva quindi essere riscattato al callback e associato
alla sessione che lo presentava — cross-site request forgery di login: una vittima viene silenziosamente autenticata come
un'identità controllata dall'attaccante, così le azioni e i dati successivi della vittima finiscono nell'account dell'attaccante. (Lo
stesso callback non validato consentiva anche di influenzare la destinazione del redirect post-autenticazione — un open redirect.)
Come nota l'advisory, il controllo dello state viene eseguito prima che il code venga riscattato, quindi la differenza è raggiungibile senza
alcuna interazione con l'identity provider.
| Runtime | Directory | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-oauth 4.22.0 (affetto; corretto in 4.22.1), callback tramite camel-undertow |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.39.0 + camel-quarkus-oauth 3.39.0 (Camel 4.22.0, affetto; controllo corretto 3.40.0 / Camel 4.22.1), callback tramite camel-quarkus-platform-http |
Entrambi i moduli dimostrano il comportamento affetto e quello corretto.
Il processore reale e non modificato OAuthCodeFlowCallback gestisce l'endpoint di callback. Uno stub OAuth minimale è
registrato nel registry di Camel così che il callback funzioni senza un identity provider attivo — sostituisce solo
l'IdP e registra quando un authorization code viene riscattato (il che, nel flusso reale, lega l'identità risultante alla
sessione che lo presenta). L'attaccante colpisce semplicemente il callback con un code e senza alcun state corrispondente:
state
corrispondente alla richiesta di autorizzazione avviata da questa sessione) — il code non viene mai riscattato.cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
Output previsto sulla build interessata:
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.
| Proprietà | Valore |
|---|---|
| Componente | camel-oauth (callback del flusso authorization-code, OAuthCodeFlowCallback) |
| CWE | CWE-352 (Cross-Site Request Forgery) |
| Gravità | MEDIA |
| Vettore di attacco | Una richiesta di callback che trasporta un authorization code senza alcun state associato alla richiesta di autorizzazione della sessione |
| Impatto | Login CSRF (la vittima viene autenticata con un'identità controllata dall'attaccante); open redirect da un'origine attendibile |
| Versioni interessate | Dalla 4.11.0 precedente alla 4.18.5, dalla 4.19.0 precedente alla 4.22.1 |
| Versioni corrette | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24437 |
| Credito | Claude Security Scan Tool |
Advisory: https://camel.apache.org/security/CVE-2026-84178.html
Il callback ora trasporta e verifica un parametro state monouso associato alla richiesta di autorizzazione avviata
dalla sessione: expectedState = session.removeValue(OAUTH_STATE), confrontato (a tempo costante) con il parametro
di query state. Se nessun flusso è in corso, o se lo state non corrisponde, il callback rifiuta la richiesta prima
di riscattare il code.
Posizionare il callback dietro un componente che imponga un binding CSRF tramite state, oppure non fare affidamento
sul callback del flusso code OAuth per l'instaurazione della sessione, finché non sarà possibile aggiornare.
Questo repository è pubblicato per scopi educativi e difensivi: per aiutare gli utenti di Apache Camel a comprendere la vulnerabilità, verificare se sono interessati e confermare che l'aggiornamento la risolve. L'identity provider stub e il "codice dell'attaccante" sono fixture locali inerti. Non utilizzare questo materiale contro sistemi di cui non si è proprietari o gestori.