CVE-2026-49099: Apache Camel Auth Bypass Vulnerability

CVE-2026-49099 Overview

CVE-2026-49099 is an injection and authorization bypass vulnerability in the Apache Camel Salesforce component. The camel-salesforce producer resolves operation parameters from Exchange message headers, preferring header values over endpoint configuration. Control-header constants in SalesforceEndpointConfig use plain names such as sObjectQuery, sObjectSearch, sObjectName, sObjectId, apexUrl, and apexMethod without the Camel prefix. HttpHeaderFilterStrategy blocks only headers in the Camel namespace, so untrusted HTTP inputs can override these values. Attackers reaching an unauthenticated bridging consumer can supply arbitrary SOQL, SOSL, and Apex parameters that execute with the connected Salesforce integration user's permissions.

Critical Impact
Unauthenticated attackers can read Salesforce data, redirect Apex REST calls to destructive methods, and execute CRUD operations under the integration user's broad privileges.

Affected Products

Apache Camel 4.0.0 through 4.14.7
Apache Camel 4.15.0 through 4.18.2
Apache Camel 4.19.0 through 4.20.x

Discovery Timeline

2026-07-06 - CVE-2026-49099 published to NVD
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-49099

Vulnerability Analysis

The flaw resides in how AbstractSalesforceProcessor.getParameter() resolves operation parameters. The method reads Exchange message headers first and falls back to endpoint configuration only when a header is absent. This design lets any upstream component override endpoint-configured Salesforce operations at runtime.

The injection surface expands because SalesforceEndpointConfig declares control headers using non-prefixed names. Constants such as SOBJECT_QUERY = sObjectQuery, SOBJECT_SEARCH = sObjectSearch, SOBJECT_NAME = sObjectName, APEX_URL = apexUrl, APEX_METHOD = apexMethod, and the apexQueryParam. prefix all sit outside the Camel header namespace.

The issue is classified under [CWE-74] Improper Neutralization of Special Elements in Output Used by a Downstream Component. Affected Salesforce operations include SOQL queries, SOSL searches, target SObject CRUD calls, and Apex REST invocations.

Root Cause

HttpHeaderFilterStrategy filters only headers beginning with the Camel or camel prefix at the HTTP boundary. Because the Salesforce control headers do not carry that prefix, inbound HTTP requests pass them directly into the Exchange. The producer then treats attacker-supplied headers as authoritative operation parameters.

Attack Vector

An attacker targets a route that bridges an HTTP consumer such as platform-http into a salesforce: producer. The attacker submits an HTTP request that includes headers like sObjectQuery, sObjectName, apexUrl, or apexMethod. The Camel route forwards these headers unchanged, and the Salesforce producer executes the attacker-controlled operation. No credentials are required when the bridging consumer is unauthenticated. All resulting operations run under the Salesforce connected integration user, which typically holds broad object and Apex permissions.

See the Apache Camel Security Advisory for the vendor's technical description.

Detection Methods for CVE-2026-49099

Indicators of Compromise

Inbound HTTP requests containing headers named sObjectQuery, sObjectSearch, sObjectName, sObjectId, apexUrl, apexMethod, or any header prefixed with apexQueryParam.
Unexpected SOQL or SOSL queries in Salesforce API audit logs originating from the integration user
Apex REST calls targeting endpoints or HTTP methods not defined by the application route
Bulk read or delete activity in Salesforce records outside the application's normal access pattern

Detection Strategies

Inspect HTTP access logs at ingress proxies for request headers matching the Salesforce control-header names
Correlate Camel route execution logs with Salesforce API event monitoring to identify parameter values that deviate from endpoint configuration
Alert on Apex REST invocations that use destructive HTTP methods such as DELETE or PATCH when the route configuration specifies read-only operations

Monitoring Recommendations

Enable Salesforce Event Monitoring for API calls attributed to the connected integration user
Log full request header sets on the HTTP consumer bridging into camel-salesforce producers
Baseline SObject query volumes and alert on sudden spikes or access to previously untouched objects

How to Mitigate CVE-2026-49099

Immediate Actions Required

Upgrade Apache Camel to 4.21.0, 4.18.3, or 4.14.8 depending on your release stream
After upgrade, update routes to use the new prefixed header names such as CamelSalesforceSObjectQuery and CamelSalesforceApexUrl
Review Salesforce connected app permissions and reduce the integration user's object and Apex access to the minimum required
Audit Salesforce API logs for the period prior to patching for anomalous SOQL, SOSL, and Apex REST activity

Patch Information

Apache Camel version 4.21.0 fixes the issue. LTS users on the 4.14.x stream should upgrade to 4.14.8, and users on the 4.18.x stream should upgrade to 4.18.3. The endpoint-option spellings remain unchanged, but header-based parameter injection now requires the CamelSalesforce* prefixed names, which HttpHeaderFilterStrategy blocks at the HTTP boundary.

Workarounds

Strip Salesforce control headers from untrusted ingress before the salesforce: producer using removeHeaders('sObject*') and removeHeaders('apex*') at the start of the route
Set query, SObject, and Apex parameters from a trusted source such as route logic or a secured configuration store
Place authentication in front of any platform-http consumer that bridges into a Salesforce producer
Restrict the Salesforce integration user's profile and permission sets to only the objects and Apex classes required by the application

bash

# Example route mitigation - strip attacker-controllable headers before the Salesforce producer
from("platform-http:/integration")
    .removeHeaders("sObject*")
    .removeHeaders("apex*")
    .setHeader("CamelSalesforceSObjectName", constant("Account"))
    .to("salesforce:getSObject");