Apache Camel has an incomplete fix for CVE-2025-27636

1. Executive summary

Apache Camel's fix for CVE-2025-27636 added case-insensitive header filtering to HttpHeaderFilterStrategy but left five non-HTTP HeaderFilterStrategy implementations unchanged, so case-variant Camel internal headers such as CAmelExecCommandExecutable still pass inbound filtering on JMS, SJMS, CoAP and Google Pub/Sub consumers. An attacker with producer access to a broker or topic consumed by a Camel route can inject those headers, which downstream components including camel-exec and camel-file resolve using their canonical casing, giving remote code execution and arbitrary file write. The verified reference data records this CVE at CVSS 5.6 MEDIUM, CWE-178, not in CISA KEV, with an EPSS of 97%. The medium base score understates the exposure for any EMEA financial services firm running Camel routes that bridge a JMS, CoAP or Pub/Sub consumer into a header-driven producer, because the outcome on such a route is code execution, not information disclosure. The EPSS figure indicates exploitation is being attempted at scale even though the flaw is not on the KEV list.

2. Regulatory framing

No other article in the reference is directly engaged by this item. The flaw is a library vulnerability with a vendor fix; it is not itself an incident, so the incident-management and reporting articles are not triggered until an exploitation attempt succeeds.

3. Technical analysis & attack chain

The vulnerability is an incomplete fix. CVE-2025-27636 was addressed by calling setLowerCase(true) on HttpHeaderFilterStrategy, which makes the inbound filter compare header names case-insensitively so that CAmelExecCommandExecutable is dropped alongside CamelExecCommandExecutable. That call was not applied to five other HeaderFilterStrategy implementations:

• JmsHeaderFilterStrategy and ClassicJmsHeaderFilterStrategy in camel-jms
• SjmsHeaderFilterStrategy in camel-sjms
• CoAPHeaderFilterStrategy in camel-coap
• GooglePubsubHeaderFilterStrategy in camel-google-pubsub

Those strategies filter with a case-sensitive String.startsWith("Camel") or String.startsWith("camel") test. The Camel Exchange, however, stores headers in a case-insensitive map. A header name that fails the case-sensitive prefix test is therefore admitted into the Exchange, and a later lookup by a downstream component using the canonical casing resolves to the attacker-supplied value.

Confirmed attack chain:

1. The attacker obtains producer access to the JMS broker, CoAP endpoint or Google Pub/Sub topic that a Camel route consumes. The advisory does not state how that access is obtained; it is a precondition, not a step.
2. The attacker publishes a message carrying a case-variant Camel internal header, for example CAmelExecCommandExecutable or a case-variant of CamelFileName.
3. The affected HeaderFilterStrategy evaluates the header name with a case-sensitive startsWith test, the test fails, and the header is copied into the Exchange.
4. The route forwards the message to a header-driven component. camel-exec reads the executable header and runs the named binary; camel-file reads the file-name header and writes to the named path.
5. The downstream component resolves the header using its canonical casing, finds the attacker's value in the case-insensitive map, and acts on it. The result is remote code execution or arbitrary file write.

Affected versions, from the advisory: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0. Fixed versions: 4.20.0 on the current stream, 4.14.6 on the 4.14.x LTS stream, 4.18.2 on the 4.18.x stream.

The precondition is the part that determines real exposure. The attacker needs write access to a broker, topic or endpoint that a Camel route consumes, and the route must forward that message into a header-driven producer. A Camel deployment that consumes only from internal, access-controlled queues and never routes into camel-exec or camel-file is not reachable through this path. A deployment that consumes from a queue reachable by a partner, a shared tenant or an internet-facing CoAP or Pub/Sub endpoint, and that routes into camel-exec or camel-file, is directly exposed.

Related advisories in the same family describe the same filtering gap in other components: Camel-CXF and Camel-Knative missing inbound filtering (setInFilterStartsWith not configured), Camel-Mail filtering only the outbound direction, and camel-vertx-websocket mapping query and path parameters into the Exchange with no HeaderFilterStrategy at all. Those are separate CVEs with separate fixes. They matter here because they show the pattern is recurring across the Camel component set, so a firm that fixes only the five strategies named in this advisory should expect further instances.

Confidence caveat: the technical mechanism above is taken from the GitHub advisory for this CVE and its related advisories, which are the vendor's own publication channel. No independent exploitation reporting, no in-the-wild telemetry and no proof-of-concept code is present in the source material. The EPSS score of 97% in the verified reference data indicates a high probability of exploitation activity in the wild, but the sources do not describe any observed campaign, actor or victim. Treat the exploitation state as high-likelihood and unattributed.

4. Mitigation & containment

P1, within 24 hours:

• Inventory every Camel deployment and record the exact version. The affected ranges are 3.0.0 to before 4.14.6, 4.15.0 to before 4.18.2, and 4.19.0 to before 4.20.0. Check the dependency tree, not just the top-level artifact, because Camel is frequently pulled in transitively by integration platforms.
• For any deployment in those ranges that consumes from JMS, SJMS, CoAP or Google Pub/Sub and routes into camel-exec or camel-file, treat it as exposed. Either take the route out of service or apply the route-level control below before the next message is processed.
• Apply the route-level control at the start of every affected route: removeHeaders("Camel*") and removeHeaders("camel*"). This strips the Camel header namespace before any downstream producer sees it. It is a compensating control, not a fix, and it must be applied to every route that bridges an untrusted consumer into a header-driven producer.
• Restrict producer access to every broker, topic and CoAP endpoint consumed by a Camel route to trusted producers only, using the broker's own authorization. This removes the precondition for the attack.

