rahulreddykarne/cve-2026-15911-confluent_kafkaVérification du certificat TLS désactivée pour HashiCorp Vault KMS dans confluent-kafka
Sévérité : Élevée, CVSS 3.1 7.4
Vecteur (v3.1) : CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Affecté : confluent-kafka >= 2.8.0, <= 2.14.2
Corrigé dans : 2.15.0
CWE : CWE-295 (Validation de certificat incorrecte)
Composant : confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Signalé par : Rahul Karne
CNA : VulnCheck
Le client HashiCorp Vault KMS dans confluent-kafka code en dur verify=False lors de la construction de son hvac.Client, désactivant la vérification du certificat TLS pour les connexions HTTPS à Vault effectuées via les règles de chiffrement de champ du Schema Registry.
Le code vulnérable se trouve dans :
confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Le client affecté est initialisé comme suit :
self._client = hvac.Client(
url=vault_url,
token=token,
namespace=ns,
verify=False
)
Comme verify=False est inconditionnel, le client accepte les certificats TLS non fiables, y compris les certificats auto-signés ou contrôlés par un attaquant.
Un attaquant positionné sur le réseau, capable d'intercepter ou de rediriger le trafic Vault de l'application, peut usurper l'identité du serveur Vault, capturer les identifiants d'authentification Vault et renvoyer des réponses Vault/KMS falsifiées.
L'intégration HCVault affectée expose la configuration pour les jetons Vault, les espaces de noms et les identifiants AppRole, mais les versions affectées ne fournissent aucune configuration prise en charge de bundle CA ni mécanisme équivalent pour restaurer la vérification du certificat.
Un attaquant disposant d'une position d'homme du milieu sur le réseau entre l'application et HashiCorp Vault peut :
X-Vault-Tokenrole_idsecret_idCela peut compromettre la confidentialité et l'intégrité des données protégées par le flux de travail KMS soutenu par Vault.
confluent-kafka est le client Python officiel de Confluent pour Apache Kafka.
La vulnérabilité affecte spécifiquement les déploiements utilisant :
Règles de chiffrement du Schema Registry
↓
Intégration HCVault KMS
↓
URI de clé hcvault://
La population affectée est donc plus restreinte que l'ensemble des utilisateurs de confluent-kafka.
Cependant, la fonctionnalité affectée est sensible en matière de sécurité car ces déploiements reposent sur HashiCorp Vault pour la gestion des clés cryptographiques et le chiffrement au niveau des champs.
HcVaultKmsClient.__init__() analyse une URI de clé hcvault://, détermine l'URL de base de Vault et crée un hvac.Client.
Dans les versions affectées, y compris 2.14.2, le code pertinent est :
self._client = hvac.Client(
url=vault_url,
token=token,
namespace=ns,
verify=False
)
if role_id and secret_id and self._client is not None:
self._client.auth.approle.login(
role_id=role_id,
secret_id=secret_id
)
La bibliothèque hvac s'appuie en fin de compte sur la pile TLS de requests de Python.
Définir :
verify=False
indique au client de ne pas valider le certificat TLS du serveur distant.
Par conséquent, les certificats qui seraient normalement rejetés peuvent être acceptés, y compris les certificats qui sont :
Cela affecte les deux chemins d'authentification pris en charge.
Lorsque l'authentification par jeton est utilisée, le jeton Vault est envoyé via l'en-tête HTTP :
X-Vault-Token
Si un attaquant réussit à usurper le point de terminaison Vault, le serveur contrôlé par l'attaquant peut recevoir ce jeton.
Lorsque l'authentification AppRole est utilisée, le client envoie :
role_id
secret_id
à :
/v1/auth/approle/login
Un MITM réussi peut donc capturer les deux identifiants AppRole.
Le pilote HCVault affecté lit la configuration, notamment :
token.id
namespace
approle.role.id
approle.secret.id
ainsi que les variables d'environnement VAULT_* pertinentes.
Cependant, les versions affectées n'exposent pas de configuration permettant aux opérateurs de :
Par conséquent, les applications utilisant l'intégration affectée ne peuvent pas restaurer la vérification TLS via la configuration normale du paquet.
Le paquet désactive explicitement la vérification du certificat serveur TLS au lieu de s'appuyer sur la valeur par défaut sécurisée.
La construction vulnérable est effectivement :
hvac.Client(..., verify=False)
plutôt que :
hvac.Client(..., verify=True)
ou simplement :
hvac.Client(...)
où la vérification est activée par défaut.
La désactivation de la vérification du certificat supprime l'authentification du serveur de la connexion TLS.
Bien que la connexion reste chiffrée, le client n'a aucun mécanisme fiable pour déterminer s'il communique avec le serveur Vault légitime.
Cela crée la condition nécessaire à une attaque de type homme du milieu sur le réseau.
Une exploitation réussie nécessite :
L'application utilise une version affectée de confluent-kafka :
2.8.0 à 2.14.2.L'application utilise les règles de chiffrement du Schema Registry avec l'intégration HCVault KMS.
La clé KMS configurée utilise le schéma :
hcvault://
Les exemples possibles incluent :
Aucun privilège au niveau de l'application ni interaction de la victime n'est requis une fois la position MITM nécessaire obtenue.
poc_confluent_kafka.py démontre le problème contre une wheel confluent-kafka 2.14.2 décompressée localement.
Le PoC utilise :
HcVaultKmsClient.La preuve de concept contient cinq modes.