CVE-2026-40176 — कंपोज़र पर्फ़ोर्स ड्राइवर कमांड इंजेक्शन (प्रूफ़ ऑफ़ कॉन्सेप्ट)

एक स्व-निहित, OOP-शैली PHP प्रूफ़ ऑफ़ कॉन्सेप्ट जो कंपोज़र के पर्फ़ोर्स रिपॉजिटरी ड्राइवर में एक कमांड-इंजेक्शन भेद्यता को प्रदर्शित और अंतर सत्यापित करता है।

PoC एक ही दुर्भावनापूर्ण composer.json को दो कंपोज़र बाइनरी — एक प्रभावित रिलीज़ (2.9.5) और एक ठीक की गई रिलीज़ (2.9.6) — पर चलाता है, और एक साइड इफ़ेक्ट (एक इंजेक्टेड शेल कमांड द्वारा लिखी गई मार्कर फ़ाइल) का अवलोकन करके बग को साबित करता है जो प्रभावित संस्करण पर ट्रिगर होता है लेकिन ठीक किए गए संस्करण पर नहीं।

⚠️ केवल अधिकृत सुरक्षा अनुसंधान और रक्षात्मक परीक्षण के लिए। जिम्मेदार उपयोग देखें।

---

विषय सूची

• सारांश
• भेद्यता
• PoC कैसे काम करता है
• इंजेक्शन पेलोड समझाया गया
• आवश्यकताएँ
• सेटअप
• उपयोग
• अपेक्षित आउटपुट
• परिणाम की व्याख्या
• प्रोजेक्ट संरचना
• डिज़ाइन नोट्स
• सीमाएँ और ज्ञात समस्याएँ
• जिम्मेदार उपयोग
• संदर्भ

---

सारांश

सीवीई	CVE-2026-40176
घटक	कंपोज़र — पर्फ़ोर्स (perforce) रिपॉजिटरी/VCS ड्राइवर
वर्ग	हमलावर-नियंत्रित रिपॉजिटरी URL के माध्यम से OS कमांड इंजेक्शन
हमला सतह	एक composer.json जिसमें type: perforce की एक क्राफ्टेड repositories प्रविष्टि है
प्रभावित	कंपोज़र 2.9.5
ठीक किया गया	कंपोज़र 2.9.6
ट्रिगर	दुर्भावनापूर्ण मेनिफेस्ट के विरुद्ध निर्भरताओं को हल/अपडेट करना (composer update)
प्रभाव	कंपोज़र चलाने वाली मशीन पर मनमाना कमांड निष्पादन
PoC भाषा	PHP (एकल फ़ाइल, कोई बाहरी निर्भरता नहीं)

---

भेद्यता

कंपोज़र कई संस्करण-नियंत्रण प्रणालियों से पैकेज हल कर सकता है। पर्फ़ोर्स के लिए, रिपॉजिटरी एक p4:// URL द्वारा पहचाना जाता है जो होस्ट, पोर्ट और उपयोगकर्ता/स्ट्रीम को एन्कोड करता है। जब कंपोज़र का पर्फ़ोर्स ड्राइवर अंतर्निहित p4 कमांड लाइन बनाता है, तो हमलावर-नियंत्रित URL से लिए गए फ़ील्ड शेल को सौंपे जाने से पहले पर्याप्त रूप से स्वच्छ नहीं किए जाते हैं।

चूंकि मेनिफेस्ट लेखक रिपॉजिटरी URL को पूरी तरह से नियंत्रित करता है, एक हमलावर जो किसी पीड़ित को दुर्भावनापूर्ण composer.json के विरुद्ध composer update/composer install चलाने के लिए प्रेरित कर सकता है (उदाहरण के लिए, एक जहरीली निर्भरता, एक शत्रुतापूर्ण रिपॉजिटरी, या अविश्वसनीय प्रोजेक्ट फ़ाइलों को संसाधित करने वाला CI कार्य) इच्छित p4 आह्वान से बाहर निकल सकता है और कंपोज़र प्रक्रिया के विशेषाधिकारों के साथ मनमाना OS कमांड निष्पादित कर सकता है।

