CVE-2026-85257 — camel-cxf: Offenlegung von Informationen in SOAP-Faults

Lauffähiger Proof-of-Concept-Reproducer für die Apache-Camel-Schwachstelle, bei der – wenn eine Route hinter einem CXF-SOAP-Consumer mit einer Exception fehlschlug, die der Service-Vertrag nicht deklariert – die Exception im Fault an den SOAP-Client zurückgemeldet wurde: CXF kopiert die Nachricht in den SOAP-faultstring (und kann so konfiguriert werden, dass der Stacktrace in das Fault-Detail geschrieben wird). Ein externer Aufrufer, der einen Fehler provozieren konnte, konnte somit interne Details über die Bereitstellung auslesen – Klassen- und Paketnamen sowie alles, was die Exception-Nachricht enthält. Deklarierte Faults (annotiert mit @WebFault) sind etwas anderes: Sie sind Teil des veröffentlichten Vertrags, gegen den Clients geschrieben werden, und werden daher weiterhin vollständig gemeldet.

Laufzeitumgebung	Verzeichnis	Stack
Camel Spring Boot	camel-spring-boot/	Spring Boot 3.5.13 + camel-cxf-soap 4.22.0 (betroffen; behoben in 4.22.1), CXFServlet auf Tomcat
Camel Quarkus	camel-quarkus/	Quarkus 3.29.0 + camel-quarkus-cxf-soap (Camel 4.15.0, betroffen; behobene Kontrolle CQ 3.40.0 / Camel 4.22.1)

Beide Module demonstrieren das betroffene und das behobene Verhalten.

Was es demonstriert

Ein CXF-SOAP-Consumer steht hinter einer Route, deren Processor eine nicht deklarierte IllegalStateException wirft, die simulierte interne Details trägt (ein Marker-Token und eine gefälschte interne JDBC-URL). Der Treiber agiert als SOAP-Client: Er ruft den Service auf und liest den zurückgegebenen SOAP-Fault aus.

• Betroffen: Der SOAP-Fault enthält die Nachricht der Route-Exception (den internen Marker / die JDBC-URL) – interne Bereitstellungsdetails erreichen den Aufrufer.
• Behoben: Der Fault ist generisch – Exchange processing failed – und enthält weder Klasse, Nachricht noch Stacktrace der Route-Exception (die neue Consumer-Option muteException ist standardmäßig true). Ein Fault, den der Vertrag deklariert (@WebFault), würde weiterhin vollständig zurückgegeben.

# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected: fault leaks internal detail; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85257-cxf-fault-info-disclosure-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: generic fault; >>> 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.15.0): fault leaks internal detail
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: generic fault

Zusammenfassung der Schwachstelle

Eigenschaft	Wert
Komponente	camel-cxf (CxfConsumer, Erstellung von SOAP-Faults)
CWE	CWE-209 (Erzeugung einer Fehlermeldung mit sensiblen Informationen)
Schweregrad	MITTEL
Angriffsvektor	Ein SOAP-Aufrufer löst einen nicht deklarierten Routenfehler aus und liest die Ausnahmedetails aus dem Fault
Auswirkung	Offenlegung von Informationen: Ausnahmeklasse/-meldung (interne Hostnamen, Verbindungszeichenfolgen, Routenstruktur) gelangen an einen externen SOAP-Aufrufer
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-24477
Danksagung	Claude Security Scan Tool

Advisory: https://camel.apache.org/security/CVE-2026-85257.html

Das Spring-Boot-Modul bindet das CXFServlet an den eingebetteten Tomcat (ein eigenständiger CXF-Jetty-Transport kollidiert mit der von Spring Boot verwalteten Jetty-Version), sodass der SOAP-Endpunkt unter /services/hello auf Port 8080 bereitgestellt wird.

Die Korrektur

CxfConsumer fügt eine Consumer-Option muteException hinzu (Standard true). Bei einem nicht deklarierten Routenfehler wird der Fault nun aus einer Ersatz-Exception("Exchange processing failed") mit leerem Stack-Trace aufgebaut, statt aus der Ausnahme der Route – sodass weder Klassenname, Meldung noch Stack-Trace an den Aufrufer gelangen. Eine vom Vertrag deklarierte Ausnahme (@WebFault) wird erkannt und vollständig gemeldet, da eine Unterdrückung den Dienst beeinträchtigen würde. Setzen Sie muteException=false, um die vorherige Ausgabe wiederherzustellen.

Gegenmaßnahmen, falls ein Upgrade nicht möglich ist

Deklarieren Sie die Ausnahmen, die der Dienst melden darf, und ordnen Sie jeden anderen Fehler einem davon in einem onException-Handler zu, sodass keine nicht deklarierte Ausnahme den Fault erreicht.

Haftungsausschluss

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. Das Marker-Token und die JDBC-URL in der fehlschlagenden Route sind inerte, erfundene lokale Testdaten. Verwenden Sie dieses Material nicht gegen Systeme, die Ihnen nicht gehören oder die Sie nicht betreiben.