CVE-2026-57836: confluent-kafka में HashiCorp Vault KMS के लिए अक्षम TLS प्रमाणपत्र सत्यापन

गंभीरता: उच्च, CVSS 3.1 7.4

वेक्टर (v3.1): CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

प्रभावित: confluent-kafka >= 2.8.0, <= 2.14.2

में ठीक किया गया: 2.15.0

CWE: CWE-295 (अनुचित प्रमाणपत्र सत्यापन)

घटक: confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py

रिपोर्ट किया गया: Rahul Karne

CNA: VulnCheck

सारांश

confluent-kafka में HashiCorp Vault KMS क्लाइंट अपने hvac.Client का निर्माण करते समय verify=False को हार्डकोड करता है, जिससे Schema Registry फ़ील्ड-एन्क्रिप्शन नियमों के माध्यम से की जाने वाली Vault HTTPS कनेक्शनों के लिए TLS प्रमाणपत्र सत्यापन अक्षम हो जाता है।

कमजोर कोड यहाँ स्थित है:

confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py

प्रभावित क्लाइंट को निम्नानुसार आरंभ किया जाता है:

self._client = hvac.Client(
    url=vault_url,
    token=token,
    namespace=ns,
    verify=False
)

चूँकि verify=False बिना शर्त है, क्लाइंट अविश्वसनीय TLS प्रमाणपत्रों को स्वीकार करता है, जिनमें स्व-हस्ताक्षरित या हमलावर-नियंत्रित प्रमाणपत्र भी शामिल हैं।

एक नेटवर्क-स्थित हमलावर जो एप्लिकेशन के Vault ट्रैफ़िक को इंटरसेप्ट या रीडायरेक्ट करने में सक्षम है, Vault सर्वर का रूप धारण कर सकता है, Vault प्रमाणीकरण क्रेडेंशियल्स को कैप्चर कर सकता है, और नकली Vault/KMS प्रतिक्रियाएँ लौटा सकता है।

प्रभावित HCVault एकीकरण Vault टोकन, नेमस्पेस, और AppRole क्रेडेंशियल्स के लिए कॉन्फ़िगरेशन प्रदान करता है, लेकिन प्रभावित संस्करण प्रमाणपत्र सत्यापन को बहाल करने के लिए कोई समर्थित CA-बंडल कॉन्फ़िगरेशन या समकक्ष तंत्र प्रदान नहीं करते हैं।

प्रभाव

एप्लिकेशन और HashiCorp Vault के बीच नेटवर्क मैन-इन-द-मिडल स्थिति वाला हमलावर यह कर सकता है:

हमलावर-नियंत्रित या स्व-हस्ताक्षरित TLS प्रमाणपत्र प्रस्तुत करना।
उस प्रमाणपत्र को स्वीकार करवाना क्योंकि सत्यापन अक्षम है।
Vault प्रमाणीकरण सामग्री को कैप्चर करना, जिसमें शामिल है:
- X-Vault-Token
- AppRole role_id
- AppRole secret_id
नकली Vault प्रतिक्रियाएँ इंजेक्ट करना।
Schema Registry एन्क्रिप्शन नियमों द्वारा उपयोग किए जाने वाले KMS key-wrapping या key-unwrapping संचालनों में हस्तक्षेप करना।

यह Vault-समर्थित KMS वर्कफ़्लो द्वारा संरक्षित डेटा की गोपनीयता और अखंडता से समझौता कर सकता है।

पहुँच

confluent-kafka Apache Kafka के लिए आधिकारिक Confluent Python क्लाइंट है।

यह भेद्यता विशेष रूप से उन डिप्लॉयमेंट्स को प्रभावित करती है जो उपयोग करते हैं:

Schema Registry encryption rules
        ↓
HCVault KMS integration
        ↓
hcvault:// key URI

इसलिए प्रभावित जनसंख्या सभी confluent-kafka उपयोगकर्ताओं की तुलना में संकीर्ण है।

हालाँकि, प्रभावित कार्यक्षमता सुरक्षा-संवेदनशील है क्योंकि ये डिप्लॉयमेंट्स क्रिप्टोग्राफिक कुंजी प्रबंधन और फ़ील्ड-स्तरीय एन्क्रिप्शन के लिए HashiCorp Vault पर निर्भर करते हैं।

