CVE-2026-49099: Apache Camel Salesforce Header Injection Vulnerability

Technical summary

The vulnerability arises from improper header namespace validation in Apache Camel's camel-salesforce producer. The component reads operation parameters (SOQL queries, SOSL searches, SObject names/IDs, Apex URLs, methods, and query parameters) from Exchange message headers with priority over endpoint configuration. Control-header constants in SalesforceEndpointConfig use plain names (sObjectQuery, sObjectSearch, sObjectName, sObjectId, apexUrl, apexMethod, apexQueryParam.*) without the Camel namespace prefix. HttpHeaderFilterStrategy only strips headers in the Camel/camel namespace at HTTP boundaries, allowing these unprefixed headers to pass unfiltered from inbound HTTP requests into the Exchange. Routes bridging HTTP consumers (platform-http, etc.) to salesforce: producers are vulnerable. An attacker can inject arbitrary SOQL/SOSL, redirect CRUD operations, or manipulate Apex REST calls with injected parameters, all executing under the connected Salesforce user's permissions. Affected versions: 4.0.0–4.14.7, 4.15.0–4.18.2, 4.19.0–4.20.x.

Business impact

Organizations using Apache Camel to integrate web applications or APIs with Salesforce face data confidentiality and integrity risks. Attackers can read sensitive Salesforce records (contacts, accounts, opportunities, custom objects) accessible to the integration user without authentication. They can also modify or delete data, create records, or trigger Apex operations if the connected user has broad permissions. Integration users typically have elevated privileges for operational needs, amplifying the blast radius. The attack requires no credentials and can be executed opportunistically by any HTTP client. Reputational and compliance consequences may follow unauthorized data access or modification. Affected deployments should be treated as high-priority for patching.

Affected systems

Apache Camel versions 4.0.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.x are affected. The three supported LTS/update streams have patches: 4.14.8, 4.18.3, and 4.21.0 respectively. Systems at risk are those deploying camel-salesforce routes that bridge HTTP entry points (REST APIs, webhooks, platform-http) directly or indirectly to Salesforce producers. Routes that explicitly set Salesforce parameters via endpoint configuration alone are not exploitable unless they also pass through an HTTP consumer layer. Deployments with air-gapped or authentication-gated HTTP entry points face lower exposure.

Exploitability

Exploitability is straightforward. An attacker simply crafts HTTP requests to a vulnerable route with headers such as sObjectQuery, sObjectSearch, sObjectName, or apexUrl set to malicious values. No authentication is required if the HTTP consumer is unauthenticated. No user interaction is needed. The attack succeeds instantly because the vulnerability is a design flaw in header parsing, not a race condition or timing dependency. Network accessibility to the HTTP endpoint is the only prerequisite. Public-facing integrations or those on internal networks accessible to untrusted users are at significant risk. The CVSS score of 5.3 reflects low integrity impact (read-only in the base case) and network-accessible entry, though real-world impact can be higher if Salesforce permissions allow writes or sensitive data exists.

Remediation

Immediately upgrade to Apache Camel 4.21.0 (latest), 4.18.3 (4.18.x stream), or 4.14.8 (4.14.x LTS stream). After upgrading, audit any routes that previously used raw header names (sObjectQuery, sObjectSearch, sObjectName, etc.) and migrate them to the corrected CamelSalesforce*-prefixed equivalents (CamelSalesforceSObjectQuery, CamelSalesforceApexUrl, etc.). Endpoint configuration syntax remains unchanged. Organizations unable to patch immediately should implement mitigation: add removeHeaders('sObject*') and removeHeaders('apex*') at the start of vulnerable routes to strip malicious headers before they reach the salesforce: producer, and ensure Salesforce parameters are set from trusted sources only (environment variables, configuration files, authenticated backends). Consider deploying a WAF or API gateway to filter suspicious header patterns. Review Salesforce integration user permissions and apply least-privilege access.

Patch guidance

Patch availability is confirmed for three release streams. For production environments, prioritize upgrading to 4.21.0 if you are on the mainline release track. If you are locked to an LTS or update-stream version, upgrade to 4.14.8 (for 4.14.x) or 4.18.3 (for 4.18.x). Test patches in a non-production environment first, paying particular attention to any routes that read Salesforce parameters from headers; these may require code changes to use the new CamelSalesforce* prefix. Verify that third-party or custom extensions do not depend on the old header names. Roll out patches during a maintenance window to minimize risk of service interruption during migration.

Detection guidance

Monitor HTTP request headers for the presence of sObject*, apex*, or apexQueryParam.* headers in traffic destined for Salesforce producers. Intrusion detection systems can flag requests containing these headers if they are unexpected. Enable audit logging on the Salesforce side to detect unusual SOQL queries, CRUD operations on unexpected objects, or Apex API calls from the integration user. Check Camel route definitions in production for any use of sObject* / apex* header names (as opposed to CamelSalesforce*) in conjunction with HTTP consumers; these are indicators of vulnerable routing patterns. Review Salesforce API audit trails and Camel application logs for anomalous query patterns or permission scope mismatches. Query for any Apex REST redirects or method overrides in audit logs that do not match expected integration behavior.

Why prioritize this

While the CVSS score is moderate (5.3), this vulnerability merits urgent attention because it enables unauthorized data access and modification to a critical business system (Salesforce) with minimal effort and no authentication required. The attack surface is potentially broad (any HTTP route to Salesforce), the impact on confidentiality is real, and the fix is available and straightforward. Organizations relying on Camel-Salesforce integrations for customer data, financial records, or operational processes should treat this as a high-priority patch. The lack of KEV status does not diminish the practical risk; proactive patching is essential before the vulnerability becomes weaponized.

Risk score, explained

The CVSS 3.1 score of 5.3 (MEDIUM) reflects a network-accessible attack vector with no prerequisites (PR:N) and no user interaction required (UI:N). Scope is unchanged (S:U), and confidentiality impact is low (C:L) while integrity and availability are not impacted (I:N/A:N) in the base vector. However, real-world risk is context-dependent: organizations with broad Salesforce integration user permissions, sensitive data in target objects, or public-facing HTTP endpoints connecting to Salesforce should treat this as effectively HIGH-risk. The vector captures read-only exploitation in the baseline; write access depends on Salesforce user role permissions. The absence of ransomware or critical infrastructure linkage justifies the MEDIUM rating, but operationally this is a prompt-to-patch vulnerability.

Frequently asked questions