Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2026-85296 — 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. | Kitploit
Strumenti/GitHubGitHub/oscerd/cve-2026-85296
Analisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebCrittografiaApprendimento e Formazione
GitHuboscerd/cve-2026-85296

CVE-2026-85296

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.

Vedi Repository
41 giorno faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

CVE-2026-85296 — camel-as2: confusione della chiave di firma MDN tra partner

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.

RuntimeDirectoryStack
Camel Spring Bootcamel-spring-boot/Spring Boot 3.5.13 + camel-as2 4.22.0 (interessata; corretta 4.22.1)
Camel Quarkuscamel-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.

Cosa dimostra

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.

  • Interessata: dopo aver gestito la richiesta del Partner A l'istanza condivisa contiene la chiave privata del Partner A; dopo quella del Partner B contiene quella del Partner B. La chiave per richiesta è memorizzata sull'istanza condivisa, quindi una richiesta concorrente per un partner può leggere — e firmare il proprio MDN con — la chiave di un altro partner.
  • Corretta: il campo è 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

Riepilogo della vulnerabilità

ProprietàValore
Componentecamel-as2 (gestione delle chiavi dinamiche di ResponseMDN)
CWECWE-488 (Esposizione di un elemento dati alla sessione errata)
GravitàMEDIA
Vettore di attaccoTraffico AS2 concorrente ordinario in una distribuzione multi-partner che condivide un'unica istanza di ResponseMDN
ImpattoUna Message Disposition Notification firmata con la chiave privata di un altro trading partner; riutilizzo del materiale di firma tra partner
Versioni interessateDalla 4.0.0 precedente alla 4.18.5, dalla 4.19.0 precedente alla 4.22.1
Versioni corrette4.18.5, 4.22.1, 4.23.0
JIRACAMEL-24429
CreditoClaude 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.

La correzione

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.

Mitigazione se non è possibile aggiornare

Eseguire un contesto Camel separato per ciascun trading partner, in modo che nessun materiale di firma venga condiviso tra di essi.

Disclaimer

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.

Scarica lo strumento