oscerd/cve-2026-85300Runnable Spring Boot and Quarkus reproducer for CVE-2026-85300, demonstrating camel-pqc writing private keys with permissive umask-derived file permissions and verifying the fix.
Runnable proof-of-concept reproducer for the Apache Camel vulnerability where camel-pqc's
FileBasedKeyLifecycleManager wrote generated key material to disk with the permissions the process default umask
produced, rather than restricting the file to its owner. On a host whose umask allows group or world read (the
common 022), the unencrypted private key was readable by other local accounts. The exposure is to a local party
rather than the remote sender, but where it applies the consequence is complete: possession of the private key
defeats every signature and key exchange the deployment performs with it.
| Runtime | Directory | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-pqc 4.22.0 (affected; fixed 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.39.0 + camel-quarkus-pqc (Camel 4.22.0, affected; fixed control CQ 3.40.0 / Camel 4.22.1) |
Both modules demonstrate the affected and the fixed behaviour. Both run under umask 022 (the common default),
which is the premise of the flaw.
The driver uses the real FileBasedKeyLifecycleManager: it stores an RSA key pair to a fresh directory
(manager.storeKey("k1", keyPair, new KeyMetadata("k","RSA"))) and then reads the POSIX permissions of the written
k1.private.json.
rw-r--r-- (0644) under umask 022 — so group
and others can read the unencrypted private key.rw------- (0600, owner only) regardless of the umask.# 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-------
| Property | Value |
|---|---|
| Component | camel-pqc (FileBasedKeyLifecycleManager.storeKey) |
| CWE | CWE-276 (Incorrect Default Permissions) |
| Severity | MEDIUM |
| Attack vector | A local account able to read the key directory on a host with a permissive (e.g. 022) umask |
| Impact | Disclosure of the unencrypted private key to other local accounts |
| Affected Versions | From 4.12.0 before 4.18.5, from 4.19.0 before 4.22.1 |
| Fixed Versions | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24447 |
| Credit | Claude Security Scan Tool |
Advisory: https://camel.apache.org/security/CVE-2026-85300.html
The Quarkus affected module is built on CQ 3.39.0 (Camel 4.22.0):
camel-quarkus-pqcfirst maps to an affected Camel version there (CQ 3.29.0 / Camel 4.15.0 predates the file-based key lifecycle manager used here).
FileBasedKeyLifecycleManager now restricts the key directory and each
private key file to their owner (rwx------ / rw------- via setPosixFilePermissions, with a java.io.File
fallback for non-POSIX file systems) before writing, and tightens a pre-existing world-readable key file on rewrite
(the file is truncated, not recreated, so it would otherwise keep the old permissions). Key material already written
with permissive permissions should be treated as exposed and rotated.
Place the key directory on a path only the service account can traverse and tighten the process umask; treat any key already written with permissive permissions as exposed and rotate it.
This repository is published for educational and defensive purposes: to help Apache Camel users understand the vulnerability, verify whether they are affected, and confirm that upgrading resolves it. The RSA key pair is generated in-process into a temporary directory and removed after the check. Do not use this material against systems you do not own or operate.