तकनीकी विवरण

HcVaultKmsClient.__init__() एक hcvault:// कुंजी URI को पार्स करता है, Vault बेस URL निर्धारित करता है, और एक hvac.Client बनाता है।

प्रभावित संस्करणों में, जिसमें 2.14.2 भी शामिल है, प्रासंगिक कोड है:

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
    )

hvac लाइब्रेरी अंततः Python requests TLS स्टैक पर निर्भर करती है।

सेटिंग:

verify=False

क्लाइंट को निर्देश देती है कि वह रिमोट सर्वर के TLS प्रमाणपत्र को मान्य न करे।

परिणामस्वरूप, वे प्रमाणपत्र जो सामान्यतः अस्वीकार किए जाते, स्वीकार किए जा सकते हैं, जिनमें शामिल हैं:

स्व-हस्ताक्षरित
समाप्त
गलत होस्टनाम के लिए जारी
अविश्वसनीय प्राधिकरण द्वारा हस्ताक्षरित
हमलावर द्वारा उत्पन्न

यह दोनों समर्थित प्रमाणीकरण पथों को प्रभावित करता है।

टोकन प्रमाणीकरण

जब टोकन प्रमाणीकरण का उपयोग किया जाता है, तो Vault टोकन इसके माध्यम से भेजा जाता है:

X-Vault-Token

HTTP हेडर।

यदि कोई हमलावर सफलतापूर्वक Vault एंडपॉइंट का रूप धारण कर लेता है, तो हमलावर-नियंत्रित सर्वर यह टोकन प्राप्त कर सकता है।

AppRole प्रमाणीकरण

जब AppRole प्रमाणीकरण का उपयोग किया जाता है, तो क्लाइंट भेजता है:

role_id
secret_id

इस पर:

/v1/auth/approle/login

इसलिए एक सफल MITM दोनों AppRole क्रेडेंशियल्स को कैप्चर कर सकता है।

अनुपलब्ध TLS कॉन्फ़िगरेशन

प्रभावित HCVault ड्राइवर निम्नलिखित सहित कॉन्फ़िगरेशन पढ़ता है:

token.id
namespace
approle.role.id
approle.secret.id

साथ ही प्रासंगिक VAULT_* पर्यावरण चर।

हालाँकि, प्रभावित संस्करण ऑपरेटरों को निम्नलिखित की अनुमति देने वाला कॉन्फ़िगरेशन प्रदान नहीं करते हैं:

कस्टम CA बंडल प्रदान करना।
सर्वर-प्रमाणपत्र सत्यापन बहाल करना।
विश्वसनीय निजी PKI रूट कॉन्फ़िगर करना।
समकक्ष सुरक्षित TLS सत्यापन व्यवहार कॉन्फ़िगर करना।

परिणामस्वरूप, प्रभावित एकीकरण का उपयोग करने वाले एप्लिकेशन सामान्य पैकेज कॉन्फ़िगरेशन के माध्यम से TLS सत्यापन बहाल नहीं कर सकते हैं।

मूल कारण

पैकेज सुरक्षित डिफ़ॉल्ट पर निर्भर रहने के बजाय स्पष्ट रूप से TLS सर्वर-प्रमाणपत्र सत्यापन को अक्षम करता है।

कमजोर निर्माण प्रभावी रूप से है:

hvac.Client(..., verify=False)

न कि:

hvac.Client(..., verify=True)

या बस:

hvac.Client(...)

जहाँ सत्यापन डिफ़ॉल्ट रूप से सक्षम है।

प्रमाणपत्र सत्यापन को अक्षम करना TLS कनेक्शन से सर्वर प्रमाणीकरण को हटा देता है।

हालाँकि कनेक्शन एन्क्रिप्टेड रहता है, क्लाइंट के पास यह निर्धारित करने का कोई विश्वसनीय तंत्र नहीं है कि वह वैध Vault सर्वर के साथ संचार कर रहा है या नहीं।

यह नेटवर्क मैन-इन-द-मिडल हमले के लिए आवश्यक स्थिति बनाता है।

शोषण की पूर्व शर्तें

सफल शोषण के लिए आवश्यक है:

