Apache Camel EUVD-2026-25790

Exploitation requires the application to be using the camel-pqc FileBasedKeyLifecycleManager with a file-backed key store, and the attacker must be able to write or replace a <keyId>.key file in the configured key directory. The description names the concrete avenues: a path traversal that reaches the key directory, misconfigured filesystem permissions on the key volume, a compromised key provisioning pipeline, or a symlink attack. A key lifecycle operation must then deserialize the planted file for the payload to fire. Limiting factors: the vector is local (AV:L) and requires low privileges (PR:L) - there is no purely remote, unauthenticated path; only vulnerable 4.18.0-4.18.1 and 4.19.0 deployments actually running the PQC key management feature are exposed, and a properly locked-down key directory neutralizes the practical attack surface.

Signals are consistent and point to a genuine-but-conditional risk rather than a mass-exploitation emergency. The CVSS vector (AV:L/AC:L/PR:L/UI:N, C:H/I:H/A:H) and SSVC 'Technical Impact: total' both reflect that successful exploitation gives full compromise of the application, but AV:L plus the description confirm the attacker must already be able to write into the key directory. SSVC 'Exploitation: none' and 'Automatable: no' align with the very low EPSS (0.07%, 22nd percentile) and the absence of KEV listing or public PoC - this is not opportunistically wormable. The practical priority is therefore driven by whether the affected 4.18.x/4.19.x PQC feature is actually in use and how well the key directory is isolated; where it is used, the total-impact outcome justifies prompt patching, but for most estates this is a moderate, patch-in-normal-cycle item. No major conflicts exist between sources; the only caveat is that the local write precondition means raw CVSS 7.8 overstates remote risk against a hardened deployment.

An attacker gains write access to the Camel key directory - for example by exploiting a path-traversal upload, abusing loose permissions on the mounted key volume, or compromising the key-provisioning pipeline - and drops a malicious <keyId>.key file containing a serialized gadget-chain object. During the next routine key lifecycle operation the application calls readObject() on that file, executing the gadget's side effects and running attacker code in the application's context before the failed KeyPair cast is ever reached. No public exploit is identified at time of analysis, though the deserialization pattern is well understood and gadget chains are widely available.