P2, within 72 hours:

• Upgrade to a fixed version: 4.20.0 on the current stream, 4.14.6 on the 4.14.x LTS stream, 4.18.2 on the 4.18.x stream. Where a third-party platform ships Camel, open the request with the provider and record the response time.
• Where an upgrade cannot be completed inside 72 hours, keep the removeHeaders control in place and document the residual risk against DORA Art. 28.
• Review routes for any consumer that maps external input into Camel-prefixed headers, including the CXF, Knative, Mail and Vert.x WebSocket components covered by the related advisories, and apply the same removeHeaders control there.

P3, within 7 days:

• Add a build-time check that fails the pipeline when a Camel version in an affected range is resolved, so the same gap cannot be reintroduced by a transitive dependency.
• Confirm that no Camel route consumes from a network segment reachable by an unauthenticated or partner-controlled producer. Where one does, require authentication on that endpoint.
• Re-test the removeHeaders control against a message carrying a case-variant header to confirm it strips the namespace as expected.

5. Indicators of compromise

No indicators of compromise available in the source material. The sources describe a vulnerability mechanism and a set of affected components, not an observed intrusion. There are no file hashes, network indicators, filenames or registry keys to publish.

Behavioural indicators:

6. Detection

The sources give no file hashes, no command-line strings, no mutexes and no filenames belonging to the threat itself. The only artefacts are the header names the attack relies on, which are Camel's own internal header names rather than attacker-authored strings. A YARA rule built on those names would detect Camel itself, not an intrusion, so no YARA rule is emitted.

The Sigma rule below targets the observable behaviour: a Camel process launching a child process where the executable path is not the one the route was configured with. It is written against process creation telemetry and requires the Camel process name to be tuned to the deployment.

title: Apache Camel header injection leading to unexpected child process
id: 8f3c1a52-7d4e-4b19-9c2a-6e0b5a1d7f34
status: experimental
description: Detects a child process spawned by a Camel host process where the executable is not a known Camel runtime binary, consistent with camel-exec resolving an attacker-injected CAmelExecCommandExecutable header. Tune ParentImage to the deployment.
author: Adverse Trace
date: 2026-10-05
references:

  - https://github.com/advisories/GHSA-jg2m-9x48-3gvj
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:

      - '/java'
      - '/javaw'
  filter_expected:
    Image|endswith:

      - '/sh'
      - '/bash'
      - '/java'
      - '/javaw'
  condition: selection_parent and not filter_expected
falsepositives:

  - Camel routes that legitimately shell out to a binary other than a shell or the JVM. Enumerate those per deployment before enabling.
level: medium

CVE assessment

1 referenced CVE

7. Sources

• GitHub Security Advisories, "Apache Camel has an incomplete fix for CVE-2025-27636" (GHSA-jg2m-9x48-3gvj), published 2026-04-27. https://github.com/advisories/GHSA-jg2m-9x48-3gvj
• GitHub Security Advisories, "Camel-CXF and Camel-Knative Message Header are Vulnerable to Injection via Missing Inbound Filtering" (GHSA-8364-hfqj-pwm6). https://github.com/advisories/GHSA-8364-hfqj-pwm6
• GitHub Security Advisories, "Apache Camel's Camel-Mail component is vulnerable to Camel message header injection" (GHSA-2vqf-x7g4-7c2g). https://github.com/advisories/GHSA-2vqf-x7g4-7c2g
• GitHub Security Advisories, "Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component" (GHSA-f755-xp6r-8q84). https://github.com/advisories/GHSA-f755-xp6r-8q84
• GitHub Security Advisories, "Improper Neutralization of Special Elements in Data Query Logic vulnerability in Apache Camel Neo4J component" (GHSA-q86m-qjpm-vqcw). https://github.com/advisories/GHSA-q86m-qjpm-vqcw
• GitHub Security Advisories, "Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Vertx Websocket component" (GHSA-hgg5-gp4c-gpcg). https://github.com/advisories/GHSA-hgg5-gp4c-gpcg
• GitHub Security Advisories, "Improper Input Validation vulnerability in Apache Camel" (GHSA-5g68-f6xg-vf2r). https://github.com/advisories/GHSA-5g68-f6xg-vf2r

8. Adverse Trace position

Adverse Trace assesses CVE-2025-27636 as CVSS 5.6 MEDIUM, CWE-178, not in CISA KEV, with an EPSS of 97% per the verified reference data. The medium base score reflects the precondition of producer access to a consumed broker or topic, and we are not re-rating it upward. The operational risk to a client is set by the route topology, not by the score: where a Camel route bridges a JMS, SJMS, CoAP or Google Pub/Sub consumer into camel-exec or camel-file, the outcome is code execution and the effective severity is high regardless of the base score. The 97% EPSS figure means scanning and exploitation attempts against this class of flaw are widespread, so an exposed route should be treated as likely to be probed. No actor is attributed and no exploitation has been observed in the source material; the sources are the vendor's own advisories and no independent telemetry is present, so any attribution claim would be unsupported. We will track the related Camel header-filtering advisories as one family, since the same filtering gap has now been fixed component by component, and we will issue a follow-up if a further instance or any in-the-wild exploitation reporting appears. Clients running Camel in an affected range should complete the P1 inventory and route-level removeHeaders control today and confirm to their account contact which routes bridge an untrusted consumer into a header-driven producer.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.