Apache Camel EUVD-2026-30895

Exploitation requires (1) a Camel deployment running an affected version (3.18.0-4.14.5 or 4.15.0-4.18.1) that (2) exposes an HTTP-reachable consumer endpoint built on camel-cxf-rest, camel-cxf-transport, or camel-knative-http, and (3) routes messages from that endpoint into a header-driven downstream component - most dangerously camel-exec (yields RCE via CamelExecCommandExecutable) or camel-file (yields arbitrary file write via CamelFileName), though any component that reads Camel-internal headers as control input is in scope. No authentication and no user interaction are required (CVSS PR:N/UI:N), and attack complexity is low (AC:L). Limiting factors: installations that expose CXF or Knative endpoints but do not chain them to header-driven sinks are not exploitable, and any network-layer header stripping in front of the endpoint blocks the vector.

Signals here pull in opposite directions and need to be reconciled before prioritization. CVSS 9.8 (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H) and SSVC Technical Impact 'total' reflect the worst-case ceiling - unauthenticated network RCE - and CPE confirms the broad Apache Camel surface. However, SSVC Exploitation is 'none', Automatable is 'no', EPSS is 0.04% (12th percentile), and the CVE is not in CISA KEV, indicating no observed exploitation. The mitigating factor not captured in CVSS is that exploitation requires a deployed route that both exposes a CXF-RS, CXF-SOAP, or Knative HTTP endpoint AND forwards messages downstream into a header-driven sink (camel-exec, camel-file, or similar) - vulnerable installs depend on routing topology, not merely on having Camel installed. Given four prior incidents of the same defect class (CVE-2025-27636, 2025-29891, 2025-30177, 2026-40453), defenders should assume PoC weaponization is straightforward for anyone who has examined the earlier patches, even though no public exploit is identified at time of analysis.

An attacker sends a single crafted HTTP POST to an internet-exposed CXF-RS endpoint that a Camel route forwards into a camel-exec component, supplying an HTTP header such as 'CamelExecCommandExecutable: /bin/sh' alongside a 'CamelExecCommandArgs' header pointing to a downloader one-liner. The unfiltered header overrides the route's configured command, and the camel-exec component spawns the attacker-chosen binary under the Camel process identity, yielding code execution without authentication. The same primitive against a camel-file sink lets the attacker write a webshell to a known web-served path via CamelFileName.