PHP2Shell: PHP की कमजोरी जो Headless जाने की बात करती है

21 अक्टूबर को डच national cyber security centre ने अपनी खुद की वेबसाइट को offline ले लिया। WordPress को hack किए जाने के कारण नहीं, बल्कि क्योंकि इसके नीचे PHP interpreter को hack किया जा सकता था।

उस दिन PHP project ने interpreter में दो unauthenticated remote code execution bugs के लिए fixes ship किए, CVE-2026-109618 और CVE-2026-109619। कोई भी साइट जहाँ PHP ने public requests का उत्तर दिया वह patch करना पड़ा या offline जाना पड़ा। साइटें जो CDN से static HTML serve करती थीं उन के पास request path में PHP process नहीं था, इसलिए edge पर patch करने के लिए कुछ नहीं था। Headless WordPress को अभी भी अपने backend को update करना था, लेकिन public साइट ऊपर रही। नीचे: timeline, architectural argument, stack के द्वारा decision table, एक 30/60/90-day plan, और एक checklist अगर आप अभी के लिए PHP पर रह रहे हैं।

अगर आप PHP चलाते हैं, यह आज करो।

• पुष्टि करें कि चलने वाला version 8.5.12, 8.4.27, 8.3.36 या 8.2.35 है, या एक vendor backport जिसकी notice आपने पढ़ी है, और हर worker को restart करें।
• जाँचें कि आपके hosting control panel ने वास्तव में क्या ship किया, dashboard क्या कहता है इससे नहीं।
• PHP के ini mitigations और किसी भी WAF rule को patch तक एक bridge के रूप में treat करें, इसके substitute के रूप में नहीं।
• 7.4 से 8.1 पर, अपने host से पूछें कि क्या उसने security team के source backports को build किया, और किसी भी तरह upgrade book करें।

21 अक्टूबर 2026 को क्या हुआ

Timeline इसलिए मायने रखता है क्योंकि यह panic को समझाता है। Tenable के अनुसार, CVE identifiers 20 अक्टूबर को Hacker News और social media पर circulate हुए। उसी दिन बाद में PHP security team ने 21 अक्टूबर को 14:00 UTC के लिए एक release का advance notice प्रकाशित किया, कहा कि अगर details public हो जाएं तो यह पहले ship हो सकता है। Tenable ने यह भी report किया, watchTowr का हवाला देते हुए, कि disclosure मूल रूप से 22 अक्टूबर को embargo के तहत set था।

PHP security team ने फिर 21 अक्टूबर को अपनी advisory प्रकाशित की, जिसका शीर्षक था "Security advisory: Critical remote code execution vulnerabilities, update now" (php.net news archive)। ENISA joint statement updates को 13:40 UTC पर रखता है। Fixed versions हैं PHP 8.5.12, 8.4.27, 8.3.36 और 8.2.35।

दोनों bugs, GitHub advisories से:

• CVE-2026-109618: out-of-memory corruption के through remote code execution।
• CVE-2026-109619: stale global state के through remote code execution, एक use-after-free जो same worker को handle करने वाले requests के बीच होता है।

PHP security team दोनों को CVSS v4.0 9.2 rate करता है। Tenable नोट करता है कि कुछ early reports, watchTowr और एक Hacker News post सहित, 10.0 कहते थे। हर web-serving SAPI scope में है: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP और LiteSpeed। OOM advisory mod_php को सबसे ज्यादा exposed बताता है, क्योंकि failure बिल्कुल किसी application code के चलने से पहले होता है। Calif कहते हैं कि earliest affected code path PHP 5.4.0 तक जाता है। Discovery का credit Wiz, Calif और OpenAI को जाता है, AI-assisted research के साथ।

फिर outages हुई। Reuters और RTE ने Netherlands, Finland, France और Australia में government services को ऑफलाइन होने की report दी, Dutch national cyber security centre की अपनी साइट सहित। CERT-EU ने internet-facing applications को patch होने तक isolate करने की सिफारिश की, और CISA ने immediate patching की अपील की। Krebs reports कि Cloudflare ने 3:02 am UTC पर WAF rules deploy किए। Amazon Threat Intelligence कहता है कि उसने 17 अक्टूबर को एक attempt देखा और बाद में exploitation को broad बताया।

Exploitation पर, sources असहमत हैं, और आपको यह जानना चाहिए। PHP Foundation ने कहा कि release के समय उसने functional exploits identify नहीं किए थे। Krebs reports कि experts कह रहे हैं कि working exploits exist करते हैं। Tenable ने कहा कि bugs को exploit करने का दावा करने वाला code circulate हो रहा था लेकिन उसने इसे verify नहीं किया था।

