CVE-2025-29891

What it actually does

Apache Camel’s default incoming header filter fails to reliably block Camel-internal headers when requests arrive through HTTP-facing components. In affected versions, attacker-supplied HTTP query parameters, form parameters, payload fields, or headers can be translated into Camel exchange headers. If a route later uses components that honor those headers, such as camel-bean or camel-exec, the attacker may influence route behavior, select unintended bean methods, or manipulate execution-related component options. Exploitability is route-dependent: applications are most exposed when Camel HTTP components are directly reachable from untrusted networks and the route passes attacker-controlled exchanges into vulnerable downstream components.

Why it matters to the business

An exposed Camel application can be made to behave in ways the application developer did not intend, potentially leading to unauthorized business logic execution, data handling errors, service disruption, or, in high-risk route designs, command execution through components that act on Camel headers. Although the CVSS score is moderate and it is not currently listed in CISA KEV or known ransomware use, the EPSS score is high, indicating elevated likelihood of exploitation attempts. Because this issue has been public for over a year, internet-facing Camel services should be treated as a priority for upgrade and review.

How an attack unfolds

An attacker first identifies an HTTP endpoint implemented with Apache Camel components such as camel-servlet, camel-jetty, camel-undertow, camel-platform-http, or camel-netty-http. The attacker then sends crafted HTTP requests containing Camel-specific names as request parameters, form fields, payload attributes, or headers. Due to insufficient filtering, those values become Camel exchange headers. If the target route subsequently invokes a component that trusts those headers, the attacker can influence component behavior, such as choosing a bean method through camel-bean or altering execution parameters through camel-exec. The final impact depends on the route: some applications may only experience unexpected logic flow, while routes using sensitive components may allow more serious consequences such as unauthorized operation execution or operating-system command influence.

How to fix it

Upgrade Apache Camel to a fixed release: use Apache Camel 4.10.2 or later for the 4.10.x LTS line, 4.8.5 or later for the 4.8.x LTS line, and 3.22.4 or later for the 3.x release line. Versions 4.9.0 through before 4.10.2, 4.0.0 through before 4.8.5, and 3.10.0 through before 3.22.4 are affected. If using vendor-packaged Camel, apply the vendor security update rather than only checking upstream version numbers. As defense in depth, restrict direct internet access to Camel HTTP routes, block or strip inbound request parameters and headers beginning with Camel where they are not explicitly required, add allowlist-based header filtering at reverse proxies or API gateways, and review routes that combine HTTP input with camel-bean, camel-exec, scripting, dynamic routing, or other components that act on exchange headers.

How to confirm the fix worked

Confirm all deployed Apache Camel libraries resolve to fixed versions by inspecting dependency manifests, container images, SBOMs, application build files, and runtime classpaths. Validate that no application ships Camel 3.10.0 through 3.22.3, 4.0.0 through 4.8.4, or 4.9.0 through 4.10.1. Exercise representative HTTP routes with benign Camel-prefixed parameters, such as CamelBeanMethodName, and verify they are rejected, stripped, or not present as exchange headers downstream. Review route definitions for HTTP inputs that flow into camel-bean, camel-exec, or dynamic behavior driven by headers. Confirm edge controls or application filters remove unexpected Camel-specific headers and parameters before Camel processing.

Typical attack path

1. Discover an internet-facing HTTP endpoint backed by Apache Camel.
2. Fingerprint likely Camel usage through response behavior, URL patterns, error messages, or exposed application metadata.
3. Send HTTP requests containing Camel-specific parameter or header names such as bean or exec control headers.
4. Rely on Camel HTTP component behavior to translate attacker-supplied request data into Camel exchange headers.
5. Trigger a route that forwards the exchange to a component that honors those headers, such as camel-bean or camel-exec.
6. Manipulate route behavior, invoke unintended methods, alter execution parameters, or cause application errors depending on the route design.
7. Repeat with different header names and values to map reachable behavior and maximize impact.

How to detect it

To determine whether exploitation was attempted or successful, search HTTP access logs, API gateway logs, WAF logs, reverse-proxy logs, load balancer logs, and application logs for request parameter names, form fields, JSON keys, or HTTP headers that begin with Camel and are not part of documented application behavior. Give special attention to CamelBeanMethodName and CamelExecCommand* names, as these are associated with components specifically called out as risky. Inspect Camel application logs for unexpected bean method invocation, route exceptions, exchange header dumps containing attacker-supplied Camel names, or errors from bean, exec, scripting, and dynamic routing components. On hosts or containers running routes that use camel-exec, review process creation telemetry, shell history, audit logs, EDR events, and container runtime logs for unexpected child processes spawned by the Java application. Correlate suspicious requests with application errors, abnormal outbound connections, file writes, or command executions shortly afterward. Because no universal exploit payload exists and impact is route-specific, absence of these indicators does not prove safety; prioritize route review and version validation.

• CamelBeanMethodName
• CamelExecCommandExecutable
• CamelExecCommandArgs
• CamelExecCommandWorkingDir
• CamelExecCommandTimeout
• CamelExecCommandOutFile
• CamelFileName
• CamelFilePath
• CamelHttpUri
• CamelHttpUrl
• CamelHttpQuery
• CamelHttpPath
• CamelHttpMethod
• CamelHttpResponseCode
• CamelHttpRawQuery
• CamelExchangePattern
• CamelSqlQuery
• CamelAwsS3Key
• CamelAwsS3BucketName
• CamelJmsDestinationName
• CamelSmppCommandId

What your security team should do

• Inventory all applications and services using Apache Camel, prioritizing internet-facing HTTP routes.
• Upgrade affected Camel deployments to 4.10.2, 4.8.5, or 3.22.4 according to the release line in use.
• Treat externally reachable Camel HTTP endpoints as high priority despite the moderate CVSS score because the EPSS probability is elevated and the issue has been public for an extended period.
• Review route definitions for HTTP-to-bean, HTTP-to-exec, dynamic recipient, scripting, or other header-driven patterns.
• Add temporary WAF, API gateway, or reverse-proxy rules to block or strip inbound parameter and header names beginning with Camel, especially CamelBeanMethodName and CamelExecCommand* values.
• Search historical HTTP access logs, application logs, and reverse-proxy logs for Camel-specific parameter names and suspicious attempts to influence bean or exec behavior.
• Increase logging around Camel exchange headers for exposed routes until upgrades and route reviews are complete, avoiding logging sensitive values.
• If suspicious activity is found, preserve access logs, application logs, container logs, route definitions, and deployment artifacts for forensic review.