CVE-2026-49099
Apache Camel Salesforce : les constantes d'en-tête d'échange sans préfixe Camel contournent le filtre d'en-têtes HTTP, permettant à un client HTTP d'influencer le comportement interne
- Publié
- 6 juil. 2026
- Mise à jour
- 7 juil. 2026
- Attribution de CNA
- apache
- Preuve observée
- 6 août 2026
CVSS primaire
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:NFaible · 30 prochains jours
- Percentile
- 43,0 %
- Date du modèle
- 21 sept. 2026
EPSS est une estimation statistique, et non une certitude ou une mesure d'impact. Combinez-le avec CVSS, le statut KEV, l'exposition et votre environnement.
Résumé
Neutralisation inappropriée des éléments spéciaux dans la sortie utilisée par un composant en aval (« Injection »), contournement de l’autorisation par le biais d’une clé contrôlée par l’utilisateur dans le composant Salesforce d’Apache Camel. Le producteur camel-salesforce résout ses paramètres d’opération — la requête SOQL, la recherche SOSL, le nom et l’identifiant de l’objet SObject cible, l’URL et la méthode Apex REST, ainsi que les paramètres de requête Apex — à partir des en-têtes des messages Exchange, en lisant l’en-tête de préférence à la valeur configurée sur le point de terminaison (AbstractSalesforceProcessor.getParameter() lit l’en-tête en premier et n’utilise la configuration du point de terminaison qu’en secours). Les constantes d’en-tête de contrôle dans SalesforceEndpointConfig (par exemple SOBJECT_QUERY = sObjectQuery, SOBJECT_SEARCH = sObjectSearch, SOBJECT_NAME = sObjectName, SOBJECT_ID = sObjectId, APEX_URL = apexUrl, APEX_METHOD = apexMethod, ainsi que le préfixe apexQueryParam.) utilisaient des valeurs simples, sans préfixe Camel. Comme ces noms ne commencent pas par le préfixe Camel / camel, HttpHeaderFilterStrategy — qui ne bloque que l’espace de noms des en-têtes Camel à la frontière HTTP — les laissait passer d’une requête HTTP entrante directement dans l’Exchange. Dans une route qui relie un consommateur HTTP (par exemple platform-http) à un producteur salesforce:, tout client HTTP pouvait donc définir ces en-têtes et remplacer ce que la route avait prévu — en fournissant sa propre requête SOQL ou sa propre recherche SOSL pour lire des données depuis n’importe quel SObject auquel l’utilisateur Salesforce connecté peut accéder, en remplaçant le nom et l’identifiant de l’objet SObject cible pour les opérations CRUD, ou en redirigeant un appel Apex REST vers un autre point de terminaison et une autre méthode HTTP (y compris des méthodes destructives) avec des paramètres de requête injectés. Toutes ces opérations s’exécutent avec les autorisations complètes de l’utilisateur Salesforce connecté (d’intégration), qui sont généralement étendues. Aucun identifiant n’est requis de la part de l’attaquant lorsque le consommateur de pontage n’est pas authentifié. Ce problème affecte Apache Camel : de 4.0.0 avant 4.14.8, de 4.15.0 avant 4.18.3, de 4.19.0 avant 4.21.0. Il est recommandé aux utilisateurs de mettre à niveau vers la version 4.21.0, qui corrige le problème. Si les utilisateurs sont sur le flux de versions LTS 4.14.x, il leur est suggéré de passer à la version 4.14.8. Si les utilisateurs sont sur le flux de versions 4.18.x, il leur est suggéré de passer à la version 4.18.3. Après la mise à niveau, les routes qui définissent les paramètres d’opération Salesforce via les noms d’en-tête bruts doivent utiliser les noms CamelSalesforce* (par exemple CamelSalesforceSObjectQuery et CamelSalesforceApexUrl) au lieu des anciennes valeurs sObject* / apex* ; l’orthographe des options de point de terminaison est inchangée. Pour les déploiements qui ne peuvent pas être mis à niveau immédiatement, supprimez les en-têtes de contrôle Salesforce de toute entrée non fiable avant le producteur salesforce: (par exemple removeHeaders('sObject*') et removeHeaders('apex*') au début de la route), et définissez les paramètres de requête, SObject et Apex à partir d’une source fiable.
Utilisation responsable
Utilisez les informations de vulnérabilité uniquement sur les systèmes que vous possédez ou que vous êtes autorisé à tester. Kitploit renvoie aux métadonnées de la recherche publique et ne stocke pas de code d'exploitation ni de charges utiles malveillantes.