क्यों सलाह patch करो या ऑफलाइन जाओ थी

Request path में unauthenticated remote code execution का मतलब web server target है। इसके सामने कोई login नहीं है, disable करने के लिए कोई plugin नहीं। एक request आता है, PHP इसे parse करता है, और bug पहले से ही play में है। OOM advisory impact को unauthenticated code execution के रूप में confirm करता है जो web worker account के रूप में होता है, HTTP के खिलाफ mod_php के साथ default input और memory limits के साथ validate किया जाता है।

जो mitigations PHP ने listed किए हैं वे real हैं, और वे stopgaps हैं। Advisories कहती हैं:

• memory_limit=-1 को administratively set करें (php_admin_value के माध्यम से), post_max_size को conservative रखें, और अगर आप उन का use नहीं करते तो multipart requests को frontend पर block करें।
• session.upload_progress.enabled=0 set करें।
• PHP 8.5 पर, fatal_error_backtraces=0 set करें।
• किसी भी इनमें से अपडेट के बाद हर worker को फिर से शुरू करें।

वही सलाह स्पष्ट है कि अपडेट करना ही एकमात्र पूर्ण समाधान है। stale-state bug के लिए कोई पूर्ण सामान्य कॉन्फ़िगरेशन कम करना भी नहीं है। PHP core developer Gina Peter Banyard, Tenable द्वारा उद्धृत, ने कहा कि एकमात्र समाधान PHP को patch करना या अपग्रेड करना है, और PHP 8.6 release manager Joe Ferguson ने कहा कि ini settings आपको बचा नहीं सकते। तो इस सूची को एक दोपहर भर का पुल मानें, कोई स्थायी रुख नहीं।

दो व्यावहारिक परेशानियों ने दिन को version bump से कहीं कठिन बना दिया। Shared hosting और control panels अपने अनुसूची पर PHP packages भेजते हैं, तो version जो आप सोचते हैं वह चल रहा है वह चलने वाला version नहीं हो सकता। Plesk ने अपने PHP के लिए अपनी खुद की सूचना प्रकाशित की, जो उस तरह का पृष्ठ है जिसे आपको पढ़ना चाहिए मान लेना नहीं।

और फिर पुरानी शाखाएं। php.net advisory कहती है कि PHP 8.1 और इससे पुरानी versions को प्रोजेक्ट से अब अपडेट नहीं मिलते, और यह distributions और LTS vendors को backports के लिए point करती है। सुरक्षा टीम ने GitHub पर 7.4, 8.0 और 8.1 के लिए minimal source-backport branches प्रकाशित किए हैं, लेकिन एक source patch एक release नहीं है: किसी को अभी भी इसे build करना और अपने host को भेजना है। PHP 5.4 से 7.3 को कुछ नहीं मिलता। अगर आपने कभी upgrade नहीं किया, तो वह आपका 21 अक्टूबर था।

पैमाने पर कुछ संख्याएँ। W3Techs दिखाता है कि PHP 22 अक्टूबर तक एक ज्ञात server-side language वाली websites के 69.3% पर है, जिनमें से 65.3% version 8 पर, 26.9% version 7 पर और 7.7% version 5 पर हैं। Censys 2.58 मिलियन internet-facing hosts और PHP चलाने वाली 54.9 मिलियन web properties गिनता है। यह restart करने के लिए बहुत सारे workers हैं।

जिनके पास 21 अक्टूबर को करने के लिए कुछ नहीं था

यहाँ request-path terms में exposure है। किसी भी site से एक सवाल पूछें: जब कोई visitor एक page load करता है, तो क्या code उन्हें जवाब देने के लिए चलता है?

CDN पर Static HTML

अगर उत्तर है "कुछ नहीं, CDN एक file return करता है", तो PHP2Shell public site को नहीं छूता। कोई PHP process requests का जवाब नहीं देता, तो edge पर patch करने के लिए कुछ नहीं है और कुछ भी offline लेने के लिए कोई कारण नहीं है। मैं gautamkhorana.com को Astro पर static output के साथ चलाता हूँ। HostList, जिसे मैंने Next.js और Supabase पर लगभग 28,000 programmatic pages के साथ बनाया है, को patch करने के लिए कोई PHP process नहीं था। Deluxe Astrology को भी नहीं, जो 30 languages में 91,000+ pages चलाता है। किसी को 21 अक्टूबर को call नहीं आई।

Headless WordPress

