rahulreddykarne/cve-2026-57836-confluent_kafkaVerificación de certificado TLS deshabilitada para HashiCorp Vault KMS en confluent-kafka
Severidad: Alta, CVSS 3.1 7.4
Vector (v3.1): CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Afectado: confluent-kafka >= 2.8.0, <= 2.14.2
Corregido en: 2.15.0
CWE: CWE-295 (Validación de certificados incorrecta)
Componente: confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Reportado por: Rahul Karne
CNA: VulnCheck
El cliente de HashiCorp Vault KMS en confluent-kafka codifica de forma fija al construir su , deshabilitando la verificación de certificados TLS para las conexiones HTTPS a Vault realizadas a través de las reglas de cifrado de campos del Schema Registry.
verify=Falsehvac.ClientEl código vulnerable se encuentra en:
confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
El cliente afectado se inicializa de la siguiente manera:
self._client = hvac.Client(
url=vault_url,
token=token,
namespace=ns,
verify=False
)
Debido a que verify=False es incondicional, el cliente acepta certificados TLS no confiables, incluidos certificados autofirmados o controlados por el atacante.
Un atacante con posición de red capaz de interceptar o redirigir el tráfico de Vault de la aplicación puede suplantar el servidor de Vault, capturar credenciales de autenticación de Vault y devolver respuestas falsificadas de Vault/KMS.
La integración HCVault afectada expone configuración para tokens de Vault, namespaces y credenciales de AppRole, pero las versiones afectadas no proporcionan ninguna configuración de CA-bundle soportada ni un mecanismo equivalente para restaurar la verificación de certificados.
Un atacante con una posición de man-in-the-middle de red entre la aplicación y HashiCorp Vault puede:
X-Vault-Tokenrole_idsecret_idEsto puede comprometer la confidencialidad e integridad de los datos protegidos por el flujo de trabajo de KMS respaldado por Vault.
confluent-kafka es el cliente oficial de Confluent para Python para Apache Kafka.
La vulnerabilidad afecta específicamente a despliegues que utilizan:
Schema Registry encryption rules
↓
HCVault KMS integration
↓
hcvault:// key URI
Por lo tanto, la población afectada es más reducida que todos los usuarios de confluent-kafka.
Sin embargo, la funcionalidad afectada es sensible a la seguridad porque estos despliegues dependen de HashiCorp Vault para la gestión de claves criptográficas y el cifrado a nivel de campo.
HcVaultKmsClient.__init__() analiza una URI de clave hcvault://, determina la URL base de Vault y crea un hvac.Client.
En las versiones afectadas, incluida 2.14.2, el código relevante es:
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 librería hvac depende en última instancia del stack TLS de requests de Python.
Establecer:
verify=False
indica al cliente que no valide el certificado TLS del servidor remoto.
Como resultado, los certificados que normalmente serían rechazados pueden ser aceptados, incluidos certificados que son:
Esto afecta a ambas rutas de autenticación soportadas.
Cuando se utiliza autenticación por token, el token de Vault se envía a través de la cabecera HTTP:
X-Vault-Token
Si un atacante logra suplantar el endpoint de Vault, el servidor controlado por el atacante puede recibir este token.
Cuando se utiliza autenticación AppRole, el cliente envía:
role_id
secret_id
a:
/v1/auth/approle/login
Por lo tanto, un MITM exitoso puede capturar ambas credenciales de AppRole.
El driver HCVault afectado lee configuración que incluye:
token.id
namespace
approle.role.id
approle.secret.id
así como las variables de entorno VAULT_* relevantes.
Sin embargo, las versiones afectadas no exponen configuración que permita a los operadores:
Como resultado, las aplicaciones que utilizan la integración afectada no pueden restaurar la verificación TLS a través de la configuración normal del paquete.
El paquete deshabilita explícitamente la verificación del certificado del servidor TLS en lugar de confiar en el valor predeterminado seguro.
La construcción vulnerable es efectivamente:
hvac.Client(..., verify=False)
en lugar de:
hvac.Client(..., verify=True)
o simplemente:
hvac.Client(...)
donde la verificación está habilitada por defecto.
Deshabilitar la verificación de certificados elimina la autenticación del servidor de la conexión TLS.
Aunque la conexión permanece cifrada, el cliente no tiene un mecanismo fiable para determinar si se está comunicando con el servidor de Vault legítimo.
Esto crea la condición necesaria para un ataque de man-in-the-middle de red.
La explotación exitosa requiere:
La aplicación utiliza una versión afectada de confluent-kafka:
2.8.0 hasta 2.14.2.La aplicación utiliza reglas de cifrado del Schema Registry con la integración HCVault KMS.
La clave KMS configurada utiliza el esquema:
hcvault://
Ejemplos posibles incluyen:
No se requieren privilegios a nivel de aplicación ni interacción de la víctima una vez que existe la posición MITM necesaria.
poc_confluent_kafka.py demuestra el problema contra un wheel de confluent-kafka 2.14.2 desempaquetado localmente.
La PoC utiliza:
HcVaultKmsClient.La prueba de concepto contiene cinco modos.
| Modo | Descripción |
|---|---|
cert | Genera un certificado autofirmado y una clave para el Vault simulado local. |
server | Inicia el Vault HTTPS simulado en https://localhost:8443 y muestra las solicitudes recibidas. |
control | Control seguro usando verify=True; debería rechazar el certificado autofirmado con CERTIFICATE_VERIFY_FAILED. |
token | Carga el HcVaultKmsClient vulnerable y demuestra que acepta el certificado no confiable. |
approle | Ejercita la ruta de autenticación AppRole vulnerable y demuestra la exposición de role_id y secret_id. |
Instala las dependencias de la PoC:
pip install hvac cryptography
Coloca el wheel vulnerable desempaquetado junto a la PoC:
confluent_kafka-2.14.2-cp310-cp310-win_amd64/
└── confluent_kafka/
└── schema_registry/
└── ...
La PoC importa HcVaultKmsClient directamente desde el paquete 2.14.2 desempaquetado.
Sustituye dependencias no relacionadas como tink, lo que permite probar la construcción vulnerable del cliente de Vault sin requerir un entorno completo de Kafka o KMS.
Utiliza dos terminales.
python poc_confluent_kafka.py server
El Vault HTTPS simulado escucha en:
https://localhost:8443
utilizando un certificado autofirmado.
Primero demuestra que la validación de certificados adecuada rechaza el servidor autofirmado:
python poc_confluent_kafka.py control
Resultado esperado:
EXPECTED TLS failure: CERTIFICATE_VERIFY_FAILED
-> verify=True correctly rejected the self-signed cert
Ejecuta:
python poc_confluent_kafka.py token
El HcVaultKmsClient vulnerable se conecta a pesar de que el servidor presenta un certificado no confiable.
El servidor simulado puede observar el token de Vault:
GET /v1/auth/token/lookup-self
X-Vault-Token: CNA-DEMO-VAULT-TOKEN
X-Vault-Namespace: cna-demo-namespace
Ejecuta:
python poc_confluent_kafka.py approle
El Vault simulado recibe:
POST /v1/auth/approle/login
{"role_id": "CNA-DEMO-ROLE-ID", "secret_id": "CNA-DEMO-SECRET-ID"}
El contraste entre el modo control seguro y los modos vulnerables token / approle demuestra que el comportamiento es resultado del:
verify=False
codificado de forma fija, en lugar del entorno de prueba.
La corrección segura básica es permitir que hvac realice la verificación de certificados:
hvac.Client(
url=vault_url,
token=token,
namespace=ns
)
Dado que la verificación TLS está habilitada por defecto, deshabilitarla explícitamente es innecesario.
Una implementación robusta debería:
Habilitar la verificación de certificados TLS por defecto.
Soportar un CA bundle configurable, por ejemplo:
ssl.ca.location
VAULT_CACERT
Soportar certificados de cliente para entornos que utilizan mutual TLS.
Evitar que un valor de configuración vacío o falso deshabilite silenciosamente la verificación de certificados.
Añadir pruebas de regresión que confirmen que los certificados autofirmados y no confiables son rechazados por defecto.
La vulnerabilidad está corregida en:
confluent-kafka 2.15.0
Las versiones afectadas son:
2.8.0
through
2.14.2
En 2.15.0, el comportamiento del cliente de Vault se modificó para que la verificación TLS esté habilitada por defecto.
La implementación actualizada también introduce configuración relacionada con TLS, incluida:
ssl.ca.location
VAULT_CACERT
ssl.certificate.location
ssl.key.location
Esto permite a los despliegues que utilizan infraestructura PKI privada proporcionar configuración de CA de confianza y certificados de cliente sin deshabilitar la verificación de certificados.
La vulnerabilidad tiene una puntuación:
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Puntuación CVSS 3.1: 7.4 — Alta
AV:N — Red
La comunicación vulnerable con Vault ocurre a través de una conexión de red.
AC:H — Complejidad de ataque alta
El atacante debe obtener una posición MITM de red o redirigir de otro modo la conexión a Vault.
Este es un requisito previo significativo y es la razón por la que la vulnerabilidad se clasifica como Alta en lugar de Crítica.
PR:N — Sin privilegios requeridos
El atacante no requiere privilegios dentro de la aplicación afectada.
UI:N — Sin interacción del usuario
No se requiere interacción del usuario después de que el atacante obtenga la posición de red necesaria.
S:U — Alcance sin cambios
El impacto permanece dentro de la autoridad de seguridad de la aplicación afectada y su interacción con Vault.
C:H — Impacto alto en confidencialidad
Los tokens de Vault o las credenciales de AppRole pueden quedar expuestos al atacante.
I:H — Impacto alto en integridad
El atacante puede suplantar a Vault y devolver respuestas falsificadas de Vault/KMS.
A:N — Sin impacto en disponibilidad
No se demostró ningún impacto directo en la disponibilidad.
2.8.0 hasta 2.14.22.15.0El verify=False codificado de forma fija existió desde la introducción de la integración HCVault hasta la versión 2.14.2.
El comportamiento de seguridad se corrigió en 2.15.0.
YYYY-MM-DD — Reportado a Confluent.2.15.0.Descubierto y reportado por Rahul Karne.
confluent-kafka-python
https://github.com/confluentinc/confluent-kafka-python
confluent-kafka en PyPI
https://pypi.org/project/confluent-kafka/
Cliente Python hvac de HashiCorp
https://hvac.readthedocs.io/
Autenticación AppRole de HashiCorp Vault
https://developer.hashicorp.com/vault/api-docs/auth/approle
CWE-295 — Validación de certificados incorrecta
https://cwe.mitre.org/data/definitions/295.html
Documentación de TLS / verificación de certificados de Python
https://docs.python.org/3/library/ssl.html#ssl-security
Este repositorio documenta un hallazgo de seguridad de divulgación coordinada y proporciona una prueba de concepto inofensiva y autocontenida.
La PoC opera completamente contra un servidor de Vault simulado local utilizando credenciales ficticias.
No interactúa con HashiCorp Vault, Kafka, Schema Registry, infraestructura de producción ni credenciales reales.
El material se proporciona para investigación de seguridad defensiva y fines educativos.
Consultas de medios: [email protected]. PoC completa (servidor del atacante, archivo de traversal, aplicación víctima) y detalle técnico adicional disponibles bajo petición.