CVE-2026-46453
Apache Camel : Camel-Elasticsearch-Rest-Client : les constantes d'en-tête d'échange sans le préfixe Camel contournent le filtrage des en-têtes HTTP entrants, permettant à des clients non fiables de remplacer la requête et l'opération Elasticsearch.
- Publié
- 6 juil. 2026
- Mise à jour
- 6 juil. 2026
- Attribution de CNA
- apache
- Preuve observée
- 7 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
- 44,7 %
- 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é
Validation d'entrée incorrecte, vulnérabilité de contournement d'autorisation via clé contrôlée par l'utilisateur dans le client REST ElasticSearch d'Apache Camel. Le composant camel-elasticsearch-rest-client lit plusieurs en-têtes Exchange pour contrôler son comportement — SEARCH_QUERY (un corps de requête avancé), OPERATION (quelle opération Elasticsearch exécuter), INDEX_NAME, INDEX_SETTINGS et ID. Les valeurs de chaîne de ces constantes d'en-tête, définies dans ElasticSearchRestClientConstant, sont des noms simples sans préfixe ('SEARCH_QUERY', 'OPERATION', 'INDEX_NAME', 'INDEX_SETTINGS', 'ID') plutôt que les noms préfixés par 'Camel' utilisés par tous les autres composants Camel (par exemple CamelSqlQuery, CamelMongoDbCriteria, CamelCqlQuery). Le filtre d'en-têtes HTTP entrants de Camel, HttpHeaderFilterStrategy, bloque uniquement les noms d'en-têtes qui commencent par 'Camel' ou 'camel'. Étant donné que les noms d'en-têtes Elasticsearch ne portent pas ce préfixe, ils traversent le filtre entrant sans modification. Lorsqu'une route Camel expose un point d'entrée HTTP (par exemple platform-http) devant un producteur elasticsearch-rest-client, un client HTTP non fiable peut définir ces en-têtes directement sur sa requête et remplacer la requête et l'opération configurées par l'auteur de la route : lire chaque document de l'index (SEARCH_QUERY avec une requête match_all), supprimer des documents (OPERATION définie sur Delete avec ID), ou exfiltrer des champs sélectionnés. Aucune information d'identification n'est requise et le producteur lit les en-têtes sans condition. Ce problème affecte Apache Camel : de 4.3.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 mettre à niveau vers 4.14.8. Si les utilisateurs sont sur le flux de versions 4.18.x, il leur est suggéré de mettre à niveau vers 4.18.3. Le correctif renomme les valeurs de chaîne constantes des en-têtes Exchange de camel-elasticsearch-rest-client (ID, SEARCH_QUERY, INDEX_SETTINGS, INDEX_NAME, OPERATION) pour qu'elles portent le préfixe Camel (CamelElasticsearchId, CamelElasticsearchSearchQuery, CamelElasticsearchIndexSettings, CamelElasticsearchIndexName, CamelElasticsearchOperation) afin qu'elles soient bloquées par le HttpHeaderFilterStrategy entrant ; les noms de champs Java sont inchangés. Pour les déploiements qui ne peuvent pas mettre à niveau immédiatement, supprimez les en-têtes concernés des messages entrants non fiables avant qu'ils n'atteignent le producteur (par exemple removeHeader('SEARCH_QUERY'), removeHeader('OPERATION'), removeHeader('INDEX_NAME'), removeHeader('INDEX_SETTINGS') et removeHeader('ID') devant le point de terminaison elasticsearch-rest-client), ou appliquez un HeaderFilterStrategy personnalisé qui bloque ces noms.
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.