Apache Camel CVE-2026-27172

Requires the target to be running the camel-consul component with a Consul-backed ConsulRegistry, AND the attacker must have write access to the specific Consul KV store backing that registry. Exploitation triggers automatically on the next Camel registry lookup with no attacker-side user interaction (UI:N). Limiting factors: the vulnerable Consul-registry configuration is optional and not a Camel default, the Consul KV store is not normally internet-exposed and typically requires Consul ACL/network access to write, and a usable Java gadget chain must be present on the Camel classpath. These constraints, not raw CVSS, explain the low EPSS and SSVC 'Automatable: no'.

Signals conflict in an informative way. CVSS 3.1 rates this 8.8 (AV:N/AC:L/PR:L/UI:N, C:H/I:H/A:H) - network-reachable, low-complexity, low-privilege full RCE. However, EPSS is only 0.08% (24th percentile) and CISA SSVC scores Exploitation: none, Automatable: no, Technical Impact: partial, indicating no observed exploitation and a non-trivial precondition. The reconciling factor is the real prerequisite the CVSS network vector understates: the attacker must already be able to WRITE to the Consul KV store backing the registry, which is not an internet-exposed default and typically requires network position or Consul ACL access. Consequently this is a serious, patch-worthy RCE for organizations running the specific Consul-registry configuration, but the low EPSS and 'Automatable: no' rating suggest targeted rather than opportunistic mass exploitation. Treat as high priority where camel-consul registry is in use, moderate elsewhere.

An attacker who gains write access to the Consul KV store - via weak or absent Consul ACLs, a shared cluster, or a foothold on an adjacent service - stores a crafted Java gadget-chain object under a key the ConsulRegistry reads. The next time the Camel application performs a registry lookup, ConsulRegistryUtils.deserialize calls ObjectInputStream.readObject() on the malicious blob and executes attacker code in the Camel process. No public exploit is identified at time of analysis, though the technique reuses well-known Java deserialization gadget chains.