camel-salesforce CVE-2026-49099

Exploitation requires two specific architectural conditions: (1) a Camel route must be configured that bridges an HTTP consumer component (platform-http, servlet, jetty, or any other HTTP-facing Camel consumer) directly into a salesforce: producer, and (2) the attacker must be able to send HTTP requests to that consumer - either because the consumer is intentionally unauthenticated or because the attacker holds any valid credential for it. The Apache advisory explicitly states that no attacker credentials are required when the bridging consumer is unauthenticated, which is a common pattern for internal integration endpoints and public-facing CRM bridges. Camel deployments that source Salesforce routes exclusively from non-HTTP consumers (JMS queues, Kafka topics, timers, file watchers, or authenticated internal APIs) are not affected by this vulnerability, even if they run the same affected camel-salesforce version. Additionally, the scope of unauthorized Salesforce operations is bounded by the permissions of the configured Salesforce connected (integration) user - the attacker cannot access SObjects or Apex endpoints beyond what that account is authorized to reach, though integration users are described as typically having broad organizational access.

No CVSS vector or EPSS score was provided in the input data, requiring independent assessment. Apache rates the severity as 'moderate,' which appears to reflect the architectural specificity of the vulnerable pattern - only routes that explicitly bridge an HTTP consumer into a salesforce: producer are affected - rather than the per-exploitation impact, which is high. When conditions are met and the HTTP consumer is unauthenticated, the attack is fully unauthenticated, low-complexity, and network-accessible, with confidentiality and integrity impact bounded only by the integration user's Salesforce permission set (described as typically broad). The effective risk profile is therefore situation-dependent: organizations running public-facing or internally-accessible Camel HTTP-to-Salesforce bridges face a serious exposure, while those sourcing Salesforce routes exclusively from trusted internal triggers (queues, timers, internal APIs with authentication) are not affected by this specific vector. KEV status is not confirmed - this CVE does not appear in the CISA KEV catalog at time of analysis. No public exploit code has been identified. The combination of no active exploitation evidence and a conditional deployment requirement supports Apache's moderate classification at portfolio level, but defenders operating HTTP-to-Salesforce bridge routes should treat this as high-priority.

An attacker targeting an organization with a public-facing or internally-accessible Apache Camel integration route that accepts HTTP requests and proxies them to Salesforce crafts an HTTP request containing a custom 'sObjectQuery' header with an arbitrary SOQL statement such as 'SELECT Id, Name, AnnualRevenue FROM Account'. The header passes through HttpHeaderFilterStrategy unchecked because its name lacks the Camel prefix, AbstractSalesforceProcessor.getParameter() reads it in preference to the route's configured query, and Salesforce executes the injected SOQL under the integration user's credentials, returning account records to the attacker. The attacker can escalate further by injecting an 'apexUrl' header pointing to a destructive Apex REST endpoint combined with an 'apexMethod: DELETE' header, redirecting the Camel route to perform unauthorized destructive operations. No public exploit code has been identified at time of analysis, but the technique requires only knowledge of Camel Exchange header names and standard HTTP tooling.