Apache Camel PQC EUVD-2026-104189

Exploitable only when a route uses the camel-pqc component's signature sign/verify operation and the producer is invoked by concurrent exchanges through the same endpoint - the default for a Camel route under load with multiple concurrent consumers. The core prerequisite is concurrency: the single shared, stateful java.security.Signature instance must have two exchanges interleaving their init/update/verify sequences. Limiting factors that reduce real-world risk: high attack complexity (AC:H) because the race window is timing-dependent and non-deterministic rather than attacker-controlled; the issue is confined to deployments actually using PQC signature verification; and the vendor-documented mitigation of restricting the affected route to a single concurrent consumer eliminates the condition entirely without upgrading.

This is a moderate, integrity-focused flaw that should be prioritized by the small subset of deployments actually using the Apache Camel PQC component, but is not a broad emergency. The vendor CVSS (5.9, AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) correctly captures the shape: network-reachable, no privileges or user interaction, but high attack complexity because success depends on a non-deterministic race window, and the only impact is integrity (C:N/A:N). No EPSS score was provided, there is no CISA KEV listing (not actively exploited per available data), and no public exploit identified at time of analysis - so all three exploitation-pressure signals are either absent or negative, reinforcing that this is a correctness/security-guarantee defect rather than a weaponized bug. The signals are internally consistent (no contradiction between the vector and the description), with one nuance: AC:H plus the race-condition root cause means exploitation is opportunistic/probabilistic rather than reliably attacker-controlled, so the real-world danger is less 'attacker forges a signature on demand' and more 'under concurrent load the component silently accepts a message whose signature was never checked.' The severity that matters is contextual - where this component is the security boundary (signature verification), a false 'verified' result fully defeats the control it exists to provide.

An application routes messages through a Camel PQC endpoint that verifies post-quantum signatures, with the normal multiple-concurrent-consumer configuration. Under concurrent traffic, two exchanges interleave on the single shared java.security.Signature instance so that one message's verify() consumes another message's accumulated state, causing the component to set VERIFY=true for a message whose signature was never actually validated. No public exploit code is known, and the high attack complexity means the outcome is non-deterministic rather than reliably triggerable.