
Proof-of-concept eseguibile per Spring Boot e Quarkus che riproduce CVE-2026-85296, una confusione di chiavi di firma MDN tra partner in camel-as2 (CWE-488), con build vulnerabili e corrette.
PoC riproducibile ed eseguibile per la vulnerabilità di Apache Camel in cui il materiale di firma per richiesta era mantenuto in
stato condiviso tra le richieste anziché confinato alla richiesta in elaborazione. Un singolo ResponseMDN è
registrato sull'HttpProcessor condiviso e serve ogni richiesta AS2; nella configurazione a chiavi dinamiche (un partner
commerciale per percorso, ciascuno con le proprie chiavi risolte per richiesta dall'HttpContext) la build interessata scriveva la
chiave di firma risolta per richiesta su un campo di istanza. Laddove un deployment serve più di un partner,
richieste concorrenti o successive potevano quindi osservare il materiale l'una dell'altra, e una Message Disposition
Notification poteva essere firmata con la chiave di un diverso partner commerciale. I deployment AS2 sono tipicamente
multi-partner per progettazione, quindi la condizione si raggiunge con normale traffico concorrente.
| Runtime | Directory | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-as2 4.22.0 (interessata; corretta 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.39.0 + camel-quarkus-as2 (Camel 4.22.0, interessata; controllo corretto CQ 3.40.0 / Camel 4.22.1) |
Entrambi i moduli dimostrano il comportamento interessato e quello corretto.
Il driver utilizza il vero ResponseMDN (l'interceptor di risposta AS2) nella sua forma a chiavi dinamiche. Risolve in sequenza il materiale
di firma di due partner — Partner A, poi Partner B — tramite ResponseMDN.process(...) (ciascuno con la chiave RSA di quel
partner nell'HttpContext), e legge il campo signingPrivateKey dell'istanza dopo ciascuno.
final e non viene mai scritto; la chiave per richiesta resta confinata alla richiesta, quindi
il signingPrivateKey dell'istanza condivisa resta null.# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected: per-request key on the shared instance; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85296-as2-signing-key-confusion-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack # fixed: field stays null; >>> 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.22.0): per-request key on the shared instance
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: field stays null
| Proprietà | Valore |
|---|---|
| Componente | camel-as2 (gestione delle chiavi dinamiche di ResponseMDN) |
| CWE | CWE-488 (Esposizione di un elemento dati alla sessione errata) |
| Gravità | MEDIA |
| Vettore di attacco | Traffico AS2 concorrente ordinario in una distribuzione multi-partner che condivide un'unica istanza di ResponseMDN |
| Impatto | Una Message Disposition Notification firmata con la chiave privata di un altro trading partner; riutilizzo del materiale di firma tra partner |
| Versioni interessate | Dalla 4.0.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-24429 |
| Credito | Claude Security Scan Tool |
Avviso: https://camel.apache.org/security/CVE-2026-85296.html
Il modulo Quarkus interessato è basato su CQ 3.39.0 (Camel 4.22.0): il meccanismo dinamico di chiave di firma AS2 per richiesta esercitato da questo PoC è successivo a CQ 3.29.0 (Camel 4.15.0), quindi CQ 3.39.0 distribuisce lo stesso Camel 4.22.0 del modulo Spring Boot.
ResponseMDN rende final i campi di sicurezza configurati e risolve
il materiale dinamico per richiesta in variabili locali all'interno di process(), senza mai riscriverlo nei
campi dell'istanza. Un'unica istanza condivisa non può quindi più far trapelare la chiave di firma di una richiesta
verso un'altra richiesta.
Eseguire un contesto Camel separato per ciascun trading partner, in modo che nessun materiale di firma venga condiviso tra di essi.
Questo repository è pubblicato per scopi educativi e difensivi: per aiutare gli utenti di Apache Camel a comprendere la vulnerabilità, verificare se ne sono interessati e confermare che l'aggiornamento la risolve. Le coppie di chiavi RSA sono generate in-process per la dimostrazione e sono inerti. Non utilizzare questo materiale contro sistemi di cui non si è proprietari o che non si gestiscono.