CVE-2026-49099 (GCVE-0-2026-49099)
Vulnerability from cvelistv5 – Published: 2026-07-06 08:11 – Updated: 2026-07-06 09:25
VLAI
Title
Apache Camel Salesforce: Non-Camel-prefixed Exchange header constants bypass the HTTP header filter, allowing an HTTP client to influence internal behaviour
Summary
Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Salesforce Component.
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.
This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
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.
Severity
No CVSS data available.
CWE
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://camel.apache.org/security/CVE-2026-49099.html | vendor-advisory |
| http://www.openwall.com/lists/oss-security/2026/0… |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Camel Salesforce |
Affected:
4.0.0 , < 4.14.8
(semver)
Affected: 4.15.0 , < 4.18.3 (semver) Affected: 4.19.0 , < 4.21.0 (semver) |
Credits
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2026-07-06T09:25:43.240Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/07/05/24"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.camel:camel-salesforce",
"product": "Apache Camel Salesforce",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.14.8",
"status": "affected",
"version": "4.0.0",
"versionType": "semver"
},
{
"lessThan": "4.18.3",
"status": "affected",
"version": "4.15.0",
"versionType": "semver"
},
{
"lessThan": "4.21.0",
"status": "affected",
"version": "4.19.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Yu Bao from PayPal"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Neutralization of Special Elements in Output Used by a Downstream Component (\u0027Injection\u0027), Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Salesforce Component.\u003c/p\u003eThe 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.\u003cbr\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\u003c/p\u003e\u003cp\u003eUsers 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(\u0027sObject*\u0027) and removeHeaders(\u0027apex*\u0027) at the start of the route), and set the query, SObject and Apex parameters from a trusted source.\u003c/p\u003e"
}
],
"value": "Improper Neutralization of Special Elements in Output Used by a Downstream Component (\u0027Injection\u0027), Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Salesforce Component.\n\nThe 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.\nThis issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\n\nUsers 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(\u0027sObject*\u0027) and removeHeaders(\u0027apex*\u0027) at the start of the route), and set the query, SObject and Apex parameters from a trusted source."
}
],
"metrics": [
{
"other": {
"content": {
"text": "moderate"
},
"type": "Textual description of severity"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-74",
"description": "CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component (\u0027Injection\u0027)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-639",
"description": "CWE-639 Authorization Bypass Through User-Controlled Key",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-06T08:11:30.540Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-49099.html"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel Salesforce: Non-Camel-prefixed Exchange header constants bypass the HTTP header filter, allowing an HTTP client to influence internal behaviour",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-49099",
"datePublished": "2026-07-06T08:11:30.540Z",
"dateReserved": "2026-05-27T11:46:24.688Z",
"dateUpdated": "2026-07-06T09:25:43.240Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-49099",
"date": "2026-07-06",
"epss": "0.00197",
"percentile": "0.09626"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2026-49099\",\"sourceIdentifier\":\"security@apache.org\",\"published\":\"2026-07-06T09:16:38.487\",\"lastModified\":\"2026-07-06T18:15:33.843\",\"vulnStatus\":\"Undergoing Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"Improper Neutralization of Special Elements in Output Used by a Downstream Component (\u0027Injection\u0027), Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Salesforce Component.\\n\\nThe 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.\\nThis issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\\n\\nUsers 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(\u0027sObject*\u0027) and removeHeaders(\u0027apex*\u0027) at the start of the route), and set the query, SObject and Apex parameters from a trusted source.\"},{\"lang\":\"es\",\"value\":\"Neutralizaci\u00f3n incorrecta de elementos especiales en la salida utilizada por un componente posterior (inyecci\u00f3n), vulnerabilidad que permite eludir la autorizaci\u00f3n mediante una clave controlada por el usuario en el componente Apache Camel para Salesforce. El productor camel-salesforce resuelve sus par\u00e1metros de funcionamiento \u2014la consulta SOQL, la b\u00fasqueda SOSL, el nombre y el identificador del SObject de destino, la URL y el m\u00e9todo REST de Apex, y los par\u00e1metros de consulta de Apex\u2014 a partir de los encabezados de los mensajes de Exchange, dando prioridad a la lectura del encabezado frente al valor configurado en el punto final (AbstractSalesforceProcessor.getParameter() lee primero el encabezado y utiliza la configuraci\u00f3n del punto final solo como alternativa). Las constantes de los encabezados de control en SalesforceEndpointConfig (por ejemplo, SOBJECT_QUERY = sObjectQuery, SOBJECT_SEARCH = sObjectSearch, SOBJECT_NAME = sObjectName, SOBJECT_ID = sObjectId, APEX_URL = apexUrl, APEX_METHOD = apexMethod y el prefijo apexQueryParam. prefijo) utilizaban valores simples, sin prefijo Camel. Dado que estos nombres no comienzan con el prefijo Camel / camel, HttpHeaderFilterStrategy \u2014que bloquea \u00fanicamente el espacio de nombres de encabezados Camel en el l\u00edmite HTTP\u2014 permit\u00eda que pasaran directamente desde una solicitud HTTP entrante al Exchange. En una ruta que conecta a un consumidor HTTP (por ejemplo, platform-http) con un salesforce: cualquier cliente HTTP podr\u00eda, por lo tanto, establecer estos encabezados y anular lo que la ruta pretend\u00eda: proporcionar su propia consulta SOQL o b\u00fasqueda SOSL para leer datos de cualquier SObject al que pueda acceder el usuario de Salesforce conectado, anular el nombre y el ID del SObject de destino para operaciones CRUD, o redirigir una llamada REST de Apex a un punto final y un m\u00e9todo HTTP diferentes (incluidos m\u00e9todos destructivos) con par\u00e1metros de consulta inyectados. Todas estas operaciones se ejecutan con todos los permisos del usuario conectado a Salesforce (de integraci\u00f3n), que suelen ser amplios. El atacante no necesita credenciales cuando el consumidor puente no est\u00e1 autenticado. Este problema afecta a Apache Camel: desde la versi\u00f3n 4.0.0 hasta la 4.14.8, desde la 4.15.0 hasta la 4.18.3 y desde la 4.19.0 hasta la 4.21.0. Se recomienda a los usuarios que actualicen a la versi\u00f3n 4.21.0, que corrige el problema. Si los usuarios utilizan las versiones LTS de la rama 4.14.x, se les sugiere que actualicen a la 4.14.8. Si los usuarios utilizan las versiones de la rama 4.18.x, se les sugiere que actualicen a la 4.18.3. Tras la actualizaci\u00f3n, las rutas que configuren los par\u00e1metros de operaci\u00f3n de Salesforce mediante los nombres de encabezado sin formato deben utilizar los nombres CamelSalesforce* (por ejemplo, CamelSalesforceSObjectQuery y CamelSalesforceApexUrl) en lugar de los antiguos valores sObject* / apex*; la ortograf\u00eda de las opciones de punto final no ha cambiado. En el caso de las implementaciones que no puedan actualizarse de inmediato, elimine los encabezados de control de Salesforce de cualquier entrada no fiable antes del productor salesforce: (por ejemplo, removeHeaders(\u201csObject*\u201d) y removeHeaders(\u201capex*\u201d) al inicio de la ruta) y configure los par\u00e1metros de consulta, SObject y Apex a partir de una fuente fiable.\"}],\"affected\":[{\"source\":\"security@apache.org\",\"affectedData\":[{\"vendor\":\"Apache Software Foundation\",\"product\":\"Apache Camel Salesforce\",\"defaultStatus\":\"unaffected\",\"collectionURL\":\"https://repo.maven.apache.org/maven2\",\"packageName\":\"org.apache.camel:camel-salesforce\",\"versions\":[{\"version\":\"4.0.0\",\"lessThan\":\"4.14.8\",\"versionType\":\"semver\",\"status\":\"affected\"},{\"version\":\"4.15.0\",\"lessThan\":\"4.18.3\",\"versionType\":\"semver\",\"status\":\"affected\"},{\"version\":\"4.19.0\",\"lessThan\":\"4.21.0\",\"versionType\":\"semver\",\"status\":\"affected\"}]}]}],\"metrics\":{},\"weaknesses\":[{\"source\":\"security@apache.org\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-74\"},{\"lang\":\"en\",\"value\":\"CWE-639\"}]}],\"references\":[{\"url\":\"https://camel.apache.org/security/CVE-2026-49099.html\",\"source\":\"security@apache.org\"},{\"url\":\"http://www.openwall.com/lists/oss-security/2026/07/05/24\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}"
}
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…