आगामी महत्वपूर्ण PHP सुरक्षा रिलीज़ (CVE-2026-109618 / -109619)

मूल लेख ↗ Hacker News चर्चा ↗

PHP की कमजोरियों की एक गंभीर जोड़ी (CVE‑2026‑109618/109619, जिसे “PHP2Shell” कहा गया) PHP संस्करण 5 और उससे आगे की लगभग हर इंस्टॉलेशन पर बिना प्रमाणीकरण के remote code execution संभव बनाती है, जिससे वेब का अनुमानित बड़ा हिस्सा — जिसमें अनगिनत WordPress और MediaWiki साइटें शामिल हैं — जोखिम में पड़ गया। आधिकारिक पैच उपलब्ध होने से पहले proof-of-concept exploits के प्रसारित होने के साथ, operators ने multipart POST अनुरोधों को block करने या साइटों को पूरी तरह offline लेने जैसी आपात mitigations पर विचार किया, जबकि CDN और hosting providers ने जल्दी से WAF rules और backported fixes जारी किए। इस घटना ने LLM युग में coordinated disclosure और PHP जैसे बड़े C-आधारित runtimes की दीर्घकालिक सुरक्षा पर चिंताओं को फिर से उभारा है.

दायरा और गंभीरता

  • कमजोरियाँ (CVE-2026-109618 / -109619, उपनाम “PHP2Shell”) मूलतः PHP के 5.x से आगे के सभी संस्करणों, डिफ़ॉल्ट कॉन्फ़िग, सामान्य FPM सेटअप, और किसी भी सर्वर को प्रभावित करती हैं जो POST/multipart अनुरोध स्वीकार करता है।
  • कई टिप्पणीकार इसका प्रभाव Heartbleed/Log4Shell के बराबर या उससे भी बदतर बताते हैं, क्योंकि वेब पर PHP की ~70% हिस्सेदारी है और बिना प्रमाणीकरण के, वेब सर्वर उपयोगकर्ता के रूप में RCE का शोषण आसान है।
  • बाद में जारी advisories दो मुख्य चेन का वर्णन करती हैं: OOM corruption के जरिए RCE और multipart parsing में stale global state के जरिए RCE।

एक्सप्लॉइट और PoC स्थिति

  • आधिकारिक पैच से पहले सोशल मीडिया पर वीडियो डेमो और PoC प्रसारित हो गए; शुरुआती PoC अधूरे थे या केवल क्रैश कराते थे, लेकिन Cloudflare और अन्य के अनुसार वास्तविक दुनिया में सक्रिय शोषण हो रहा है।
  • एक्सप्लॉइट पाथ multipart/form-data parsing और upload progress handling का दुरुपयोग करता दिखता है; डिफ़ॉल्ट session/upload सेटिंग्स जोखिम बढ़ाती हैं।
  • कुछ टिप्पणीकारों का दावा है कि उन्होंने टेस्ट सिस्टम पर कम से कम memory corruption या सीमित database access प्राप्त कर लिया।

उपशमन और बचाव (पैच से पहले)

  • PHP core maintainers बार-बार कहते हैं कि केवल कॉन्फ़िगरेशन-आधारित mitigations पर्याप्त नहीं हैं; इसे पूरी तरह ठीक करने का तरीका केवल PHP को अपग्रेड करना है।
  • सामान्य अस्थायी उपाय:
    • session.upload_progress.enabled और कभी-कभी file_uploads को disable करें।
    • वेब सर्वर या WAF पर multipart/form-data या सभी POST/PUT/PATCH/DELETE को block करें।
    • अनुरोधों को केवल GET/HEAD तक सीमित करें, या PHP सेवाओं को पूरी तरह बंद कर दें।
  • कई providers (Cloudflare, अन्य CDNs, managed WordPress/hosting, Plesk, distros) WAF rules और/या backports तैनात कर रहे हैं; प्रभावशीलता को आंशिक/heuristic बताया गया है।

ऑपरेशनल प्रभाव

  • कई admins ने पैच से पहले MediaWiki, WordPress, Drupal, और custom PHP apps बंद कर दिए; कुछ सरकारें, विश्वविद्यालय, और बड़ी सेवाएँ अस्थायी रूप से साइटों को offline ले गईं।
  • shared hosting उपयोगकर्ता अक्सर PHP को साफ़ तरीके से disable नहीं कर पाते, जिससे यह भ्रम पैदा होता है कि “offline” का वास्तव में क्या अर्थ है।
  • लोग patched PHP packages, Docker images, और distro builds पाने की जल्दी में हैं; कुछ शिकायत करते हैं कि official container images source releases से पीछे रह गईं।

Disclosure और प्रक्रिया पर बहस

  • इस पर तीखी बहस हुई कि:
    • PoC लीक होने के बाद embargo बनाम तुरंत patch release।
    • क्या बड़े providers के साथ समन्वय करने के लिए patches में देरी करना छोटे operators को “छोड़ देना” है।
    • क्या LLMs कोई भी सार्वजनिक संकेत (या third-party writeups में SEO keywords) को bug को तेजी से फिर से खोजने के लिए पर्याप्त बना देते हैं।

व्यापक चिंतन

  • PHP के C codebase, multipart parser की गुणवत्ता, और security issues के लंबे इतिहास पर आलोचना फिर से तेज़ हुई; PHP को “oxidize” करने या Rust/Go/.NET या static sites पर माइग्रेट करने की मांगें उठीं।
  • दूसरी ओर, यह भी कहा गया कि हर stack में गंभीर CVEs होते हैं; असली मुद्दा defense-in-depth, process isolation, least privilege, और dynamic attack surface को कम करना है।