लेखक: 
Research update: 30 October 2026. CERT-In ने 22 अक्टूबर 2026 को advisory CIAD-2026-0052 जारी करके भारत के MSMEs को PHP2Shell नाम से चर्चित दो critical PHP vulnerabilities के प्रति आगाह किया। CVE-2026-109618 और CVE-2026-109619 के कारण प्रभावित servers पर बिना login किए भी attacker का arbitrary code execute हो सकता है। PHP WordPress, कई e-commerce websites और custom business portals के पीछे चलने वाला runtime है। इसलिए केवल WordPress plugin updates देखकर website सुरक्षित घोषित नहीं करनी चाहिए।
सबसे पहले क्या करें: Hosting control panel या administrator से live web PHP version verify करें, supported fixed release पर urgently update करें, web worker services restart करें, फिर logs और recent files review करें। Fixed versions हैं 8.5.12, 8.4.27, 8.3.36 और 8.2.35—या vendor का verified security-fixed package। CERT-In page पर 8.2 affected-version line में छोटा typo दिखता है; उसकी own remediation section और PHP project’s 21 October security release में 8.2.35 स्पष्ट है। Original CERT-In advisory पढ़ें।
PHP2Shell क्या है और attack कहाँ होता है
PHP2Shell PHP interpreter के भीतर memory handling तथा request-resource control से जुड़ी vulnerabilities का popular name है। Web request से dynamic pages बनने के समय affected PHP runtime process data संभालता है। CERT-In के मुताबिक विशेष रूप से तैयार request unauthenticated remote code execution का अवसर दे सकती है। इस बात का मतलब है कि समस्या केवल किसी एक vulnerable WordPress plugin की नहीं; नीचे चल रहा PHP version ही attack surface बन सकता है।
हम जानबूझकर malicious request या exploit chain की recipe नहीं बता रहे हैं। Administrator के लिए relevant सवाल हैं: internet-facing app पर affected runtime है? कोई cloud container पुराने PHP image पर चल रहा है? Web worker reboot के बाद patched binary load हुआ है? अगर application सिर्फ static HTML है और server पर PHP run नहीं होती, उसकी exposure अलग होगी। Risk assessment वास्तविक architecture से शुरू होना चाहिए।
CVE-2026-109618 और CVE-2026-109619 में क्या खास है
PHP Project ने 21 October 2026 release announcements में इन दो CVEs को critical बताया, जिनसे unauthenticated RCE संभव है। CERT-In ने severity Critical रखी और large-scale exploitation reports की चेतावनी दी। Exploitation का outcome privilege तथा deployment के अनुसार बदलता है: attacker website files बदल सकता है, database credentials हासिल कर सकता है या business data तक पहुँचने का रास्ता पा सकता है।
लेकिन पूरे internet पर हर PHP website compromise हो चुकी है, ऐसा किसी official announcement से नहीं निकलता। Vulnerable runtime और confirmed intrusion दो अलग अवस्थाएँ हैं। Affected version मिला तो तुरंत patch priority दें; compromise claim के लिए forensic indicators भी जाँचें। कोई vulnerability identifier अकेला यह नहीं बताता कि आपकी particular site पर attack successful हुआ है।
Affected और fixed PHP versions की सही table
CERT-In तथा PHP Project में version mapping इस प्रकार है: PHP 8.5 series में 8.5.12 या बाद का vendor-fixed update; 8.4 में 8.4.27; 8.3 में 8.3.36; 8.2 में 8.2.35। ये 21 October 2026 के specific fixes हैं—future releases available हों तो उनके security notes भी check करें। 8.1 और older branches upstream unsupported हैं; केवल version number बदल देने के बजाय supported branch migration या authorised vendor backport चाहिए।
PHP 8.2 की upstream end-of-life date 31 December 2026 है। इसलिए 8.2.35 पर patch लेना immediate response हो सकता है, पर 2027 के लिए sustainable lifecycle plan नहीं। Version strings को marketing screenshots के बजाय official PHP release notes, hosting vendor advisories तथा installed environment से match करें।
WordPress administrator को सबसे पहले कहाँ देखना है
WordPress admin में Tools → Site Health → Info → Server के अंतर्गत PHP version दिख सकती है। Managed hosting में PHP version selector तथा subscription details अलग panel में होते हैं। Linux system administrator php -v से CLI version देख सकता है, लेकिन यह जरूरी नहीं कि Apache या PHP-FPM द्वारा requests serve करने वाली PHP binary के समान हो। इसलिए public site का actual configured PHP handler independently verify करें।
अगर एक ही VPS में चार WordPress sites और एक Laravel portal हैं, तो हर virtual host/runtime का inventory अलग निकालें। एक website update करने से दूसरे PHP-FPM pool या Docker container को patch हो जाने का प्रमाण नहीं मिलता। Custom WordPress plugin और third-party themes की compatibility testing ज़रूरी है, पर critical security update को अनिश्चित काल तक टालना जोखिमपूर्ण है।
Hosting provider से कौन-सी पाँच बातें लिखित में पूछें
Shared hosting पर root server upgrade customer स्वयं नहीं करता। Support से actual PHP web-handler version और patched build timestamp माँगें; security fix vendor backport में included है या नहीं, उसका official reference पूछें; PHP-FPM workers restart किए गए या नहीं, confirm कराएँ; पुराने runtime का fallback/alternate selector है या नहीं देखें; और backup तथा restore process की स्थिति जानें।
कई providers application-level dashboard में एक version दिखाते हैं जबकि background worker अलग container से serve करता है। Strong support response सिर्फ “site secured” नहीं बल्कि installed version या patched package identifier देता है। यदि panel outdated version allow करता है तो उसे default option से हटाने की vendor policy समझें। Support ticket में private passwords लिखने की आवश्यकता नहीं।
PHP 8.1 और उससे पहले वाली sites का plan
कई पुराने CMS, custom ERP या payment portal PHP 7.4/8.0/8.1 पर ही निर्भर हैं। CERT-In advisory स्पष्ट कहती है कि 8.1 और earlier PHP branches upstream supported नहीं हैं। उन पर 21 October fixed build की simple patch path उपलब्ध नहीं होगी; supported modern branch में code migration, dependencies update और vendor security-fixed distribution पर विचार जरूरी है।
Business continuity के लिए sandbox/staging copy पर plugin/theme tests और database compatibility validate करें। Legacy portal तुरंत migrate न हो सके तो internet-facing access कम करें और compensating controls रखें, मगर इन्हें permanent fix न कहें। पुराने portal को VPN और IP allowlist से सीमित करना exposure घटा सकता है; अंदर के trusted network में भी software security updates की आवश्यकता बनी रहती है।
Patch deployment से पहले backup और staging checks
Site owner पहले encrypted database और wp-content files का tested backup बनाए। Backups को उस server से logically अलग रखें जहाँ attack हो सकता है। फिर staging पर current PHP version से target patched version में upgrade test करें: homepage, contact form, login, checkout, media upload, cron jobs, emails, payments तथा API endpoints। Critical paths verified हों तो change window चुनकर production update लागू करें।
Urgent patching के समय rollback plan उपयोगी है लेकिन rollback के नाम पर vulnerable runtime को फिर internet पर expose करना सुरक्षित समाधान नहीं। Failure होने पर trusted maintenance mode, temporary isolation और vendor fix के साथ recovery बेहतर है। किसी unchecked third-party PHP binary को random forum से डाउनलोड करके install न करें।
PHP-FPM, Apache और workers restart करना क्यों जरूरी
Package manager या hosting panel updated build install कर दे, फिर भी long-running PHP workers memory में पुरानी binaries या libraries use कर सकते हैं। CERT-In recommendation है कि जरूरत के अनुसार services restart करके verify करें कि update वास्तव में active है। Deployment design के अनुसार PHP-FPM pool restart, webserver reload या container recreation हो सकता है। इनमें कौन-सा step appropriate है, hosted stack का administrator तय करेगा।
Restart के बाद runtime version, uptime, error logs तथा site health जाँचें। Proxy cache से पुराना response मिलने पर runtime check करना मुश्किल हो सकता है। CLI command की output को web-facing runtime का independent proof न मानें। Business owner को अंतिम confirmation चाहिए कि actual user traffic fixed build से serve हो रहा है।
WAF और CDN अकेले protection क्यों नहीं
Web Application Firewall suspicious HTTP patterns block कर सकती है और CDN rate limiting तथा threat intelligence जोड़ सकता है। पर PHP Project ने इन CVEs के लिए “no complete mitigations” की चेतावनी दी है; updating ही safe choice है। इसलिए सिर्फ WAF enable करके affected interpreter पर site चलती रहने देना acceptable long-term solution नहीं।
यदि patch deployment कुछ घंटों तक impossible है तो authenticated access, IP restrictions, emergency maintenance mode या protected network से exposure reduce करें। WAF log anomalies useful detection evidence दे सकते हैं, मगर attacker techniques बदलती हैं। WAF protection, runtime patching, least privilege तथा backup मिलकर defence-in-depth बनाते हैं; कोई एक layer risk शून्य नहीं करती।
Attack के बाद किन संकेतों की जाँच करनी चाहिए
CERT-In suspicious web-server/application requests, unexplained file modifications, new administrator accounts, unusual processes तथा unexplained outbound network connections review करने की सलाह देती है। WordPress में unknown administrator, plugin file में unexpected code, new scheduled task या hosting account में modified web shell-like files की investigation करें। Logs का exact time zone, source IP तथा request path सुरक्षित रखें।
हर new file intrusion का प्रमाण नहीं; legitimate deployment, backup restore या cache generation भी ऐसा दिख सकते हैं। Baseline और version-control comparison से evidence strengthen करें। अगर compromise suspect है तो clean host से credentials rotate और incident-response specialist से scope review कराएँ; सिर्फ WordPress password बदलकर affected server को safe घोषित नहीं किया जा सकता।
Small business के लिए real-world scenario
मान लें hypothetical bakery की WordPress website contact orders तथा payment enquiry लेती है। Hosting account के panel पर PHP 8.4.26 दिखता है, जबकि fixed 8.4.27 है। Owner website developer से backup बनवाता है, staging compatibility test करता है, hosting पर update लागू कराता है और active PHP-FPM version verify करता है। फिर recent admin account list तथा server access logs जाँचता है।
यदि unknown access या suspicious file मिलती है तो owner incident response में website temporarily isolate, evidence preserve और relevant credentials rotate कराता है। इस case का मतलब यह नहीं कि ऐसी हर bakery hacked है; version information remediation trigger है, intrusion proof नहीं। Customers को notification देने का निर्णय confirmed data impact तथा applicable reporting requirements पर आधारित होना चाहिए।
E-commerce और school ERP जैसे portals की priority
Online shops और educational ERP systems कभी contact information, order histories, receipts और application data store करते हैं। ऐसे portals के internet-facing PHP runtime में critical RCE risk है तो patch priority high होगी। Business owner को technical team से live environment, exposed subdomains, separate admin panel, staging host तथा backup server सभी का inventory लेना चाहिए। सिर्फ homepage accessible होना backend सुरक्षित होने का proof नहीं।
Security controls में restricted database permissions, secrets को repository से अलग रखना, minimal admin roles और account MFA जरूरी हैं। अगर service provider third-party software manage करता है तो contractual response और patch confirmation document करें। Financial/education datasets की sensitivity incident handling urgency बढ़ा सकती है; vulnerability देखकर personal information leak हुई है, ऐसा बिना evidence claim न करें।
Unsupported plugin और vulnerable PHP में फर्क
WordPress में plugin bug, weak password और PHP runtime bug अलग vulnerability classes हैं। PHP2Shell interpreter-level vulnerabilities के लिए WordPress core/plugin update पर्याप्त नहीं, जैसा कि plugin की flaw के लिए PHP update अकेला पर्याप्त नहीं। सुरक्षित maintenance workflow दोनों पर नजर रखता है: PHP branch + core + active theme + extensions + server OS dependencies + firewall + backups।
यदि website में कोई outdated plugin है तो उसे patch/remove करें, लेकिन इसे PHP2Shell के root cause के रूप में गलत label न करें। Website security audit में “runtime patched” और “application scanned” दो independent fields रखें। इससे administrator exact changes verify कर सकेगा और compliance reporting अधिक reliable बनेगी।
CERT-In को incident report कब और कैसे करें
22 October advisory में suspicious activity दिखने पर logs preserve, incident contain और available evidence के साथ incident@cert-in.org.in पर report करने को कहा गया है। CERT-In Directions के तहत covered entities की reporting deadlines तथा log-retention duties हो सकती हैं; actual incident category और applicable requirements official Directions से समझें। Incident reporting को hypothetical worry भेजने और confirmed security events के लिए formal notification में फर्क होता है।
Security team timeline, observed artifacts, impacted IP/domain, remediation status तथा contact person रखे। Credentials, private customer records या exploit samples को untrusted email threads में बिखेरना उचित नहीं; authorised secure submission paths की पुष्टि करें। Cyber incident पर bank/customer/legal reporting obligations अलग भी हो सकती हैं।
MSME की 24-hour remediation checklist
पहले asset owner assign करें और सभी publicly reachable PHP endpoints list बनाएं। दूसरा active PHP version व hosting vendor के fixes confirm करें। तीसरा critical sites का verified backup तथा change plan बनाएं। चौथा supported patch deploy और workers restart करें। पाँचवाँ login, website forms, checkout और payment integrations smoke-test करें। छठा recent web/auth logs और administrator accounts investigate करें। सातवाँ confirmed exposure पर incident response तथा credential rotation trigger करें।
यह actionable checklist है, हर organisation के लिए guaranteed 24-hour complete remediation promise नहीं। Multi-tenant enterprise environments, legacy applications और forensic incidents अधिक समय ले सकते हैं। Priority “patch verified + intrusion review” होनी चाहिए, केवल advisory forwarding या policy PDF बनाना नहीं।
PHP2Shell का SEO और revenue पर असर
Site compromise होने पर attacker SEO spam, unwanted redirects, fake investment landing pages या injected JavaScript जोड़ सकता है। इससे Google Search indexing, customer trust तथा advertising eligibility प्रभावित हो सकती है। इसलिए vulnerability incident के बाद security restore होने के साथ published article templates, sitemap URLs, modified admin pages तथा Search Console unusual pages भी review करें। SEO cleanup affected webroot की clean recovery के बाद करें, क्योंकि infected server पर superficial rewrite फिर compromise हो सकता है।
अगर Search Console में unknown indexed pages दिखें तो crawl issue और actual malicious files का evidence अलग रखें। हर sudden rank drop attack का प्रमाण नहीं, मगर suspicious redirects के साथ version exposure investigation को priority दें। Website administrator को security और SEO monitoring silos में नहीं बाँटना चाहिए।
FAQs — CERT-In PHP2Shell Advisory 2026
Advisory कब जारी हुई? 22 October 2026, CIAD-2026-0052।
कौन-से CVEs हैं? CVE-2026-109618 तथा CVE-2026-109619।
कौन-से PHP versions fixed हैं? 8.5.12, 8.4.27, 8.3.36 और 8.2.35, या equivalent vendor-fixed packages।
क्या WordPress website affected हो सकती है? अगर उसका actual PHP runtime affected build use करता है, तो risk है; WordPress होना अकेले compromise proof नहीं।
क्या plugin update पर्याप्त है? नहीं, interpreter-level PHP fix अलग चाहिए।
क्या WAF पूरी तरह सुरक्षित बना देती है? नहीं, PHP official security release के अनुसार patching आवश्यक है।
क्या PHP 8.1 के लिए same fixed release है? नहीं, unsupported branch को supported version या verified vendor backport चाहिए।
क्या php -v server version verify करता है? CLI version दिखाता है; web-facing PHP-FPM/Apache environment अलग हो सकता है।
Attack का शक हो तो क्या करें? Evidence preserve, containment, trusted recovery और CERT-In reporting।
Official sources और related guides
- CERT-In CIAD-2026-0052 — 22 October 2026 PHP2Shell advisory
- PHP Project — 21 October 2026 critical security updates and fixed branches
- CERT-In — Current 2026 advisories
- Nexeons — DNSSEC, HTTPS and website protection layers
- Nexeons — Zero Trust security basics
- Nexeons — MCP Server Security and access permission checks
Editorial notice: यह defensive security education article है। Nexeons ने किसी specific business server का PHP version या compromise manually test करने का दावा नहीं किया। Exact runtime upgrade steps आपके hosting vendor और application compatibility पर निर्भर होंगे।
इस विषय पर आगे क्या पढ़ें?
इस खबर से जुड़े विषयों को आसान भाषा में और गहराई से समझें।
