PHP2Shell का पैच जारी हो चुका है, लेकिन जिन वेबसाइटों को इसकी सबसे ज़्यादा ज़रूरत है, उनमें से अधिकांश के पास इसे लागू करने का कोई बटन नहीं है। खामियां खुद PHP में हैं—उस इंजन में, जिस पर हर WordPress, Joomla और Drupal पेज चलता है। यह CMS, उसके प्लगइन और लॉगिन स्क्रीन से भी नीचे की परत है। WordPress अपडेट करने से इन खामियों पर कोई असर नहीं पड़ता। पैच वाला इंटरप्रेटर उसी के ज़रिए आना होगा जो सर्वर चलाता है: होस्टिंग कंपनी, Linux वितरण का पैकेज या कंटेनर इमेज। जब तक ऐसा नहीं होता, साइट इंतज़ार ही करती रहेगी—मालिक चाहे कुछ भी कर ले।

“अभी पैच करें” वाली सुर्खियां कहानी का यही पहलू छोड़ देती हैं। PHP टीम ने अपना काम कर दिया है। उसका पैच किसी खास सर्वर तक पहुंचेगा या नहीं, यह उस वितरण-श्रृंखला पर निर्भर है जो अपनी सबसे धीमी कड़ी की रफ्तार से चलती है। पहले ही दिन यह साफ हो गया कि इन कड़ियों के बीच कितना फासला है। जिस साइट-मालिक को पता ही नहीं कि उसके PHP का स्रोत क्या है, वह यह भी नहीं जान सकता कि उसकी साइट अब तक कितनी जोखिम में है।

WordPress अपडेट से यह समस्या क्यों नहीं सुलझती

चूंकि खामियां इंटरप्रेटर में हैं, इसलिए PHP की सुरक्षा चेतावनी उन सभी इंस्टॉलेशन पर लागू होती है जो वेब अनुरोधों का जवाब देते हैं—PHP-FPM और Apache के mod_php से लेकर php-cgi, FrankenPHP और LiteSpeed तक। The Hacker News के मुताबिक, असुरक्षित संस्करण पर चलने वाले साधारण-से “Hello World” पेज पर भी हमला किया जा सकता है। सबसे गंभीर स्थिति mod_php की है, जहां बिना खाते वाला कोई भी व्यक्ति एक अनुरोध भेजकर हमला शुरू कर सकता है—वह भी किसी एप्लिकेशन कोड के चलने से पहले। ऐसे में न कोई सुरक्षा प्लगइन और न ही लॉगिन स्क्रीन इसे देख पाती है।

WordPress सुरक्षा सेवा देने वाली कंपनी Wordfence ने साइट-मालिकों से कहा कि, जैसा कि The Verge ने बताया, यह पैच अपने-आप होने वाले अपडेट के ज़रिए नहीं आएगा। उन्हें पता लगाना होगा कि उनके PHP की ज़िम्मेदारी किसकी है। Laravel Forge ने अपने ग्राहकों को अपने सर्वरों के बारे में यही बात बताई: उसके स्वचालित सुरक्षा अपडेट PHP को पैच नहीं करते, और Ubuntu के unattended upgrades केवल Ubuntu के अपने रिपॉज़िटरी से अपडेट लेते हैं—उन तीसरे पक्ष के पैकेजों से नहीं, जिनके ज़रिए Forge PHP इंस्टॉल करता है।

इन पैकेज स्रोतों पर अपडेट एक साथ नहीं पहुंचे। रिलीज़ के दिन, साइट-प्रबंधन सेवा mySites.guru ने बताया कि cPanel के EasyApache 4 में सुरक्षा चेतावनियां जारी होने के कुछ ही मिनटों में ठीक किए गए बिल्ड उपलब्ध थे, जबकि ओन्ड्रेज सुरी (Ondřej Surý) के PPA, Laravel Forge के अपने Ubuntu पैकेज स्रोत और Remi के रिपॉज़िटरी में अभी कोई पैच नहीं था। InMotion Hosting ने कहा कि उसके साझा होस्टिंग और WordPress सर्वर CloudLinux के बिल्ड का इंतज़ार कर रहे थे। mySites.guru जिन लाइव साइटों पर नज़र रखता है, उनमें 13:52 UTC तक सिर्फ़ 0.08% ने PHP का पैच वाला संस्करण इस्तेमाल करने की सूचना दी थी।