Headless एक अलग कहानी है, और मैं सुविधाजनक से ज्यादा सटीक होना पसंद करता हूँ। PHP backend को अभी भी 8.5.12, 8.4.27, 8.3.36 या 8.2.35 की जरूरत थी उस दिन, क्योंकि WordPress अभी भी PHP पर चलता है। अंतर यह है कि यह कहाँ बैठता है। एक firewall या एक IP allowlist के पीछे, public site को Astro या Next.js द्वारा serve किया जाता है, backend एक visitor के request के path में नहीं था। patch एक maintenance task था, कोई public outage नहीं।

इसे सीधे कहें: यह "headless unhackable है" नहीं है। एक attacker जो backend तक पहुँच सकता है वह अभी भी bug तक पहुँच सकता है, जो यह है कि allowlist क्यों महत्वपूर्ण है। SSR frameworks के अपने server-runtime risks हैं, Next.js, Astro और Nuxt security piece में cover किया हुआ, और व्यापक comparison headless vs WordPress security में रहता है। मैं यहाँ दोनों को दोहराऊँगा नहीं।

एक pattern, एक one-off नहीं

यह पहली बार नहीं था जब PHP का request path headlines में आया। PHP-CGI argument injection, CVE-2024-4577, 2024 में आई। 2012 में एक पुरानी PHP-CGI bug थी। अब PHP2Shell। अलग flaws, same shape: code जो हर public request के सामने बैठता है को hit किया जाता है, और हर कोई downstream scrambles करता है।

अब lesson जो दूसरी तरफ काटता है। React2Shell on Next.js ने दिखाया कि SSR runtimes के अपने request-path exposure होते हैं। अगर एक JavaScript server हर page request का जवाब देता है, तो यह patch करने के लिए नया PHP है। WordPress से एक Next.js server-rendered site पर जाना attack surface को move करता है। यह इसे delete नहीं करता। Static output शक्तिशाली claim है; SSR एक trade है।

तो सवाल कभी "कौन सी language" नहीं था। यह है "क्या code एक public request का जवाब देता है"। उस सूची को काटें और आपके incident days कुछ भी छोटे हो जाते हैं अगले CVE जो भी language में लिखा हो।

एक आगे की ओर pointing पहलू भी है। Wiz researchers ने लिखा कि flaws decades से present थीं, कि उन्हें exploit करना "कि human researchers practically achieve कर सकते हैं उसके edge पर" steps की एक chain थी, और "frontier AI models ने उस barrier को substantially reduce किया" (Krebs)। implication, जो मेरा है न कि उनका: अगर old flaws को exploits में turn करना सस्ता हो जाता है, तो disclosure cadence हर runtime के लिए ऊपर जाता है। इस तरह के ज्यादा दिनों के लिए plan करें, कम के लिए नहीं।

21 अक्टूबर को आपके stack के हिसाब से क्या cost हुआ

Classic WordPress या अन्य PHP CMS। Drupal, Magento, Joomla और WordPress सभी PHP पर चलते हैं, और Calif रिपोर्ट करता है कि इन सभी चारों के specific versions के विरुद्ध pre-authentication remote code execution की पुष्टि हुई है, Tenable के FAQ के अनुसार। इस row ने पूरे दिन की लागत ले ली।

Headless WordPress। आपने पैच किया, लेकिन अपनी शेड्यूल पर और फायरवॉल के पीछे। एडिटर्स एडिट करते रहे। विजिटर्स को कुछ नहीं दिखा।

Laravel या कस्टम PHP। क्लासिक CMS जैसा ही एक्सपोजर, एक मोड़ के साथ: आपके कस्टम ऐप के लिए कोई प्रोडक्ट एडवाइजरी प्रकाशित नहीं करता, इसलिए आप इन्वेंटरी के मालिक हैं। NCSC-NL का php2shell रिपॉजिटरी कहता है कि कस्टम PHP एप्लिकेशन इसके ओवरव्यू में रजिस्टर नहीं हैं।

Static Jamstack। एज पर कुछ नहीं करना। अगर आपका बिल्ड CI बॉक्स पर चलता है, तो इसे जब सुविधाजनक हो पैच करें, क्योंकि यह विजिटर्स को सर्व नहीं कर रहा है।

SSR with Next.js या Nuxt। कोई PHP नहीं, कोई PHP2Shell नहीं। लेकिन एक सर्वर प्रोसेस अभी भी रिक्वेस्ट का जवाब देता है, और React2Shell इस बात की याद दिलाता है कि इस प्रोसेस के भी बुरे दिन होते हैं।

30/60/90-दिन की योजना

