oscerd/cve-2026-85296Ausführbare Spring-Boot- und Quarkus-Proof-of-Concept, die CVE-2026-85296 reproduziert, eine partnerübergreifende MDN-Signaturschlüssel-Verwechslung (CWE-488) in camel-as2, mit betroffenen und korrigierten Builds.
Lauffähiger Proof-of-Concept-Reproduzierer für die Apache-Camel-Schwachstelle, bei der pro Anfrage bestimmtes Signaturmaterial in
zustand, der über Anfragen hinweg geteilt wird, gehalten wurde, statt auf die gerade verarbeitete Anfrage beschränkt zu sein. Ein einzelnes ResponseMDN wird
auf dem geteilten HttpProcessor registriert und bedient jede AS2-Anfrage; in der Dynamic-Keys-Konfiguration (ein Handelspartner
pro Pfad, jeder mit eigenen, pro Anfrage aus dem HttpContext aufgelösten Schlüsseln) schrieb der betroffene Build den
aufgelösten Signaturschlüssel pro Anfrage zurück in ein Instanzfeld. Wenn eine Bereitstellung mehr als einen Partner bedient,
konnten gleichzeitige oder aufeinanderfolgende Anfragen daher das Material des jeweils anderen beobachten, und eine Message Disposition
Notification konnte mit dem Schlüssel eines anderen Handelspartners signiert werden. AS2-Bereitstellungen sind typischerweise
von Natur aus Multi-Partner-Umgebungen, sodass die Bedingung durch gewöhnlichen gleichzeitigen Datenverkehr erreicht wird.
| Laufzeitumgebung | Verzeichnis | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-as2 4.22.0 (betroffen; behoben in 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.39.0 + camel-quarkus-as2 (Camel 4.22.0, betroffen; behobene Kontrolle CQ 3.40.0 / Camel 4.22.1) |
Beide Module demonstrieren das betroffene und das behobene Verhalten.
Der Treiber verwendet das echte ResponseMDN (den AS2-Response-Interceptor) in seiner Dynamic-Keys-Form. Er löst nacheinander das Signaturmaterial
zweier Partner auf — Partner A, dann Partner B — über ResponseMDN.process(...) (jeweils mit dem RSA-Schlüssel des Partners im
HttpContext) und liest danach jeweils das Feld signingPrivateKey der Instanz aus.
final und wird nie geschrieben; der Schlüssel pro Anfrage bleibt auf die Anfrage beschränkt, sodass
signingPrivateKey der geteilten Instanz null bleibt.# 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
| Eigenschaft | Wert |
|---|---|
| Komponente | camel-as2 (Handhabung dynamischer Schlüssel in ResponseMDN) |
| CWE | CWE-488 (Offenlegung eines Datenelements gegenüber der falschen Sitzung) |
| Schweregrad | MITTEL |
| Angriffsvektor | Gewöhnlicher gleichzeitiger AS2-Datenverkehr in einer Multi-Partner-Bereitstellung, die sich eine ResponseMDN-Instanz teilt |
| Auswirkung | Eine mit dem privaten Schlüssel eines anderen Handelspartners signierte Message Disposition Notification; Wiederverwendung von Signaturmaterial zwischen Partnern |
| Betroffene Versionen | Ab 4.0.0 vor 4.18.5, ab 4.19.0 vor 4.22.1 |
| Behobene Versionen | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24429 |
| Danksagung | Claude Security Scan Tool |
Advisory: https://camel.apache.org/security/CVE-2026-85296.html
Das betroffene Quarkus-Modul basiert auf CQ 3.39.0 (Camel 4.22.0): Der dynamische, pro Anfrage arbeitende AS2-Signaturschlüsselmechanismus, den dieser PoC ausnutzt, ist neuer als CQ 3.29.0 (Camel 4.15.0), sodass CQ 3.39.0 dasselbe Camel 4.22.0 wie das Spring-Boot-Modul ausliefert.
ResponseMDN macht die konfigurierten Sicherheitsfelder final und löst
das dynamische Material pro Anfrage in lokale Variablen innerhalb von process() auf, ohne es jemals in
Instanzfelder zurückzuschreiben. Eine einzelne gemeinsam genutzte Instanz kann daher nicht länger den Signaturschlüssel
einer Anfrage an eine andere Anfrage weitergeben.
Betreiben Sie einen separaten Camel-Kontext pro Handelspartner, sodass kein Signaturmaterial zwischen ihnen geteilt wird.
Dieses Repository wird zu Bildungs- und Verteidigungszwecken veröffentlicht: um Apache-Camel-Nutzern zu helfen, die Schwachstelle zu verstehen, zu prüfen, ob sie betroffen sind, und zu bestätigen, dass ein Upgrade sie behebt. Die RSA-Schlüsselpaare werden für die Demonstration im Prozess erzeugt und sind wirkungslos. Verwenden Sie dieses Material nicht gegen Systeme, die Ihnen nicht gehören oder die Sie nicht betreiben.