संस्करण संख्या आपको गुमराह कर सकती है

यह पता लगाना उतना आसान नहीं जितना संस्करण संख्या देख लेना। Ubuntu, Debian और Red Hat, अपस्ट्रीम संस्करण बदले बिना सुरक्षा पैच अपने पैकेज में शामिल कर लेते हैं। इसलिए पैच वाला Ubuntu 24.04 सर्वर भी 8.3.6 पैकेज ही दिखा सकता है। Debian का हवाला देते हुए The Hacker News कहता है कि संस्करण संख्या पर भरोसा करने के बजाय पैकेज के changelog में CVE खोजें। mySites.guru एक और पेच बताता है: कमांड लाइन पर php -v का जवाब देने वाला PHP बाइनरी अक्सर वह नहीं होता जो वेब पेज चलाता है। इसलिए साइट खुद जिस संस्करण की जानकारी देती है, उसे जांचें।

इसके बाद पैच को लोड भी करना होगा। PHP की सुरक्षा चेतावनी और Forge—दोनों Apache, PHP-FPM और लंबे समय तक चलते रहने वाले हर worker को रीस्टार्ट करने पर ज़ोर देते हैं। Queue worker और इसी तरह की पृष्ठभूमि प्रक्रियाएं रीस्टार्ट होने तक पुराने इंटरप्रेटर पर ही चलती रहती हैं—भले ही डिस्क पर मौजूद फाइलें पैच की जा चुकी हों।

किन्हें आधिकारिक पैच नहीं मिलेगा

पैच वाले संस्करण हैं PHP 8.5.12, 8.4.27, 8.3.36 और 8.2.35। ये CVE-2026-109618 और CVE-2026-109619 को ठीक करते हैं; CVSS v4.0 में दोनों की गंभीरता 9.2 आंकी गई है। PHP 8.1 और इससे पुराने संस्करणों के लिए PHP प्रोजेक्ट की ओर से कोई पैच नहीं है। 7.4, 8.0 और 8.1 के लिए सिर्फ़ न्यूनतम स्रोत-स्तरीय बैकपोर्ट उपलब्ध हैं, जो खुद PHP कंपाइल करने वालों के लिए हैं। कुछ विक्रेता यह कमी पूरी कर रहे हैं: InMotion का कहना है कि cPanel ने उसके 7.4 से 8.1 तक के पैकेजों के लिए पैच बैकपोर्ट किए हैं और CloudLinux अपने हर उपलब्ध संस्करण को पैच कर रहा है। वहीं CentOS 7 के लिए कोई पैच नहीं है।

पुराने संस्करणों पर चल रही साइटों की संख्या कम नहीं है। रिलीज़ से एक दिन पहले, mySites.guru जिन Joomla और WordPress साइटों पर नज़र रखता है, उनमें 22.7% PHP 8.1 या इससे पुराने संस्करण पर थीं और 16.6% अब भी PHP 7 या उससे पुराने संस्करण पर चल रही थीं। कंपनी इसकी एक वजह खुद WordPress को मानती है: वह PHP 8.3 इस्तेमाल करने की सलाह देता है, लेकिन अब लंबे समय से समर्थन से बाहर 7.4 को भी अनुकूल संस्करणों की सूची में रखता है। PHP 8.2 को यह पैच तो मिला है, लेकिन उसका सुरक्षा समर्थन 31 दिसंबर, 2026 को समाप्त हो जाएगा।

अंतरिम सेटिंग से क्या रुकता है