एप्लिकेशन confluent-kafka का प्रभावित संस्करण उपयोग करता है:
- 2.8.0 से 2.14.2 तक।
एप्लिकेशन HCVault KMS एकीकरण के साथ Schema Registry एन्क्रिप्शन नियमों का उपयोग करता है।
कॉन्फ़िगर की गई KMS कुंजी इस स्कीम का उपयोग करती है:

hcvault://

हमलावर एप्लिकेशन और Vault के बीच ट्रैफ़िक को इंटरसेप्ट, रीडायरेक्ट, या रूप धारण करने में सक्षम नेटवर्क स्थिति प्राप्त करता है।

संभावित उदाहरणों में शामिल हैं:

DNS स्पूफ़िंग
ARP स्पूफ़िंग
समझौता किया गया नेटवर्क बुनियादी ढाँचा
रोग वाई-फ़ाई या राउटर बुनियादी ढाँचा
रूट/BGP हेरफेर
दुर्भावनापूर्ण एग्रेस प्रॉक्सी
समझौता किया गया नेटवर्क सेगमेंट

आवश्यक MITM स्थिति बनने के बाद किसी एप्लिकेशन-स्तरीय विशेषाधिकार या पीड़ित इंटरैक्शन की आवश्यकता नहीं है।

प्रूफ़ ऑफ़ कॉन्सेप्ट

poc_confluent_kafka.py स्थानीय रूप से अनपैक किए गए confluent-kafka 2.14.2 व्हील के विरुद्ध इस समस्या को प्रदर्शित करता है।

PoC उपयोग करता है:

HashiCorp Vault का अनुकरण करने वाला एक स्थानीय स्व-हस्ताक्षरित HTTPS सर्वर।
डमी Vault क्रेडेंशियल्स।
वास्तविक कमजोर HcVaultKmsClient कार्यान्वयन।
कोई वास्तविक Kafka बुनियादी ढाँचा नहीं।
कोई वास्तविक Vault बुनियादी ढाँचा नहीं।
कोई उत्पादन क्रेडेंशियल्स नहीं।

प्रूफ़ ऑफ़ कॉन्सेप्ट में पाँच मोड हैं।

सेटअप

PoC निर्भरताएँ स्थापित करें:

pip install hvac cryptography

अनपैक किए गए कमजोर व्हील को PoC के बगल में रखें:

confluent_kafka-2.14.2-cp310-cp310-win_amd64/
└── confluent_kafka/
    └── schema_registry/
        └── ...

PoC सीधे अनपैक किए गए 2.14.2 पैकेज से HcVaultKmsClient आयात करता है।

यह tink जैसी असंबंधित निर्भरताओं को स्टब करता है, जिससे पूर्ण Kafka या KMS वातावरण की आवश्यकता के बिना कमजोर Vault-क्लाइंट निर्माण का परीक्षण किया जा सकता है।

चलाएँ

दो टर्मिनल का उपयोग करें।

टर्मिनल 1 — मॉक Vault शुरू करें

python poc_confluent_kafka.py server

मॉक HTTPS Vault यहाँ सुनता है:

https://localhost:8443

स्व-हस्ताक्षरित प्रमाणपत्र का उपयोग करके।

टर्मिनल 2 — सुरक्षित नियंत्रण

पहले प्रदर्शित करें कि उचित प्रमाणपत्र सत्यापन स्व-हस्ताक्षरित सर्वर को अस्वीकार करता है:

python poc_confluent_kafka.py control

अपेक्षित परिणाम:

EXPECTED TLS failure: CERTIFICATE_VERIFY_FAILED
-> verify=True correctly rejected the self-signed cert

कमजोर टोकन पथ

चलाएँ:

python poc_confluent_kafka.py token

कमजोर HcVaultKmsClient सर्वर द्वारा अविश्वसनीय प्रमाणपत्र प्रस्तुत किए जाने के बावजूद कनेक्ट होता है।

मॉक सर्वर Vault टोकन को देख सकता है:

GET /v1/auth/token/lookup-self
X-Vault-Token: CNA-DEMO-VAULT-TOKEN
X-Vault-Namespace: cna-demo-namespace

कमजोर AppRole पथ

चलाएँ:

python poc_confluent_kafka.py approle

मॉक Vault प्राप्त करता है:

POST /v1/auth/approle/login
{"role_id": "CNA-DEMO-ROLE-ID", "secret_id": "CNA-DEMO-SECRET-ID"}

सुरक्षित control मोड और कमजोर token / approle मोड के बीच का अंतर प्रदर्शित करता है कि व्यवहार हार्डकोड किए गए:

verify=False

के कारण होता है, न कि परीक्षण वातावरण के कारण।

उपचार

बुनियादी सुरक्षित समाधान यह है कि hvac को प्रमाणपत्र सत्यापन करने की अनुमति दी जाए:

hvac.Client(
    url=vault_url,
    token=token,
    namespace=ns
)

चूँकि TLS सत्यापन डिफ़ॉल्ट रूप से सक्षम है, इसे स्पष्ट रूप से अक्षम करना अनावश्यक है।

एक मजबूत कार्यान्वयन को चाहिए:

डिफ़ॉल्ट रूप से TLS प्रमाणपत्र सत्यापन सक्षम करना।
एक कॉन्फ़िगर करने योग्य CA बंडल का समर्थन करना, उदाहरण के लिए:

ssl.ca.location

Vault-विशिष्ट CA कॉन्फ़िगरेशन का समर्थन करना जैसे:

VAULT_CACERT

म्यूचुअल TLS का उपयोग करने वाले वातावरणों के लिए क्लाइंट प्रमाणपत्रों का समर्थन करना।
खाली या फ़ाल्सी कॉन्फ़िगरेशन मान को चुपचाप प्रमाणपत्र सत्यापन अक्षम करने से रोकना।
रिग्रेशन परीक्षण जोड़ना जो पुष्टि करता है कि स्व-हस्ताक्षरित और अन्यथा अविश्वसनीय प्रमाणपत्र डिफ़ॉल्ट रूप से अस्वीकार किए जाते हैं।

ठीक किया गया संस्करण

भेद्यता यहाँ ठीक की गई है:

confluent-kafka 2.15.0

प्रभावित संस्करण हैं:

2.8.0
से
2.14.2

2.15.0 में, Vault क्लाइंट व्यवहार को बदल दिया गया ताकि TLS सत्यापन डिफ़ॉल्ट रूप से सक्षम हो।

अद्यतन कार्यान्वयन TLS-संबंधित कॉन्फ़िगरेशन भी प्रस्तुत करता है जिसमें शामिल है:

ssl.ca.location
VAULT_CACERT
ssl.certificate.location
ssl.key.location

यह निजी PKI बुनियादी ढाँचे का उपयोग करने वाले डिप्लॉयमेंट्स को प्रमाणपत्र सत्यापन अक्षम किए बिना विश्वसनीय CA और क्लाइंट-प्रमाणपत्र कॉन्फ़िगरेशन प्रदान करने की अनुमति देता है।

CVSS

भेद्यता को स्कोर किया गया है:

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

CVSS 3.1 स्कोर: 7.4 — उच्च

वेक्टर विश्लेषण

AV:N — नेटवर्क

कमजोर Vault संचार एक नेटवर्क कनेक्शन पर होता है।

AC:H — उच्च आक्रमण जटिलता

हमलावर को नेटवर्क MITM स्थिति प्राप्त करनी होती है या अन्यथा Vault कनेक्शन को रीडायरेक्ट करना होता है।

यह एक महत्वपूर्ण पूर्व शर्त है और यही कारण है कि भेद्यता को क्रिटिकल के बजाय उच्च रेट किया गया है।

PR:N — कोई विशेषाधिकार आवश्यक नहीं

हमलावर को प्रभावित एप्लिकेशन के भीतर विशेषाधिकारों की आवश्यकता नहीं है।

UI:N — कोई उपयोगकर्ता इंटरैक्शन नहीं

हमलावर द्वारा आवश्यक नेटवर्क स्थिति प्राप्त करने के बाद किसी उपयोगकर्ता इंटरैक्शन की आवश्यकता नहीं है।

S:U — दायरा अपरिवर्तित

प्रभाव प्रभावित एप्लिकेशन और उसके Vault इंटरैक्शन के सुरक्षा प्राधिकार के भीतर रहता है।

C:H — उच्च गोपनीयता प्रभाव

