GHSA-gcc7-c8mp-34qx
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
AV:N and PR:N for unauthenticated HTTP boundary; S:C because exploitation crosses into Salesforce as a distinct system; A:L for potential destructive Apex calls without classic service availability impact.
Primary rating from Vendor (CNA).
CVSS VectorVendor
Lifecycle Timeline
3Blast Radius
ecosystem impact- 16 maven packages depend on org.apache.camel:camel-salesforce (10 direct, 6 indirect)
Ecosystem-wide dependent count for version 4.0.0.
Description PRE-NVD
Articles & Coverage 4
AnalysisAI
Header injection in Apache Camel's camel-salesforce component allows any HTTP client to override SOQL queries, SOSL searches, Salesforce object targets, and Apex REST endpoints by setting non-Camel-prefixed Exchange headers that the framework's HttpHeaderFilterStrategy fails to block. Routes that bridge an HTTP consumer (such as platform-http) into a salesforce: producer are the attack surface; when that HTTP consumer is unauthenticated, exploitation requires zero attacker credentials. All injected operations execute under the configured Salesforce integration user's permissions, which are typically broad, enabling unauthorized data exfiltration or destructive CRUD and Apex calls across the organization's Salesforce instance. No public exploit has been identified and the vulnerability is not listed in the CISA KEV catalog at time of analysis.
Technical ContextAI
Apache Camel (org.apache.camel:camel-salesforce) is a widely used integration component that routes messages between Camel exchanges and Salesforce via SOQL queries, SOSL searches, SObject CRUD operations, and Apex REST API calls. Camel's HttpHeaderFilterStrategy is designed to prevent inbound HTTP headers from polluting the Exchange's internal control plane by blocking any header whose name begins with the 'Camel' or 'camel' prefix. The flaw arises because the control-header constants in SalesforceEndpointConfig - SOBJECT_QUERY='sObjectQuery', SOBJECT_SEARCH='sObjectSearch', SOBJECT_NAME='sObjectName', SOBJECT_ID='sObjectId', APEX_URL='apexUrl', APEX_METHOD='apexMethod', and the 'apexQueryParam.' prefix - were defined without the Camel prefix, placing them outside the filter's protected namespace. AbstractSalesforceProcessor.getParameter() reads Exchange headers before falling back to endpoint configuration, so any inbound HTTP header matching these names silently overrides the developer's intended route parameters. The root cause is an authorization bypass through user-controlled keys (the header namespace convention that protects all other Camel control headers was never applied to Salesforce-specific constants), compounded by an injection weakness that allows arbitrary SOQL/SOSL query strings and Apex URLs to be supplied by an external HTTP client.
RemediationAI
Upgrade org.apache.camel:camel-salesforce to version 4.14.8 (for the 4.14.x LTS stream), 4.18.3 (for the 4.18.x stream), or 4.21.0 (latest), as confirmed by the Apache Camel security advisory at https://camel.apache.org/security/CVE-2026-49099.html. The fix renames 39 producer-read Exchange header constants to the CamelSalesforce* naming convention (e.g., sObjectQuery becomes CamelSalesforceSObjectQuery, apexUrl becomes CamelSalesforceApexUrl, apexQueryParam.* becomes CamelSalesforceApexQueryParam.*), bringing them under the HttpHeaderFilterStrategy's blocking namespace. After upgrading, any route logic that programmatically sets these headers using the old names must be updated to the new CamelSalesforce-prefixed names; endpoint-option configuration spelling is unchanged. For deployments that cannot upgrade immediately, add removeHeaders('sObject*') and removeHeaders('apex*') steps at the very start of any route containing an HTTP consumer feeding into a salesforce: producer to strip attacker-controlled headers before they reach the Salesforce component; note that this workaround strips all such headers, so any legitimate route logic that sets operation parameters via these header names must be refactored to use trusted internal sources (e.g., set headers explicitly from a trusted bean or constant after the strip). The fix commits are publicly available on GitHub (PR #23887, commits 3445c57e, 578eb2a0, 48880af9) for teams that need to apply patches to custom builds.
Bypass/Injection vulnerability in Apache Camel components under particular conditions.10.0 through <= 4.10.1, from 4.8.0
The XSLT component in Apache Camel before 2.11.4 and 2.12.x before 2.12.3 allows remote attackers to read arbitrary file
Apache Camel's Jackson and JacksonXML unmarshalling operation are vulnerable to Remote Code Execution attacks. Rated cri
The XSLT component in Apache Camel 2.11.x before 2.11.4, 2.12.x before 2.12.3, and possibly earlier versions allows remo
Cross-realm token acceptance bypass in Apache Camel Keycloak security policy. The KeycloakSecurityPolicy fails to proper
Deserialization of Untrusted Data vulnerability in Apache Camel LevelDB component. The Camel-LevelDB DefaultLevelDBSeria
Unsafe Java deserialization in the Apache Camel camel-mina component (versions 3.0.0 through 4.14.5, 4.15.0 through 4.18
Apache Camel's File is vulnerable to directory traversal. Rated high severity (CVSS 7.5), this vulnerability is remotely
The camel-castor component in Apache Camel 2.x before 2.19.4 and 2.20.x before 2.20.1 is vulnerable to Java object de-se
The camel-xstream component in Apache Camel before 2.15.5 and 2.16.x before 2.16.1 allow remote attackers to execute arb
The camel-hessian component in Apache Camel 2.x before 2.19.4 and 2.20.x before 2.20.1 is vulnerable to Java object de-s
Apache Camel before 2.9.7, 2.10.0 before 2.10.7, 2.11.0 before 2.11.2, and 2.12.0 allows remote attackers to execute arb
Same technique Authentication Bypass
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-41845