nimaarek/cve-2026-8932-pocCVE-2026-8932 का प्रूफ-ऑफ-कॉन्सेप्ट, जो libcurl कनेक्शन पुनःउपयोग में अपूर्ण mTLS कॉन्फ़िगरेशन मिलान दोष है, जिसमें एक स्थानीय लैब सर्वर और C PoC शामिल है।
CVE-2026-8932 का प्रूफ-ऑफ-कॉन्सेप्ट पुनरुत्पादन, जो libcurl कनेक्शन पुन:उपयोग में एक अपूर्ण mTLS कॉन्फ़िगरेशन मिलान समस्या है।
CVE-2026-8932 libcurl के कनेक्शन पुन:उपयोग तर्क को प्रभावित करता है जब अनुरोधों के बीच mutual TLS (mTLS) कॉन्फ़िगरेशन बदलता है।
संवेदनशील परिस्थितियों में, libcurl एक मौजूदा TLS कनेक्शन का पुन:उपयोग कर सकता है, भले ही एक mTLS-संबंधित कॉन्फ़िगरेशन विकल्प बदल गया हो और उस कनेक्शन के पुन:उपयोग को रोकना चाहिए था।
यह PoC दो अनुरोधों के बीच निजी-कुंजी पासवर्ड बदलकर समस्या का प्रदर्शन करता है, जबकि समान क्लाइंट प्रमाणपत्र और निजी कुंजी का उपयोग किया जाता है।
पहला अनुरोध सही पासवर्ड का उपयोग करता है:
correct-password
दूसरा अनुरोध जानबूझकर एक अमान्य पासवर्ड का उपयोग करता है:
WRONG-PASSWORD
यदि libcurl गलत तरीके से मौजूदा TLS कनेक्शन का पुन:उपयोग करता है, तो दूसरे अनुरोध को एक और TLS हैंडशेक की आवश्यकता नहीं होती। परिणामस्वरूप, नया TLS कनेक्शन स्थापित करने के लिए अमान्य निजी-कुंजी पासवर्ड की कभी आवश्यकता नहीं पड़ती और अनुरोध सफल हो जाता है।
इसलिए PoC CVE-2026-8932 से जुड़ी कनेक्शन-पुन:उपयोग स्थिति का प्रदर्शन करता है।
| Property | Value |
|---|
| CVE | CVE-2026-8932 |
| Component | libcurl |
| Vulnerability Type | Incomplete mTLS configuration matching |
| CWE | CWE-305 — Authentication Bypass by Primary Weakness |
| Affected Area | TLS connection reuse |
| Protocol | HTTPS / mTLS |
| Client | libcurl API |
| curl CLI | Not affected |
| PoC Scope | Local laboratory environment |
यह भेद्यता एक तर्क/कॉन्फ़िगरेशन मिलान समस्या है, न कि बफ़र ओवरफ़्लो या use-after-free जैसी पारंपरिक मेमोरी-सुरक्षा भेद्यता।
libcurl कनेक्शन जानकारी बनाए रखता है और जब कोई बाद का अनुरोध कनेक्शन के कॉन्फ़िगरेशन के साथ संगत माना जाता है, तो मौजूदा कनेक्शन का पुन:उपयोग कर सकता है।
इसलिए TLS कनेक्शनों के लिए, पुन:उपयोग से पहले कनेक्शन कॉन्फ़िगरेशन की सावधानीपूर्वक तुलना की जानी चाहिए।
संवेदनशील कार्यान्वयन ने कनेक्शन मिलान तर्क में सभी प्रासंगिक mTLS कॉन्फ़िगरेशन फ़ील्ड शामिल नहीं किए।
प्रभावित सेटिंग्स में शामिल हैं:
cert_type
key
key_type
key_passwd
key_blob
इस PoC द्वारा उपयोग की जाने वाली महत्वपूर्ण सेटिंग है:
key_passwd
PoC एक एन्क्रिप्टेड क्लाइंट निजी कुंजी और सही पासवर्ड का उपयोग करके एक TLS कनेक्शन स्थापित करता है:
correct-password
इसके बाद यह समान प्रमाणपत्र और कुंजी का उपयोग करके एक और अनुरोध करता है, लेकिन पासवर्ड बदल देता है:
WRONG-PASSWORD
एक संवेदनशील कनेक्शन-मिलान कार्यान्वयन अभी भी मौजूदा कनेक्शन को पुन:प्रयोज्य मान सकता है।
परीक्षण में दो HTTP अनुरोध होते हैं।
पहला अनुरोध TLS कनेक्शन स्थापित करता है:
URL:
https://server.test:8443/A
Client certificate:
client.crt
Private key:
client.key
Key password:
correct-password
TLS कनेक्शन बना रहता है क्योंकि सर्वर HTTP keep-alive का समर्थन करता है।
दूसरा अनुरोध समान प्रमाणपत्र और निजी कुंजी का उपयोग करता है, लेकिन कुंजी पासवर्ड बदल देता है:
URL:
https://server.test:8443/B
Client certificate:
client.crt
Private key:
client.key
Key password:
WRONG-PASSWORD
यदि libcurl एक नया TLS कनेक्शन बनाता है, तो गलत पासवर्ड के साथ एन्क्रिप्टेड निजी कुंजी लोड करना विफल होना चाहिए।
हालाँकि, यदि libcurl गलत तरीके से मौजूदा कनेक्शन का पुन:उपयोग करता है, तो किसी नए TLS हैंडशेक की आवश्यकता नहीं होती।
इसलिए अमान्य पासवर्ड HTTP अनुरोध को सफल होने से नहीं रोकता।
प्रयोगशाला सेटअप में शामिल हैं:
localhost
|
v
+---------------------+
| Python mTLS Server |
| 127.0.0.1:8443 |
+----------+----------+
|
| HTTPS / TLS 1.3
|
+--------+--------+
| |
/A /B
\ /
\ /
v v
Same TLS Connection
|
v
libcurl
PoC (C)
महत्वपूर्ण अवलोकन यह है कि /A और /B को समान TLS कनेक्शन पर पहुँचना चाहिए।
CVE-2026-8932-PoC/
├── README.md
├── LICENSE
├── .gitignore
│
├── certs/
│ └── .gitkeep
│
├── poc/
│ └── poc.c
│
├── server/
│ └── server.py
│
└── docs/
├── CVE-2026-8932-POC.jpg
├── CVE-2026-8932-server-POC.jpg
├── poc-output.txt
└── server-output.txt
certs/ निर्देशिका को रिपॉज़िटरी में जानबूझकर खाली रखा गया है। प्रमाणपत्र और निजी कुंजियाँ स्थानीय रूप से उत्पन्न की जानी चाहिए।
PoC का परीक्षण निम्नलिखित वातावरण में किया गया था:
OS:
Debian GNU/Linux 13 (trixie)
Architecture:
x86_64
libcurl:
8.14.1
OpenSSL:
3.5.7
GCC:
14.2.0
पुनरुत्पादन के लिए उपयोग किया गया संवेदनशील libcurl इंस्टॉलेशन था:
libcurl/8.14.1
स्थापित संस्करण सत्यापित करें:
curl --version
और:
pkg-config --modversion libcurl
mkdir -p ~/cve-2026-8932-lab/{certs,poc,server,docs}
cd ~/cve-2026-8932-lab
cd ~/cve-2026-8932-lab/certs
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes \
-key ca.key \
-sha256 \
-days 3650 \
-subj "/CN=CVE-2026-8932-CA" \
-out ca.crt
सर्वर निजी कुंजी उत्पन्न करें:
openssl genrsa -out server.key 2048
CSR उत्पन्न करें:
openssl req -new \
-key server.key \
-subj "/CN=server.test" \
-out server.csr
प्रमाणपत्र एक्सटेंशन बनाएँ:
printf "subjectAltName=DNS:server.test\nextendedKeyUsage=serverAuth\n" \
> server.ext
परीक्षण CA का उपयोग करके प्रमाणपत्र पर हस्ताक्षर करें:
openssl x509 -req \
-in server.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out server.crt \
-days 3650 \
-sha256 \
-extfile server.ext
क्लाइंट निजी कुंजी उत्पन्न करें:
openssl genrsa -out client.key.tmp 2048
CSR उत्पन्न करें:
openssl req -new \
-key client.key.tmp \
-subj "/CN=Client-A" \
-out client.csr
निजी कुंजी को एन्क्रिप्टेड PKCS#8 प्रारूप में बदलें:
openssl pkcs8 \
-topk8 \
-in client.key.tmp \
-out client.key \
-v2 aes-256-cbc \
-passout pass:correct-password
परिणामी निजी कुंजी इसके साथ एन्क्रिप्ट की गई है:
correct-password
क्लाइंट प्रमाणपत्र एक्सटेंशन बनाएँ:
printf "extendedKeyUsage=clientAuth\n" \
> client.ext
क्लाइंट प्रमाणपत्र पर हस्ताक्षर करें:
openssl x509 -req \
-in client.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out client.crt \
-days 3650 \
-sha256 \
-extfile client.ext
इस बिंदु पर आवश्यक फ़ाइलें मौजूद होनी चाहिए:
certs/
├── ca.crt
├── ca.key
├── client.crt
├── client.key
├── server.crt
└── server.key
सर्वर निर्देशिका में जाएँ:
cd ~/cve-2026-8932-lab/server
सर्वर प्रारंभ करें:
python3 server.py
सर्वर इस पर सुनता है:
0.0.0.0:8443
क्लाइंट प्रमाणपत्र प्रमाणीकरण आवश्यक है।
सर्वर HTTP/1.1 कनेक्शनों को भी सक्रिय रखता है ताकि libcurl TLS कनेक्शन का पुन:उपयोग कर सके।
एक और टर्मिनल खोलें:
cd ~/cve-2026-8932-lab/poc
कंपाइल करें:
gcc -Wall -Wextra -O0 -g \
poc.c \
$(pkg-config --cflags --libs libcurl) \
-o poc
निष्पादित करें:
./poc
PoC इसका उपयोग करता है:
Client certificate : client.crt
Private key : client.key
Request A password : correct-password
Request B password : WRONG-PASSWORD
सबसे महत्वपूर्ण क्लाइंट-साइड साक्ष्य है:
[+] STEP 2: Request using modified mTLS configuration
[+] Key password = WRONG-PASSWORD
* Re-using existing https: connection with host server.test
> GET /B HTTP/1.1
इसके बाद अनुरोध प्राप्त करता है:
< HTTP/1.1 200 OK
और PoC रिपोर्ट करता है:
[!!!] B REQUEST SUCCEEDED
यह महत्वपूर्ण है क्योंकि /B जानबूझकर एक अमान्य निजी-कुंजी पासवर्ड का उपयोग करता है।
मुख्य अवलोकन केवल यह नहीं है कि /B सफल होता है।
महत्वपूर्ण साक्ष्य यह है कि libcurl स्पष्ट रूप से रिपोर्ट करता है:
Re-using existing https: connection
इसलिए दूसरे अनुरोध को संशोधित कुंजी कॉन्फ़िगरेशन का उपयोग करके एक और TLS हैंडशेक करने की आवश्यकता नहीं है।
सर्वर आउटपुट कनेक्शन पुन:उपयोग की स्वतंत्र पुष्टि प्रदान करता है।
प्रासंगिक आउटपुट है:
[+] TLS connection #2
Client CN : Client-A
[+] Connection #2 Client=Client-A Request=GET /A HTTP/1.1
[+] Connection #2 Client=Client-A Request=GET /B HTTP/1.1
महत्वपूर्ण अवलोकन है:
/A -> Connection #2
/B -> Connection #2
इसलिए दोनों HTTP अनुरोध समान TLS कनेक्शन के माध्यम से प्राप्त हुए।
सर्वर दोनों अनुरोधों के लिए समान क्लाइंट पहचान भी रिपोर्ट करता है:
Client-A
PoC द्वारा उपयोग की जाने वाली निजी कुंजी एन्क्रिप्टेड है।
पहला अनुरोध इसका उपयोग करता है:
correct-password
जो libcurl/OpenSSL को निजी कुंजी तक पहुँचने और TLS कनेक्शन स्थापित करने की अनुमति देता है।
दूसरा अनुरोध कॉन्फ़िगरेशन को इसमें बदल देता है:
WRONG-PASSWORD
यदि एक नया TLS कनेक्शन स्थापित करना पड़ता, तो libcurl को एन्क्रिप्टेड निजी कुंजी को फिर से संसाधित करना होगा और गलत पासवर्ड के कारण ऑपरेशन विफल हो जाना चाहिए।
हालाँकि, जब मौजूदा TLS कनेक्शन का पुन:उपयोग किया जाता है, तो TLS सत्र पहले से ही स्थापित होता है।
/B के लिए किसी नए क्लाइंट प्रमाणीकरण ऑपरेशन की आवश्यकता नहीं है।
अवधारणात्मक रूप से:
Request A
|
| correct-password
v
TLS handshake
|
v
Established TLS connection
|
+----------------------+
| |
v v
/A /B
|
WRONG-PASSWORD
|
X
No new TLS handshake
|
v
HTTP succeeds
यह PoC कनेक्शन पुन:उपयोग का प्रदर्शन करता है, TLS सत्र पुनःआरंभ का नहीं।
दोनों तंत्र भिन्न हैं।
एक पहले से स्थापित TLS कनेक्शन खुला रहता है और किसी अन्य HTTP अनुरोध के लिए उपयोग किया जाता है:
TLS connection #2
|
+-- GET /A
|
+-- GET /B
किसी दूसरे TLS हैंडशेक की आवश्यकता नहीं है।
एक नया TCP/TLS कनेक्शन बनाया जाता है, लेकिन नए TLS हैंडशेक को छोटा करने के लिए पहले के कनेक्शन की क्रिप्टोग्राफिक सत्र जानकारी का उपयोग किया जाता है।
यह वह नहीं है जिस पर यह PoC निर्भर करता है।
PoC जानबूझकर दो easy handles के बीच साझा करता है:
CURL_LOCK_DATA_CONNECT
जबकि साझा नहीं करता:
CURL_LOCK_DATA_SSL_SESSION
यह प्रदर्शन को कनेक्शन पुन:उपयोग पर केंद्रित रखता है।
रिपॉज़िटरी में सफल पुनरुत्पादन से कैप्चर किया गया आउटपुट शामिल है।
कैप्चर किया गया आउटपुट प्रदर्शित करता है:
/A अनुरोधRe-using existing https: connection/B अनुरोधपूर्ण टर्मिनल आउटपुट यहाँ भी उपलब्ध है:
docs/poc-output.txt
सर्वर-साइड साक्ष्य प्रदर्शित करता है कि:
/A -> TLS connection #2
/B -> TLS connection #2
पूर्ण सर्वर आउटपुट यहाँ उपलब्ध है:
docs/server-output.txt
यदि PoC चलाने से पहले एक मैनुअल curl परीक्षण किया जाता है, तो सर्वर एक पहले का कनेक्शन प्रदर्शित कर सकता है:
TLS connection #1
यह कनेक्शन वास्तविक PoC निष्पादन से असंबंधित है।
उदाहरण के लिए, मैनुअल सत्यापन अनुरोध:
curl \
--resolve server.test:8443:127.0.0.1 \
--cacert ~/cve-2026-8932-lab/certs/ca.crt \
--cert ~/cve-2026-8932-lab/certs/client.crt \
--key ~/cve-2026-8932-lab/certs/client.key \
--pass correct-password \
https://server.test:8443/A
कनेक्शन #1 बना सकता है।
वास्तविक PoC तब कनेक्शन #2 बना सकता है।
इसलिए प्रासंगिक शर्त पूर्ण कनेक्शन संख्या नहीं है, बल्कि यह है कि:
/A and /B
PoC निष्पादन के दौरान समान TLS कनेक्शन पर दिखाई दें।
अपस्ट्रीम फ़िक्स है:
7541ae569d82fb308a5e2d94916027da4fa3ba3e
कमिट:
tls: fix incomplete mTLS config in conn reuse and session cache
फ़िक्स कनेक्शन मिलान तर्क में छूटी हुई mTLS कॉन्फ़िगरेशन तुलनाओं को जोड़ता है।
अवधारणात्मक रूप से, मिलान तर्क अब इन सहित मानों पर विचार करता है:
blobcmp(c1->key_blob, c2->key_blob) &&
curl_strequal(c1->cert_type, c2->cert_type) &&
Curl_safecmp(c1->key, c2->key) &&
curl_strequal(c1->key_type, c2->key_type) &&
!Curl_timestrcmp(c1->key_passwd, c2->key_passwd)
इस PoC के लिए महत्वपूर्ण परिवर्तन इसकी तुलना है:
key_passwd
इसलिए निजी-कुंजी पासवर्ड में परिवर्तन को मौजूदा कनेक्शन को पुन:उपयोग के लिए संगत माने जाने से रोकना चाहिए।
अपस्ट्रीम फ़िक्स ने TLS कॉन्फ़िगरेशन मिलान व्यवहार के लिए रिग्रेशन कवरेज भी पेश किया।
प्रासंगिक परीक्षण इससे जुड़ा है:
test 3303
रिग्रेशन परीक्षण mTLS कॉन्फ़िगरेशन में अंतरों को कवर करता है, जिनमें शामिल हैं:
key_passwd
key
key_type
cert_type
उदाहरण के लिए, समान कॉन्फ़िगरेशन मेल खाने चाहिए:
config A == config B
जबकि कुंजी पासवर्ड बदलने पर नहीं होना चाहिए:
config A key_passwd = password-A
config B key_passwd = password-B
↓
connection match = false
यह वही कॉन्फ़िगरेशन आयाम है जिसका उपयोग इस PoC द्वारा किया जाता है।
/B विफल होता हैयदि /B विफल होता है, तो पहले जाँचें कि क्या libcurl ने वास्तव में कनेक्शन का पुन:उपयोग किया।
वर्बोज़ आउटपुट में यह होना चाहिए:
Re-using existing https: connection
यदि यह पंक्ति दिखाई नहीं देती, तो भेद्यता स्थिति प्रदर्शित नहीं हुई है।
/A और /B भिन्न TLS कनेक्शनों पर दिखाई देते हैंसर्वर को यह दिखाना चाहिए:
Connection #X -> /A
Connection #X -> /B
यदि इसके बजाय आप देखते हैं:
Connection #X -> /A
Connection #Y -> /B
तो दूसरे अनुरोध ने एक नया TLS कनेक्शन बनाया और इच्छित स्थिति पुनरुत्पादित नहीं हुई।
जाँचें कि:
CURL_LOCK_DATA_CONNECT साझा है।CURLOPT_FORBID_REUSE सक्षम नहीं है।CURLOPT_FRESH_CONNECT सक्षम नहीं है।Connection: keep-alive भेजता है।क्लाइंट निजी कुंजी इसका उपयोग करके उत्पन्न की जानी चाहिए:
correct-password
इसके बाद PoC जानबूझकर इसका उपयोग करता है:
WRONG-PASSWORD
निजी-कुंजी निर्माण कमांड में एम्बेड किए गए पासवर्ड को तब तक न बदलें जब तक कि संबंधित PoC मान भी न बदला जाए।
यह रिपॉज़िटरी नियंत्रित सुरक्षा अनुसंधान और भेद्यता पुनरुत्पादन के लिए है।
PoC को स्थानीय रूप से होस्ट किए गए परीक्षण सर्वर के विरुद्ध संचालित करने के लिए डिज़ाइन किया गया है:
127.0.0.1:8443
अनधिकृत प्रणालियों के विरुद्ध PoC का उपयोग न करें।
निजी कुंजियाँ और उत्पन्न प्रमाणपत्र संस्करण नियंत्रण से बाहर रहने चाहिए।
रिपॉज़िटरी में केवल यह होना चाहिए:
certs/.gitkeep
उत्पन्न निजी कुंजियों के बजाय।
PoC डिज़ाइन, प्रयोगशाला कार्यप्रणाली, कार्यान्वयन, और तकनीकी विश्लेषण AliReza द्वारा OpenAI ChatGPT (GPT-5.6 Luna) की सहायता से विकसित किए गए थे।
मानव सत्यापन, निष्पादन, परीक्षण, और पुनरुत्पादन रिपॉज़िटरी लेखक द्वारा किए गए थे।
यह रिपॉज़िटरी सुरक्षा अनुसंधान, भेद्यता विश्लेषण, और शैक्षिक उद्देश्यों के लिए प्रदान की गई है।
इसका उपयोग केवल उन प्रणालियों और वातावरणों में करें जिनके लिए आपके पास स्पष्ट प्राधिकरण है।