Back

MEDIUM

Apache Camel Salesforce: Non-Camel-prefixed Exchange header constants bypass the HTTP header filter, allowing an HTTP client to influence internal behaviour

Published Jul 6, 2026

Description

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Salesforce Component.

The camel-salesforce producer resolves its operation parameters - the SOQL query, the SOSL search, the target SObject name and id, the Apex REST URL and method, and the Apex query parameters - from Exchange message headers, reading the header in preference to the value configured on the endpoint (AbstractSalesforceProcessor.getParameter() reads the header first and uses the endpoint configuration only as a fallback). The control-header constants in SalesforceEndpointConfig (for example SOBJECT_QUERY = sObjectQuery, SOBJECT_SEARCH = sObjectSearch, SOBJECT_NAME = sObjectName, SOBJECT_ID = sObjectId, APEX_URL = apexUrl, APEX_METHOD = apexMethod, and the apexQueryParam. prefix) used plain, non-Camel-prefixed values. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a salesforce: producer, any HTTP client could therefore set these headers and override what the route intended - supplying its own SOQL query or SOSL search to read data from any SObject the connected Salesforce user can access, overriding the target SObject name and id for CRUD operations, or redirecting an Apex REST call to a different endpoint and HTTP method (including destructive methods) with injected query parameters. All such operations run with the full permissions of the Salesforce connected (integration) user, which is typically broad. No credentials are required from the attacker when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.

Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set Salesforce operation parameters via the raw header names must use the CamelSalesforce* names (for example CamelSalesforceSObjectQuery and CamelSalesforceApexUrl) instead of the old sObject* / apex* values; the endpoint-option spelling is unchanged. For deployments that cannot upgrade immediately, strip the Salesforce control headers from any untrusted ingress before the salesforce: producer (for example removeHeaders('sObject*') and removeHeaders('apex*') at the start of the route), and set the query, SObject and Apex parameters from a trusted source.

Affected products

Remediation

Red Hat statement

This Moderate vulnerability in Apache Camel Salesforce component allows an unauthenticated HTTP client to bypass header filtering in routes that bridge an HTTP consumer to a Salesforce producer. An attacker can inject arbitrary Salesforce operation parameters, potentially leading to unauthorized data access, modification, or redirection of Apex REST calls with the full permissions of the connected Salesforce user. This risk is present when the affected component is deployed in a vulnerable bridging configuration.

Red Hat mitigation

To mitigate this issue, configure affected Apache Camel routes to strip Salesforce control headers from any untrusted ingress before they reach the `camel-salesforce` producer. This can be achieved by adding `removeHeaders('sObject*')` and `removeHeaders('apex*')` at the beginning of the route. Ensure that Salesforce operation parameters are subsequently set from a trusted source within the route. Redeployment of the affected route or application may be required for the changes to take effect.

References (18)

Change history (0)

No recorded changes yet.

Sources
CVE.org / MITRE
Status PUBLISHED
Assigner apache
Published Jul 6, 2026
Updated Jul 7, 2026
Reserved May 27, 2026
CISA Vulnrichment
Updated Jul 7, 2026
NVD
Status Analyzed
Modified Jul 8, 2026
Red Hat
Severity Moderate
Public date Jul 6, 2026
ENISA EUVD
Assigner apache
Published Jul 6, 2026
Updated Jul 7, 2026
Exploited since n/a
EUVD-2026-41845 GHSA-GCC7-C8MP-34QX