GPU VulnDB

Database/Control plane, storage & DevOps

Confluent Kafka Python client: TLS certificate verification disabled by default toward HashiCorp Vault KMS

CVSS 7.4CVE-2026-15911Control plane, storage & DevOpscurated

Impact

The client's Vault KMS integration, used to fetch the keys that protect Kafka message payloads, did not validate the Vault server's TLS certificate by default. An attacker positioned on the path between a producer or consumer and Vault can impersonate Vault, which means capturing the Vault token the client presents and serving back key material of the attacker's choosing. Where Kafka carries telemetry, job events or feature data across a fleet, this exposes the secret that guards those payloads rather than just one message. Confluent scores it 7.4 with high confidentiality and integrity impact; the record gives no indication of exploitation in the wild.

Who can reach it

An attacker able to intercept or redirect the network path from a Kafka client process to its Vault endpoint - the same-VLAN or compromised-DNS position. No credentials on either side are needed; Confluent rates attack complexity high because the position has to be obtained first.

What to do

Upgrade the confluent-kafka Python client to the fixed release named in Confluent advisory CONFSA-2026-22 and explicitly enable TLS verification on the Vault KMS configuration. This is a library bump: redeploy and restart each producer and consumer process that uses the Vault KMS integration. No node drain or reboot is involved, but every service with the client embedded has to be rolled.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.