GHSA-jg2m-9×48-3gvj – Critical Header Filter Bypass in Apache Camel (CVE‑2026‑40453)

by

Introduction

The advisory GHSA-jg2m-9×48-3gvj (also cataloged as CVE-2026-40453) identifies an incomplete fix in Apache Camel that can lead to remote code execution (RCE) and arbitrary file writes. The issue stems from case‑variant header handling in five non‑HTTP HeaderFilterStrategy implementations. This article provides an in‑depth technical analysis, remediation guidance, and verification steps for developers, DevSecOps engineers, and security teams.

Vulnerability Overview

Field Value
OSV advisory ID GHSA-jg2m-9×48-3gvj
CVE identifier(s) CVE-2026-40453
Summary Apache Camel has an incomplete fix for CVE-2025-27636, leaving five header‑filter strategies vulnerable to case‑variant header injection.
Affected package names org.apache.camel:camel-coap, org.apache.camel:camel-google-pubsub, org.apache.camel:camel-jms, org.apache.camel:camel-sjms
Package ecosystem Maven
Published date 2026-04-27T09:34:39Z
Modified date 2026-10-05T18:38:49Z
Severity CRITICAL (as reported by NVD)
CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE identifiers CWE-178
Recorded fixed versions camel‑coap 4.20.0, camel‑google‑pubsub 4.20.0, camel‑jms 4.20.0, camel‑sjms 4.20.0 (plus LTS fixes 4.14.6 and 4.18.2)

Detailed Vulnerability Explanation

Apache Camel routes often rely on headers to drive component behavior. For security, Camel provides HeaderFilterStrategy implementations that reject internal headers prefixed with Camel or camel. In response to a prior issue (CVE‑2025‑27636), the core HTTP strategy was patched by invoking setLowerCase(true), which normalises header names before applying the prefix filter.

Unfortunately, five other strategies—JmsHeaderFilterStrategy, ClassicJmsHeaderFilterStrategy, SjmsHeaderFilterStrategy, CoAPHeaderFilterStrategy, and GooglePubsubHeaderFilterStrategy—were left unmodified. These strategies continue to perform a case‑sensitive String.startsWith("Camel") check while the underlying Camel Exchange stores headers in a case‑insensitive map. An attacker who can publish messages via JMS (or an equivalent protocol) to a broker consumed by a vulnerable Camel route can therefore inject headers such as CAmelExecCommandExecutable. Downstream components (e.g., camel‑exec, camel‑file) retrieve the canonical header name, interpret it as a trusted internal command, and may execute arbitrary OS commands or write files.

Technical Analysis

The root cause is a mismatch between the case handling of the header storage layer and the filtering logic of the affected strategies. The steps an attacker would follow are:

  1. Gain producer access to a JMS broker (or CoAP/Google Pub/Sub broker) that is the source of a Camel route.
  2. Publish a message whose header key uses a mixed‑case variant of the protected Camel prefix (e.g., CAmelExecCommandExecutable).
  3. The non‑HTTP strategy receives the raw header name, performs a case‑sensitive startsWith check, which returns false, allowing the header to pass through.
  4. When the message reaches downstream components, the Camel Exchange returns the header using the canonical case (CamelExecCommandExecutable), which matches the component’s internal whitelist and triggers execution.

Because the exploit requires only message production privileges (not full system compromise), the vulnerability is especially concerning for multi‑tenant environments or any scenario where external services can push data into a Camel‑based integration pipeline.

Affected Software and Versions

The advisory lists four Maven artifacts. Each artifact is vulnerable across three distinct version streams reflecting the Apache Camel release cadence:

Package Ecosystem Introduced Fixed
org.apache.camel:camel-coap Maven 3.0.0 4.14.6
org.apache.camel:camel-coap Maven 4.15.0 4.18.2
org.apache.camel:camel-coap Maven 4.19.0 4.20.0
org.apache.camel:camel-google-pubsub Maven 3.0.0 4.14.6
org.apache.camel:camel-google-pubsub Maven 4.15.0 4.18.2
org.apache.camel:camel-google-pubsub Maven 4.19.0 4.20.0
org.apache.camel:camel-jms Maven 3.0.0 4.14.6
org.apache.camel:camel-jms Maven 4.15.0 4.18.2
org.apache.camel:camel-jms Maven 4.19.0 4.20.0
org.apache.camel:camel-sjms Maven 3.0.0 4.14.6
org.apache.camel:camel-sjms Maven 4.15.0 4.18.2
org.apache.camel:camel-sjms Maven 4.19.0 4.20.0

Each range is independent; there is no overlap across streams. The advisory recommends upgrading to the earliest fixed version within the stream you are using (4.14.6 for the 4.14.x LTS line, 4.18.2 for the 4.18.x line, or 4.20.0 for the main line).

Severity and Risk Interpretation

