CVE-2026-85248
Camel-PQC: signature verification bypass - one java.security.Signature instance was shared across concurrent exchanges without synchronization, so interleaved use could make a verification succeed for data it never covered
Description
The producer held a single java.security.Signature instance and used it for every exchange without synchronizing access. Signature is stateful and is not thread safe: update() accumulates the data to be signed or verified, and verify() consumes that accumulated state. With concurrent exchanges sharing one instance the update and verify calls of different messages interleave, so a verification can complete against data that belongs to another exchange, or against a partially accumulated buffer. The outcome is non-deterministic and includes a verification reporting success for a message whose signature was never actually checked, which defeats the guarantee the component exists to provide. Reaching it requires concurrent traffic through the same endpoint, which is the ordinary condition for a Camel route under load.
Mitigation
Credit
This issue was discovered by Claude Security Scan Tool
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24445 refers to the various commits that resolved the issue, and has more details.
The fix was merged on main in https://github.com/apache/camel/pull/25825 (commit 91d5bdac51182fda8515e5b200e8aa842ccd1bc6), backported to camel-4.22.x in https://github.com/apache/camel/pull/25850 (commit 936a851a2b92c29712a77080fa0935b361179f83) and to camel-4.18.x in https://github.com/apache/camel/pull/25851 (commit 1466b0fdf5a6e9a8fd859893f9b245218f30ea17).
The issue is classified as CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization. The camel-4.14.x line reached end of life before this fix and does not receive it; deployments on 4.14.x should move to 4.18.5 or later.