Apache Camel Security Advisory - CVE-2026-49099

Apache Camel security advisory: CVE-2026-49099

Severity

MEDIUM

Summary

Camel-Salesforce: Non-Camel-prefixed Exchange header constants (sObjectQuery, sObjectSearch, apexUrl, ...) bypass the HTTP header filter, allowing an HTTP client to inject SOQL/SOSL queries, override the target SObject, and redirect Apex REST calls using the connected Salesforce user's permissions

Versions affected

From 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.

Versions fixed

4.14.8, 4.18.3 and 4.21.0

Description

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.

Notes

The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-23716 refers to the various commits that resolved the issue, and have more details. The fix was merged on main in https://github.com/apache/camel/pull/23887 (commit 3445c57e147da12ccfdde066c06ec5492d8c262b) and backported to camel-4.18.x (commit 578eb2a0a089c94f507853a737d7c46365f0272e) and camel-4.14.x (commit 48880af9d401e8c03473a14bd652ce012b66157b). The fix renames the 39 producer-read camel-salesforce Exchange header constant values to the CamelSalesforce* convention (for example sObjectQuery to CamelSalesforceSObjectQuery, apexUrl to CamelSalesforceApexUrl, and the apexQueryParam. prefix to CamelSalesforceApexQueryParam.), so they are filtered on the HTTP boundary like every other Camel control header. The Java field names are unchanged, so code referencing the constants keeps working, and the endpoint-option spelling (for example salesforce:query?sObjectQuery=…) is unchanged because it is bound to the @UriParam field name rather than to these constants - only the header name changes. This is a breaking change for routes that set these values as literal-string message headers, which must be updated to the CamelSalesforce* names (see the 4.21 upgrade guide). The issue is classified as CWE-74 (Improper Neutralization of Special Elements) and CWE-639 (Authorization Bypass Through User-Controlled Key). It belongs to the same Camel header-injection family as CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453, CVE-2026-46454 and CVE-2026-47323, and shares the non-Camel-prefixed-header-constant root cause with the camel-cxf operationName, camel-solr SolrParam., camel-kafka kafka.* and camel-jira siblings.

Mitigation

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.

Credit

This issue was discovered by Yu Bao from PayPal

References

PGP signed advisory data: CVE-2026-49099.txt.asc
Mitre CVE Entry: https://www.cve.org/CVERecord?id=CVE-2026-49099