The vulnerability is classified as CRITICAL by the NVD and carries a CVSS v3.1 base vector of AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. The vector indicates:

  • Attack Vector (AV): Network – the attacker can exploit the flaw remotely over the network.
  • Attack Complexity (AC): Low – no special conditions beyond the ability to send a message.
  • Privileges Required (PR): Low – only producer rights on the messaging system.
  • User Interaction (UI): None – exploitation does not require any user action.
  • Scope (S): Changed – the vulnerability impacts components beyond the one where the injection occurs.
  • Confidentiality, Integrity, Availability (C/I/A): High – successful exploitation can lead to full system compromise.

No public proof‑of‑concept, exploitation reports, or active attacks are listed in the OSV record, but the severity rating reflects the worst‑case impact.

Who Should Investigate

  • Application developers who ship Camel‑based integration services.
  • DevSecOps engineers responsible for CI/CD pipelines that build or publish Maven artifacts.
  • Security operations teams managing enterprise SBOM inventories.
  • Platform operations that run Camel routes in containers, Kubernetes pods, or on‑premise servers.

Any team that consumes or produces JMS, CoAP, or Google Pub/Sub messages through Camel should prioritize this advisory.

How to Check Whether an Application Is Affected

Follow the steps appropriate for a Maven‑based Java ecosystem:

  1. Identify direct dependencies in pom.xml or build.gradle. Look for the four affected artifacts.
  2. Generate a dependency tree to expose transitive dependencies: 
    mvn dependency:tree -Dincludes=org.apache.camel:camel-*
  3. Search for the version numbers reported in the advisory. Versions prior to the respective fixed version in the same release stream are vulnerable.
  4. If you use a Bill of Materials (BOM) such as camel-bom, verify the BOM version aligns with a fixed release.
  5. For container images, extract the built JARs or use jdeps to list included Maven coordinates.
  6. Leverage SBOM tools (CycloneDX, SPDX) or commercial SCA solutions to flag the vulnerable coordinates automatically.

Compare discovered versions against the table above, taking care not to assume that a higher major version automatically includes the fix; consult the exact fixed version for the stream you are using.

Remediation and Mitigation

The advisory provides concrete upgrade paths:

  • For the main release line (3.0.0 → 4.20.0), upgrade to 4.20.0 of the affected artifacts.
  • If you are on the 4.14.x LTS stream, upgrade to 4.14.6.
  • If you are on the 4.18.x stream, upgrade to 4.18.2.

Remediation steps:

  1. Update the version in your build file (e.g., <version>4.20.0</version>).
  2. Run the full test suite, focusing on integration tests that involve JMS, CoAP, or Pub/Sub routes.
  3. Re‑build Docker images or other deployment artefacts and push to your registry.
  4. If an immediate upgrade is not feasible, consider temporarily disabling routes that accept external JMS/CoAP messages until the fix can be applied.

When no fixed version is available for a custom fork, back‑port the setLowerCase(true) change to the affected strategies and submit a pull request upstream.

Post‑Remediation Verification

After applying the upgrade, confirm the remediation with the following checklist:

  • Run mvn dependency:tree again and verify that no vulnerable version appears.
  • Regenerate your SBOM (CycloneDX or SPDX) and scan it with the same SCA tool to ensure the issue is cleared.
  • Deploy the updated artefact to a staging environment and execute an integration test that attempts to send a case‑variant header. The request should be rejected.
  • Audit CI/CD logs to confirm that the new versions were published and consumed.
  • Document the upgrade in your vulnerability management ticketing system, referencing the OSV ID GHSA-jg2m-9×48-3gvj and the fixed version.

Developer and DevSecOps Recommendations

  • Adopt a “dependency‑as‑code” policy: lock dependency versions in pom.xml and enforce updates via automated pull‑requests (e.g., Renovate, Dependabot).
  • Integrate SBOM generation into your CI pipeline and feed the SBOM into a continuous vulnerability monitoring platform.
  • Enable Maven Enforcer rules to ban vulnerable version ranges.
  • Prefer the latest stable Camel release stream when starting new projects to minimise exposure to legacy fixes.
  • When using JMS, CoAP, or Google Pub/Sub, consider adding an additional header‑validation layer (e.g., a custom Processor) that normalises case before handing messages to Camel components.

Explore on cve.sbom.guru

Authoritative References

Key Takeaways

  • GHSA-jg2m-9×48-3gvj (CVE‑2026‑40453) is a critical RCE vulnerability affecting four Apache Camel Maven artifacts.
  • The flaw arises from case‑variant header injection in non‑HTTP HeaderFilterStrategy implementations.
  • All vulnerable versions are listed; the recommended fixes are 4.14.6 (LTS), 4.18.2 (intermediate), or 4.20.0 (latest).
  • Upgrade the affected artifacts, validate the upgrade with SBOM scans and integration tests, and document remediation.

Freshness Note

Vulnerability data can evolve. Readers should verify the latest status and remediation details on the official advisory pages linked above before taking action.

Leave a Comment