रिलीज़ से पहले जो अस्थायी उपाय साझा किया जा रहा था—session.upload_progress.enabled=0 सेट करना—वह कारगर है, मगर पूरी सुरक्षा नहीं देता। PHP के मुताबिक, इससे CVE-2026-109619 तक पहुंचने वाले पुष्टि किए गए session रास्ते बंद होते हैं, लेकिन दूसरे तरीके नहीं रुकते। यह सेटिंग php.ini या सर्वर अथवा पूल कॉन्फ़िगरेशन में करनी होगी और फिर हर worker को रीस्टार्ट करना होगा। PHP 8.5 पर fatal_error_backtraces=0 सेट करने से एक और पुष्टि किया गया रास्ता बंद होता है। इनमें से कोई भी उपाय CVE-2026-109618 को नहीं रोकता। इसके लिए PHP ऐसा memory_limit=-1 सुझाता है जिसे बदला न जा सके, कम post_max_size और वेब सर्वर या प्रॉक्सी पर अनुरोध के आकार की सीमाएं। PHP का अपना कहना है कि इस खामी से बचाव का कोई पूरा उपाय उपलब्ध नहीं है। InMotion के मुताबिक WordPress, Joomla, Drupal, Magento और PrestaShop अपलोड प्रोग्रेस का इस्तेमाल नहीं करते, इसलिए इसे बंद करने से उनके लिए कुछ नहीं टूटेगा।

Cloudflare ने सभी प्लान पर फ़ायरवॉल नियम चालू कर दिए। कंपनी के मुख्य प्रौद्योगिकी अधिकारी डेन नेच्ट (Dane Knecht) ने इसे अस्थायी उपाय बताया। mySites.guru का कहना है कि ये नियम तभी मददगार हैं जब इनके पीछे का सर्वर, Cloudflare को दरकिनार करके सीधे उसके IP पते पर आने वाले ट्रैफ़िक को रोकता हो।

अब तक हुए हमले

watchTowr का कहना है कि रिलीज़ के दिन उसके honeypots ने दोनों खामियों का फायदा उठाने की कोशिशें दर्ज कीं। Cloudflare ने भी देखा कि हमलावर उसके नियमों से बच निकलने के लिए अपने payload बदल रहे थे। किसी स्रोत ने अब तक किसी खास सर्वर में सफल सेंध की पुष्टि नहीं की है। कुछ ऑपरेटरों ने कोई जोखिम नहीं लिया: The Hacker News के मुताबिक, BambooHR ने अपनी सेवा बंद कर दी और DigiD समेत नीदरलैंड की सरकारी सेवाएं एहतियातन ऑफलाइन हो गईं। यूरोपीय संघ की CERT और UK का National Cyber Security Centre उन संगठनों से, जो पैच नहीं लगा सकते, प्रभावित ऐप को अलग-थलग करने या ऑफलाइन करने को कह चुके हैं।

इन खामियों का पता Wiz Research, कैलिफ़ (Calif) और OpenAI की Codex Security टीम ने लगाया। PHP Foundation के मुताबिक, मेमोरी से जुड़ी खामी के संकेत 2024 के एक ऑडिट में सामने आए थे, लेकिन पैच महीनों तक अटका रहा। फाउंडेशन ने इस देरी को “संरचनात्मक विफलता” कहा। शोधकर्ताओं का कहना है कि AI मॉडल की मदद से दशक पुरानी इन खामियों को करीब एक हफ्ते में काम करने वाले हमलों में बदला जा सका।

इस पैच को जारी करने से पहले PHP को सुरक्षा ऑडिट, महीनों के गतिरोध और एक लीक से गुजरना पड़ा। साझा होस्टिंग पर चलने वाली साइट के लिए अब आखिरी कदम है—सपोर्ट टिकट दर्ज करना।

टैग: Cloudflare, PHP, PHP2Shell, WordPress, सुरक्षा खामियां