oscerd/cve-2026-85300Lauffähiger Spring Boot- und Quarkus-Reproducer für CVE-2026-85300, der demonstriert, wie camel-pqc private Schlüssel mit permissiven, aus der umask abgeleiteten Dateiberechtigungen schreibt, und die Behebung verifiziert.
Lauffähiger Proof-of-Concept-Reproduzierer für die Apache-Camel-Schwachstelle, bei der camel-pqc's
FileBasedKeyLifecycleManager generiertes Schlüsselmaterial mit den Berechtigungen, die die Standard-umask des Prozesses
erzeugte, auf die Festplatte schrieb, anstatt die Datei auf ihren Eigentümer zu beschränken. Auf einem Host, dessen umask Gruppen- oder Welt-Lesezugriff erlaubt (die
übliche 022), war der unverschlüsselte private Schlüssel für andere lokale Konten lesbar. Die Exposition betrifft eine lokale Partei
und nicht den entfernten Absender, aber wo sie zutrifft, ist die Konsequenz vollständig: Der Besitz des privaten Schlüssels
macht jede Signatur und jeden Schlüsselaustausch zunichte, die die Bereitstellung damit durchführt.
| Laufzeitumgebung | Verzeichnis | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-pqc 4.22.0 (betroffen; behoben in 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.39.0 + camel-quarkus-pqc (Camel 4.22.0, betroffen; behobene Kontrolle CQ 3.40.0 / Camel 4.22.1) |
Beide Module demonstrieren das betroffene und das behobene Verhalten. Beide laufen unter umask 022 (der übliche Standard),
was die Prämisse der Schwachstelle ist.
Der Treiber verwendet den echten FileBasedKeyLifecycleManager: Er speichert ein RSA-Schlüsselpaar in einem frischen Verzeichnis
(manager.storeKey("k1", keyPair, new KeyMetadata("k","RSA"))) und liest dann die POSIX-Berechtigungen der geschriebenen
k1.private.json.
rw-r--r-- (0644) unter umask 022 —, sodass Gruppe
und Andere den unverschlüsselten privaten Schlüssel lesen können.rw------- (0600, nur Eigentümer) geschrieben.# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected: rw-r--r-- private key; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
umask 022 && java -jar target/cve-2026-85300-pqc-key-permissions-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack # fixed: rw------- ; >>> 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): rw-r--r-- private key
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
umask 022 && java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack # fixed: rw-------
| Eigenschaft | Wert |
|---|---|
| Komponente | camel-pqc (FileBasedKeyLifecycleManager.storeKey) |
| CWE | CWE-276 (Falsche Standardberechtigungen) |
| Schweregrad | MITTEL |
| Angriffsvektor | Ein lokales Konto, das das Schlüsselverzeichnis auf einem Host mit einer permissiven (z. B. 022) umask lesen kann |
| Auswirkung | Offenlegung des unverschlüsselten privaten Schlüssels gegenüber anderen lokalen Konten |
| Betroffene Versionen | Ab 4.12.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-24447 |
| Danksagung | Claude Security Scan Tool |
Sicherheitshinweis: https://camel.apache.org/security/CVE-2026-85300.html
Das betroffene Quarkus-Modul basiert auf CQ 3.39.0 (Camel 4.22.0):
camel-quarkus-pqcwird erst dort einer betroffenen Camel-Version zugeordnet (CQ 3.29.0 / Camel 4.15.0 liegt vor dem hier verwendeten dateibasierten Key-Lifecycle-Manager).
FileBasedKeyLifecycleManager beschränkt nun das Schlüsselverzeichnis und jede
Datei mit privatem Schlüssel auf ihren Eigentümer (rwx------ / rw------- via setPosixFilePermissions, mit einem java.io.File-
Fallback für Nicht-POSIX-Dateisysteme) vor dem Schreiben und verschärft eine bereits vorhandene, für alle lesbare Schlüsseldatei beim
Überschreiben (die Datei wird abgeschnitten, nicht neu erstellt, sodass sie andernfalls die alten Berechtigungen behalten würde). Schlüsselmaterial, das bereits
mit permissiven Berechtigungen geschrieben wurde, sollte als offengelegt betrachtet und rotiert werden.
Legen Sie das Schlüsselverzeichnis auf einem Pfad ab, den nur das Dienstkonto durchlaufen kann, und verschärfen Sie die Prozess-umask; behandeln Sie jeden Schlüssel, der bereits mit permissiven Berechtigungen geschrieben wurde, als offengelegt und rotieren Sie ihn.
Dieses Repository wird zu Bildungs- und Verteidigungszwecken veröffentlicht: um Apache-Camel-Nutzern zu helfen, die Schwachstelle zu verstehen, zu überprüfen, ob sie betroffen sind, und zu bestätigen, dass ein Upgrade sie behebt. Das RSA-Schlüsselpaar wird im Prozess in einem temporären Verzeichnis generiert und nach der Prüfung entfernt. Verwenden Sie dieses Material nicht gegen Systeme, die Ihnen nicht gehören oder die Sie nicht betreiben.