लक्ष्य एडिटिंग एक्सपीरिएंस को दोबारा बनाए बिना PHP को पब्लिक सर्फेस से निकालना है।

1. 30वें दिन तक: अपने पेज टाइप (पोस्ट, लैंडिंग पेज, प्रोडक्ट पेज, आर्काइव) की सूची बनाएँ और चिह्नित करें कि कौन से सच में प्रति-रिक्वेस्ट लॉजिक की जरूरत है। हर होस्ट पर PHP वर्जन की पुष्टि करें। ओरिजिन के सामने एक CDN लगाएँ और एडमिन को एक अनुमति सूची तक सीमित करें।
2. 60वें दिन तक: एक या दो सबसे अधिक ट्रैफिक वाले स्टेटिक पेज टाइप के लिए Astro या Next.js फ्रंट एंड सेट अप करें, WordPress कंटेंट API से बनाया गया। प्रकाशन पर एक बिल्ड ट्रिगर करें। हर URL के लिए 301 रीडायरेक्ट जोड़ें जिसे आप ले जा रहे हैं।
3. 90वें दिन तक: शेष पेज टाइप को माइग्रेट करें जो स्टेटिक हो सकते हैं। PHP ओरिजिन को पब्लिक ट्रैफिक के लिए बंद करें ताकि केवल बिल्ड प्रोसेस और आपकी अनुमति सूची वाले एडिटर्स इसतक पहुँचें। जो कुछ सच में सर्वर की जरूरत है (सर्च, फॉर्म, खाते) एक छोटी, नामित सेवा में जाता है जिसे आप अपने दम पर पैच कर सकते हैं।

CMS को खोए बिना PHP को पब्लिक सर्फेस से निकालना

PHP को रिक्वेस्ट पाथ से निकालने के लिए आपको WordPress को फेंकना जरूरी नहीं है। Headless WordPress एडिटर्स, कंटेंट और राइटिंग और अनुमोदन के लिए प्लगइन वर्कफ्लो रखता है, जबकि Astro या Next.js साइट को सर्व करता है। एडिटर्स उस स्क्रीन को रखते हैं जिसे वे जानते हैं। विजिटर्स CDN से फाइलें पाते हैं।

धीरे-धीरे माइग्रेट करें। एक पेज टाइप चुनें, इसे नए फ्रंट एंड पर दोबारा बनाएँ, पुराने URLs को 301 करें, और आगे बढ़ें। एडमिन PHP में रहता है, एक अनुमति सूची के पीछे। होस्टिंग पैटर्न सरल है: ओरिजिन लॉक डाउन, सामने CDN, प्रकाशन पर बिल्ड।

फ्रेमवर्क चुनाव पर: कंटेंट साइट्स के लिए Astro, जब साइट को एप्लिकेशन लेयर की जरूरत हो तो Next.js, Vue टीमों के लिए Nuxt। गहरे ट्रेड-ऑफ स्टेटिक साइट जेनरेटर तुलना और headless WordPress गाइड में हैं।

प्रयास पर, केवल शुरुआती कीमतों का उपयोग करते हुए: WordPress से Astro माइग्रेशन $7k से है, headless WordPress विकास $10k से है, और एक लीगेसी CMS माइग्रेशन $5k से शुरू होता है। अगर साइट को एप्लिकेशन लेयर की जरूरत है, तो WordPress से Next.js माइग्रेशन $10k से जो रूट फिट करता है वह है। ये शुरुआती बिंदु हैं, और असली आंकड़ा पेज टाइप, इंटीग्रेशन और आप कितना एडिटिंग वर्कफ्लो संरक्षित करना चाहते हैं इस पर निर्भर करता है। अगर आप PHP को पूरी तरह से छोड़ने के बारे में सोच रहे हैं, तो leave-WordPress पेज उस पाथ को कवर करता है।

इसे शुरू करने के लिए सबसे सस्ता दिन एडवाइजरी के बाद वाला दिन नहीं है। लेकिन एडवाइजरी के बाद वाला दिन वह है जब बजट को मंजूरी दी जाती है, इसलिए इसका उपयोग करें।

अगर आप फिलहाल PHP पर बने रहना चाहते हैं

कुछ साइटें एक या तीन साल के लिए जहाँ की तहाँ रहेंगी। ठीक है। इस बीच यह करें:

1. पुष्टि करें कि चल रहा PHP संस्करण 8.5.12, 8.4.27, 8.3.36 या 8.2.35 है (या कोई vendor backport जिसके लिए आपने नोटिस पढ़ा हो), और हर worker रीस्टार्ट हुआ हो। एक package upgrade जो पुरानी workers को चलने देता है, कुछ ठीक नहीं किया है।
2. जाँचें कि आपका hosting control panel वास्तव में क्या भेज रहा है, डैशबोर्ड क्या कहता है इसके बजाय।
3. PHP की listed mitigations को केवल एक bridge के रूप में लागू करें। advisories कहती हैं कि वे एक installation को सुरक्षित नहीं बनाते, और OOM advisory RLIMIT_AS और RLIMIT_DATA के विरुद्ध चेतावनी देती है, जो vulnerable path को trigger करते हैं।
4. 7.4 से 8.1 तक के exit की अभी से योजना बनाएँ। PHP project अब 8.1 और पुराने को अपडेट नहीं करता, और आप किसी और के backport पर निर्भर हैं।
5. जब आप patch करें तो साइट को WAF के पीछे रखें। Cloudflare CTO Dane Knecht ने इसके नियमों को "केवल एक STOPGAP" कहा, और Tenable नोट करते हैं कि ये केवल Cloudflare के माध्यम से routed ट्रैफिक को कवर करते हैं।
6. web shells और PHP files को देखें जो वहाँ नहीं होनी चाहिएँ। Wiz mass exploitation की उम्मीद करता है इन्हें इंस्टॉल करने की, तो upload directories और हाल ही में modified files को जाँचें।

उन साइटों के लिए जो WordPress पर बनी रहेंगी, $150/महीना से WordPress security care चल रहे patching और monitoring को कवर करता है।

21 अक्टूबर का सबसे महत्वपूर्ण तथ्य यह है कि बग उस एक जगह में था जहां हर PHP विज़िटर को जाना पड़ता है, इसलिए जिन साइटों को कुछ करना नहीं था वे केवल वे थीं जहां PHP ने कभी public request का जवाब नहीं दिया। Static output इस दावे का मजबूत संस्करण है; headless WordPress को अभी भी अपने backend को patch करने की जरूरत थी, और SSR सिर्फ एक runtime को दूसरे से बदल देता है।

FAQ

क्या WordPress PHP2Shell से प्रभावित है?

WordPress ही bug नहीं है। flaws PHP में हैं, और WordPress PHP पर चलता है, इसलिए unpatched PHP पर कोई भी WordPress site exposed था। Tenable का FAQ, Calif को citing करते हुए, specific WordPress versions के विरुद्ध pre-authentication remote code execution की पुष्टि करता है, जो सवाल को settle करता है।

क्या headless WordPress को अभी भी patch की जरूरत है?

हाँ। backend PHP चलाता है, और एक attacker जो इस तक पहुँच सकता है वह bug तक पहुँच सकता है। headless जो बदलता है वह है exposure: backend एक firewall या allowlist के पीछे बैठ सकता है जबकि एक अलग front end जनता को serve करता है।

क्या Next.js या Astro साइट PHP से ज्यादा सुरक्षित है?

दोनों से static output इस तरह के bug के विरुद्ध ज्यादा सुरक्षित है, क्योंकि कोई server-side runtime requests का जवाब नहीं देता। SSR एक trade-off है: आप PHP को JavaScript server runtime से swap करते हैं जिसकी अपनी advisories हैं, जैसे React2Shell दिखाया।

क्या WAF मुझे बचाता है?

आंशिक रूप से, और केवल कुछ समय के लिए। Cloudflare ने इसके नियमों को stopgap कहा और ये केवल Cloudflare के माध्यम से traffic को कवर करते हैं। एक WAF आपको patch करने का समय देता है। यह एक patch नहीं है।

क्या मुझे अपनी साइट offline ले जानी चाहिए?

CERT-EU ने internet-facing applications के isolation पर विचार करने की सिफारिश की जब तक fix available न हो, और ENISA का joint statement वही कहता है जहाँ immediate remediation feasible नहीं है। अगर आप जल्दी patch कर सकते हैं, patch करें। अगर नहीं कर सकते, तो isolation एक reasonable call है।

कौन से PHP versions fixed हैं?

PHP 8.5.12, 8.4.27, 8.3.36 और 8.2.35, PHP advisories के अनुसार।

क्या PHP 7.4, 8.0 और 8.1 patched हैं?

releases के साथ नहीं। php.net advisory कहती है कि 8.1 और पुरानी versions को PHP project से अब अपडेट नहीं मिलते, और सुरक्षा टीम ने इसके बजाय 7.4, 8.0 और 8.1 के लिए minimal source-backport branches प्रकाशित किए हैं। अपने host या distribution से पूछें कि क्या उसने उन्हें build किया; किसी भी तरह से, upgrade की planning करें।