Vault टोकन या AppRole क्रेडेंशियल्स हमलावर के सामने उजागर हो सकते हैं।

I:H — उच्च अखंडता प्रभाव

हमलावर Vault का रूप धारण कर सकता है और नकली Vault/KMS प्रतिक्रियाएँ लौटा सकता है।

A:N — कोई उपलब्धता प्रभाव नहीं

कोई प्रत्यक्ष उपलब्धता प्रभाव प्रदर्शित नहीं किया गया।

स्थिति

प्रभावित: 2.8.0 से 2.14.2 तक
ठीक किया गया: 2.15.0
CWE: CWE-295
CVE: लंबित / अभी तक असाइन नहीं किया गया

हार्डकोड किया गया verify=False HCVault एकीकरण की शुरुआत से संस्करण 2.14.2 तक मौजूद था।

सुरक्षा व्यवहार को 2.15.0 में ठीक किया गया।

प्रकटीकरण समयरेखा

YYYY-MM-DD — Confluent को रिपोर्ट किया गया।
2026-06-26 — सुरक्षित TLS सत्यापन फ़िक्स अपस्ट्रीम में मर्ज किया गया।
ठीक किया गया संस्करण 2.15.0 के रूप में जारी किया गया।
CVE असाइनमेंट लंबित।

श्रेय

खोजा और रिपोर्ट किया गया Rahul Karne द्वारा।

संदर्भ

confluent-kafka-python
https://github.com/confluentinc/confluent-kafka-python
PyPI पर confluent-kafka
https://pypi.org/project/confluent-kafka/
HashiCorp hvac Python क्लाइंट
https://hvac.readthedocs.io/
HashiCorp Vault AppRole प्रमाणीकरण
https://developer.hashicorp.com/vault/api-docs/auth/approle
CWE-295 — अनुचित प्रमाणपत्र सत्यापन
https://cwe.mitre.org/data/definitions/295.html
Python TLS / प्रमाणपत्र सत्यापन दस्तावेज़ीकरण
https://docs.python.org/3/library/ssl.html#ssl-security

परिचय

यह रिपॉज़िटरी एक समन्वित-प्रकटीकरण सुरक्षा निष्कर्ष का दस्तावेज़ीकरण करती है और एक हानिरहित, स्व-निहित प्रूफ़ ऑफ़ कॉन्सेप्ट प्रदान करती है।

PoC पूरी तरह से डमी क्रेडेंशियल्स का उपयोग करके एक स्थानीय मॉक Vault सर्वर के विरुद्ध संचालित होता है।

यह वास्तविक HashiCorp Vault, Kafka, Schema Registry, उत्पादन बुनियादी ढाँचे, या वास्तविक क्रेडेंशियल्स के साथ इंटरैक्ट नहीं करता है।

यह सामग्री रक्षात्मक सुरक्षा अनुसंधान और शैक्षिक उद्देश्यों के लिए प्रदान की गई है।

प्रेस

मीडिया पूछताछ: [email protected]। पूर्ण PoC (हमलावर सर्वर, ट्रैवर्सल आर्काइव, पीड़ित एप्लिकेशन) और अतिरिक्त तकनीकी विवरण अनुरोध पर उपलब्ध।

`cert`	स्थानीय मॉक Vault के लिए स्व-हस्ताक्षरित प्रमाणपत्र और कुंजी उत्पन्न करता है।
`server`	`https://localhost:8443` पर मॉक HTTPS Vault शुरू करता है और प्राप्त अनुरोधों को प्रदर्शित करता है।
`control`	`verify=True` का उपयोग करके सुरक्षित नियंत्रण; स्व-हस्ताक्षरित प्रमाणपत्र को `CERTIFICATE_VERIFY_FAILED` के साथ अस्वीकार करना चाहिए।
`token`	कमजोर `HcVaultKmsClient` को लोड करता है और प्रदर्शित करता है कि यह अविश्वसनीय प्रमाणपत्र को स्वीकार करता है।
`approle`	कमजोर AppRole प्रमाणीकरण पथ का परीक्षण करता है और `role_id` और `secret_id` के एक्सपोज़र को प्रदर्शित करता है।

सबसे लोकप्रिय

CVE-2026-57836-Confluent_Kafka