यह ऐतिहासिक कंपोज़र VCS-ड्राइवर आर्गुमेंट-इंजेक्शन समस्याओं के समान परिवार से संबंधित है, जहां URL/ब्रांच/स्ट्रीम मान बिना एस्केपिंग के शेल कमांड में प्रवाहित होते हैं। कंपोज़र 2.9.6 पर्फ़ोर्स ड्राइवर को मजबूत करता है ताकि इंजेक्टेड पेलोड अब निष्पादित न हो।

यहां प्रदर्शित व्यवहार का आधिकारिक विवरण स्वयं PoC स्रोत (CVE202640176Test.php) है; अपस्ट्रीम फिक्स विवरण के लिए आधिकारिक सलाहकार और कंपोज़र चेंजलॉग देखें।

---

PoC कैसे काम करता है

PoC एक एकल वर्ग है, CVE202640176Test, जो एक नियंत्रित A/B (अंतर) प्रयोग करता है:

1. प्रीफ़्लाइट — दोनों कंपोज़र बाइनरी (प्रभावित 2.9.5 और ठीक की गई 2.9.6) पर --version क्वेरी करता है और यदि उनमें से किसी को भी आमंत्रित नहीं किया जा सकता है तो जल्दी बाहर निकल जाता है।
2. प्रभावित रन (2.9.5)
   • सिस्टम टेम्प पथ के अंतर्गत एक पृथक अस्थायी निर्देशिका बनाता है।
   • एक composer.json लिखता है जिसके repositories अनुभाग में एक perforce प्रविष्टि है जिसमें एक इंजेक्टेड शेल पेलोड वाला दुर्भावनापूर्ण p4:// URL है।
   • उस निर्देशिका में composer update चलाता है।
   • परिणाम को मान्य करता है।
3. ठीक किया गया रन (2.9.6) — पैच किए गए बाइनरी के विरुद्ध बिल्कुल वही कदम दोहराता है।
4. पुनर्स्थापना — एक finally ब्लॉक हमेशा प्रोजेक्ट निर्देशिका में मूल composer.json को पुनर्स्थापित करता है।
5. निर्णय — केवल तब PASS प्रिंट करता है जब प्रभावित रन साइड इफ़ेक्ट दिखाता है और ठीक किया गया रन नहीं दिखाता।

सत्यापन (क्या "शोषित" माना जाता है)

प्रत्येक रन के लिए, validateRun() तीन चीज़ों की जाँच करता है:

जांच	यह क्या साबित करता है
मार्कर फ़ाइल मौजूद है और उसमें रन ID है	इंजेक्टेड touch/echo पेलोड वास्तव में निष्पादित हुआ — अर्थात कमांड इंजेक्शन सफल हुआ।
कंपोज़र आउटपुट में p4 का उल्लेख है	पर्फ़ोर्स ड्राइवर कोड पथ तक पहुंच गया था (पेलोड सही घटक द्वारा संसाधित किया गया था, किसी असंबंधित चरण द्वारा नहीं)।
पार्स किया गया कंपोज़र संस्करण == अपेक्षित	सही बाइनरी (2.9.5 बनाम 2.9.6) वह थी जो चली।

एक रन केवल तभी "OK" होता है जब तीनों पास हों। समग्र परीक्षण पास होता है जब प्रभावित रन OK होता है और ठीक किया गया रन नहीं होता — एक वास्तविक भेद्यता का सटीक हस्ताक्षर जिसे बाद में पैच किया गया।

---

इंजेक्शन पेलोड (समझाया गया)

दुर्भावनापूर्ण रिपॉजिटरी URL writeComposerJson() में बनाया गया है:

p4://127.0.0.1:1666:attacker_user;touch <marker> && echo '<runId>' > <marker>:client_test

इसे तोड़ते हुए:

• p4://127.0.0.1:1666:attacker_user — एक अच्छी दिखने वाली पर्फ़ोर्स URL (होस्ट, पोर्ट 1666, उपयोगकर्ता)।
• ;touch <marker> && echo '<runId>' > <marker> — इंजेक्टेड शेल कमांड। अग्रणी ; इच्छित p4 कमांड को समाप्त करता है; touch मार्कर फ़ाइल बनाता है, और echo '<runId>' > <marker> उसमें अद्वितीय रन ID लिखता है ताकि PoC पुष्टि कर सके कि पेलोड (और कोई असंबंधित प्रक्रिया नहीं) ने फ़ाइल उत्पन्न की।
• :client_test — बाकी URL पार्सिंग को प्रशंसनीय बनाए रखने के लिए अनुगामी टेक्स्ट।

प्रभावित ड्राइवर पर शेल मेटाकैरेक्टर का सम्मान किया जाता है और मार्कर फ़ाइल बनाई जाती है। ठीक किए गए ड्राइवर पर मान को ठीक से एस्केप/कोट किया जाता है, इसलिए वही स्ट्रिंग निष्क्रिय डेटा के रूप में मानी जाती है और कोई मार्कर प्रकट नहीं होता।

नोट: PoC एक अद्वितीय, टाइमस्टैम्प्ड रन ID का उपयोग करता है और अपने मार्कर को एक पृथक अस्थायी निर्देशिका के अंदर लिखता है, इसलिए पेलोड हानिरहित और स्व-सफाई है न कि विनाशकारी।

---

आवश्यकताएँ

• PHP 7.4+ (PHP 8.x CLI के विरुद्ध विकसित/परीक्षित)। PoC स्वयं केवल मुख्य फ़ंक्शन का उपयोग करता है — हार्नेस चलाने के लिए किसी Composer पैकेज की आवश्यकता नहीं।
• दो कंपोज़र बाइनरी PHAR के रूप में उपलब्ध:
  • कंपोज़र 2.9.5 (प्रभावित)
  • कंपोज़र 2.9.6 (ठीक किया गया)
• POSIX-जैसा शेल वातावरण (exec() cd … && php … चलाता है)। Linux/macOS के लिए डिज़ाइन किया गया।
• प्रोजेक्ट निर्देशिका में एक आधार composer.json (यह स्टार्टअप पर पढ़ा जाता है, प्रत्येक अस्थायी रन में कॉपी किया जाता है, और बाद में पुनर्स्थापित किया जाता है)।

आपको आम तौर पर एक लाइव पर्फ़ोर्स सर्वर की आवश्यकता नहीं है: भेद्यता इस बात में है कि कंपोज़र p4 कमांड लाइन कैसे बनाता है, और इंजेक्टेड पेलोड किसी वास्तविक p4 कनेक्शन से पहले/आसपास चलता है। कंपोज़र एक पर्फ़ोर्स कनेक्शन त्रुटि लॉग कर सकता है — यह अपेक्षित है और मार्कर-फ़ाइल प्रमाण को प्रभावित नहीं करता।

---

सेटअप

1. PoC को क्लोन करें / रखें एक कार्यशील निर्देशिका में।

2. एक composer.json प्रदान करें PoC के समान निर्देशिका में। एक न्यूनतम पर्याप्त है:

   {
     "name": "research/cve-2026-40176-poc",
     "description": "Base manifest for the CVE-2026-40176 differential PoC",
     "require": {}
   }
   

3. दो कंपोज़र बाइनरी प्राप्त करें और उन्हें वहां रखें जहां PoC उनकी अपेक्षा करता है (डिफ़ॉल्ट दिखाए गए हैं):

   /usr/local/bin/composer-2.9.5.phar   # प्रभावित
   /usr/local/bin/composer-2.9.6.phar   # ठीक किया गया
   

   आप आधिकारिक संग्रह से विशिष्ट कंपोज़र रिलीज़ डाउनलोड कर सकते हैं, उदा.:

   curl -Lo /usr/local/bin/composer-2.9.5.phar https://getcomposer.org/download/2.9.5/composer.phar
   curl -Lo /usr/local/bin/composer-2.9.6.phar https://getcomposer.org/download/2.9.6/composer.phar
   

   यदि आपके पथ भिन्न हैं, तो CVE202640176Test.php के नीचे दो कंस्ट्रक्टर तर्क संपादित करें।

---

उपयोग

php CVE202640176Test.php