rahulreddykarne/cve-2026-15911-confluent_kafkaDeaktivierte TLS-Zertifikatsüberprüfung für HashiCorp Vault KMS in confluent-kafka
Schweregrad: Hoch, CVSS 3.1 7.4
Vektor (v3.1): CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Betroffen: confluent-kafka >= 2.8.0, <= 2.14.2
Behoben in: 2.15.0
CWE: CWE-295 (Improper Certificate Validation)
Komponente: confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Gemeldet von: Rahul Karne
CNA: VulnCheck
Der HashiCorp Vault KMS-Client in confluent-kafka hardcodiert verify=False bei der Erstellung seines hvac.Client, wodurch die TLS-Zertifikatsüberprüfung für Vault-HTTPS-Verbindungen deaktiviert wird, die über die Schema-Registry-Feldverschlüsselungsregeln hergestellt werden.
Der verwundbare Code befindet sich in:
confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Der betroffene Client wird wie folgt initialisiert:
self._client = hvac.Client(
url=vault_url,
token=token,
namespace=ns,
verify=False
)
Da verify=False bedingungslos gesetzt ist, akzeptiert der Client nicht vertrauenswürdige TLS-Zertifikate, einschließlich selbstsignierter oder von Angreifern kontrollierter Zertifikate.
Ein Angreifer mit einer Netzwerkposition, der in der Lage ist, den Vault-Datenverkehr der Anwendung abzufangen oder umzuleiten, kann sich als Vault-Server ausgeben, Vault-Authentifizierungsdaten erbeuten und gefälschte Vault/KMS-Antworten zurückgeben.
Die betroffene HCVault-Integration bietet Konfigurationsmöglichkeiten für Vault-Tokens, Namespaces und AppRole-Anmeldedaten, aber betroffene Versionen bieten keine unterstützte CA-Bundle-Konfiguration oder einen gleichwertigen Mechanismus zur Wiederherstellung der Zertifikatsüberprüfung.
Ein Angreifer mit einer Man-in-the-Middle-Position im Netzwerk zwischen der Anwendung und HashiCorp Vault kann:
X-Vault-Tokenrole_idsecret_idDies kann die Vertraulichkeit und Integrität von Daten kompromittieren, die durch den Vault-gestützten KMS-Workflow geschützt sind.
confluent-kafka ist der offizielle Confluent Python-Client für Apache Kafka.
Die Schwachstelle betrifft speziell Bereitstellungen, die Folgendes verwenden:
Schema Registry encryption rules
↓
HCVault KMS integration
↓
hcvault:// key URI
Die betroffene Nutzergruppe ist daher kleiner als alle confluent-kafka-Benutzer.
Allerdings ist die betroffene Funktionalität sicherheitskritisch, da diese Bereitstellungen auf HashiCorp Vault für kryptografisches Schlüsselmanagement und Feldverschlüsselung angewiesen sind.
HcVaultKmsClient.__init__() parst eine hcvault://-Schlüssel-URI, bestimmt die Vault-Basis-URL und erstellt einen hvac.Client.
In betroffenen Versionen, einschließlich 2.14.2, lautet der relevante Code:
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
)
Die hvac-Bibliothek stützt sich letztendlich auf den Python-requests-TLS-Stack.
Die Einstellung:
verify=False
weist den Client an, das TLS-Zertifikat des Remote-Servers nicht zu validieren.
Infolgedessen können Zertifikate akzeptiert werden, die normalerweise abgelehnt würden, einschließlich Zertifikaten, die:
Dies betrifft beide unterstützten Authentifizierungspfade.
Wenn Token-Authentifizierung verwendet wird, wird das Vault-Token über den:
X-Vault-Token
HTTP-Header gesendet.
Wenn ein Angreifer den Vault-Endpunkt erfolgreich imitiert, kann der vom Angreifer kontrollierte Server dieses Token empfangen.
Wenn AppRole-Authentifizierung verwendet wird, sendet der Client:
role_id
secret_id
an:
/v1/auth/approle/login
Ein erfolgreicher MITM kann daher beide AppRole-Anmeldedaten erbeuten.
Der betroffene HCVault-Treiber liest Konfigurationen einschließlich:
token.id
namespace
approle.role.id
approle.secret.id
sowie relevante VAULT_*-Umgebungsvariablen.
Betroffene Versionen bieten jedoch keine Konfiguration, die es Betreibern ermöglicht:
Infolgedessen können Anwendungen, die die betroffene Integration verwenden, die TLS-Überprüfung nicht über die normale Paketkonfiguration wiederherstellen.
Das Paket deaktiviert explizit die TLS-Server-Zertifikatsüberprüfung, anstatt sich auf den sicheren Standard zu verlassen.
Die verwundbare Konstruktion ist effektiv:
hvac.Client(..., verify=False)
anstelle von:
hvac.Client(..., verify=True)
oder einfach:
hvac.Client(...)
wobei die Überprüfung standardmäßig aktiviert ist.
Das Deaktivieren der Zertifikatsüberprüfung entfernt die Server-Authentifizierung aus der TLS-Verbindung.
Obwohl die Verbindung verschlüsselt bleibt, hat der Client keinen zuverlässigen Mechanismus, um festzustellen, ob er mit dem legitimen Vault-Server kommuniziert.
Dies schafft die Voraussetzung für einen Man-in-the-Middle-Angriff im Netzwerk.
Eine erfolgreiche Ausnutzung erfordert:
Die Anwendung verwendet eine betroffene Version von confluent-kafka:
2.8.0 bis 2.14.2.Die Anwendung verwendet Schema-Registry-Verschlüsselungsregeln mit der HCVault KMS-Integration.
Der konfigurierte KMS-Schlüssel verwendet das:
hcvault://
Schema.
Mögliche Beispiele sind:
Sobald die erforderliche MITM-Position besteht, sind keine Anwendungsberechtigungen oder Opferinteraktion erforderlich.
poc_confluent_kafka.py demonstriert das Problem gegen ein lokal entpacktes confluent-kafka 2.14.2-Wheel.
Das PoC verwendet:
HcVaultKmsClient-Implementierung.Das Proof of Concept enthält fünf Modi.