PHP2Shell क्या है? CVE-2026-109618 और CVE-2026-109619 से WordPress Site कैसे बचाएं

PHP2Shell नाम से चर्चा में आई दो critical vulnerabilities — CVE-2026-109618 और CVE-2026-109619 — सीधे PHP runtime के अंदर हैं, किसी plugin या theme में नहीं। इसका मतलब है कि अगर आपकी WordPress, Joomla, Drupal, Magento या कोई custom PHP website unpatched PHP पर चल रही है, तो वह खतरे में हो सकती है।

PHP team ने 21 October 2026 को official security advisory जारी करके सभी users को तुरंत update करने को कहा है। Advisory के अनुसार ये flaws बिना login के remote code execution (RCE) तक ले जा सकते हैं, और Apache mod_php पर एक exploit demonstrate भी किया गया है। इसलिए यह “बाद में देखेंगे” वाला update नहीं है।

PHP2Shell क्या है? CVE-2026-109618 और CVE-2026-109619 आसान भाषा में

PHP2Shell कोई एक bug नहीं, बल्कि PHP runtime की दो memory-safety vulnerabilities का nickname है। Official advisory के अनुसार दोनों में attacker को login की ज़रूरत नहीं पड़ती।

CVE-2026-109618: RCE via OOM corruption

PHP Out-of-Memory (OOM) error आने पर longjmp() से request को बीच में ही abort कर देता है। कुछ जगहों पर request की memory पूरी तरह initialize होने से पहले ही reachable हो जाती है।

अगर ठीक उसी समय कोई भी allocation fail हो जाए, तो memory invalid state में रह जाती है, और request shutdown के दौरान PHP उसी invalid data को पढ़ सकता है। Advisory बताती है कि multipart request parsing के कुछ तरीकों से OOM लगातार trigger किया जा सकता है। Source: GHSA-w8hw-w9fx-j79w

CVE-2026-109619: RCE via stale global state

PHP worker के पास कुछ global state (error, session, object, extension state) होती है, जो थोड़े समय के लिए एक request की memory की तरफ point करती है। Request खत्म होने से पहले इसे reset होना चाहिए।

Fatal error, OOM या execution timeout जैसी रुकावट से यह reset छूट सकता है। फिर request memory free हो जाती है, लेकिन पुराना reference बचा रहता है। उसी worker पर आने वाली अगली request normal initialization से पहले इस stale state को इस्तेमाल कर सकती है — यह Use-After-Free (CWE-416) है। Source: GHSA-6wmf-4rv5-p3rp

Severity पर नोट: इस article में severity PHP की official GitHub advisories से ली गई है, जहां दोनों CVE को Critical (CVSS v4 9.2) बताया गया है। Linux distributions और दूसरे databases अपने हिसाब से अलग score या priority दिखा सकते हैं, इसलिए अपने vendor का page भी देखें।

कौन-सी PHP Setups खतरे में हैं?

Official advisory के अनुसार web requests serve करने वाली सभी PHP installations प्रभावित हो सकती हैं: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP और LiteSpeed। CLI से चलने वाले scripts इस advisory का मुख्य focus नहीं हैं।

• Apache mod_php: PHP team के अनुसार सबसे ज़्यादा risk। यहां बिना login वाली request application code चलने से पहले ही attack trigger कर सकती है।
• PHP-FPM: CVE-2026-109619 का session lifecycle path FPM पर validated है। CVE-2026-109618 के लिए source analysis FPM को susceptible बताता है, हालांकि complete FPM exploit demonstrate नहीं हुआ।
• LiteSpeed (LSAPI) और FrankenPHP: Advisory इन्हें भी likely या conditional candidates मानती है।

Shared hosting पर आप किस SAPI पर हैं, यह hosting company से पूछें या hosting panel में देखें।

PHP2Shell Attack कैसे काम करता है?

नीचे simplified flow है। Steps 1–4 advisories के technical description पर आधारित हैं। नीचे दिए impacts वे संभावित नुकसान हैं जो worker account पर code execution मिलने के बाद हो सकते हैं — हर site पर ये अपने आप नहीं होते।

Advisory के मुताबिक exploit की reliability PHP build, extensions, frontend और memory layout पर निर्भर करती है। लेकिन research में RCE validate हो चुका है, इसलिए patch को टालना सही नहीं है।

WordPress Plugin Update से यह Fix क्यों नहीं होगा?

बहुत से लोग सोचते हैं कि security plugin लगा लिया या WordPress update कर दिया तो site safe है। PHP2Shell में ऐसा नहीं है, क्योंकि bug उस layer में है जो WordPress को चलाती है। WordPress या plugin vulnerabilities अलग चीज़ हैं — उनका fix plugin update से होता है, जबकि इसका fix PHP update से।

WordPress plugins Layer 4 में हैं, जबकि PHP2Shell Layer 3 में है। इसलिए fix भी Layer 3 पर होगा — यानी PHP runtime को patched release या vendor backport पर update करके।

Affected और Fixed PHP Versions की पूरी लिस्ट

नीचे की जानकारी PHP 8 ChangeLog और official advisories से है। “Fixed Version” या उससे नया upstream release patched है:

EOL versions पर नोट: PHP project अब 8.1 और पुराने versions के नए releases नहीं बनाता। Severity को देखते हुए PHP security team ने 7.4, 8.0 और 8.1 के लिए minimal source-backports दिए हैं, लेकिन ये मुख्य रूप से source से build करने वालों के लिए हैं। ज़्यादातर websites के लिए सही रास्ता supported version पर जाना या vendor का backported package लेना है।

PHP 8.6 के pre-release builds चलाने वाले users के लिए fix 8.6.0 RC4 में शामिल है, लेकिन PHP team ने इसे production में इस्तेमाल न करने को कहा है।

Step 1: अपना PHP Version कैसे Check करें?

WordPress Dashboard से

1. WordPress Admin में login करें।
2. Tools → Site Health पर जाएं।
3. ऊपर Info tab पर click करें।
4. Server section खोलें और PHP version नोट करें।

यह वही PHP version है जो आपकी website को चला रहा है। WordPress Site Health docs

SSH / Terminal से (सावधानी के साथ)

php -v

ध्यान दें: यह command सिर्फ CLI PHP का version दिखाता है। Website को चलाने वाला PHP (PHP-FPM, mod_php या LiteSpeed का lsphp) अलग version या अलग package हो सकता है। एक server पर कई PHP versions installed होना आम बात है। FPM का version अलग से check करें (version number अपने setup के अनुसार बदलें):

# Example: Ubuntu/Debian पर PHP 8.3 FPM
php-fpm8.3 -v

# Example: RHEL/AlmaLinux पर
php-fpm -v

Distro package status कैसे देखें?

Package manager से देखें कि कौन-सा package version installed है, फिर उसे vendor के security advisory में दी गई fixed package version से मिलाएं:

# Ubuntu / Debian (example)
apt policy php8.3-fpm
dpkg -l | grep -i php

# RHEL / AlmaLinux / Rocky (example)
rpm -qa | grep -i php

कई vendors changelog में CVE ID लिखते हैं, इसलिए यह optional check भी मदद कर सकता है:

apt changelog php8.3-fpm | grep -E "CVE-2026-10961[89]"
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"

Changelog में CVE न दिखने का मतलब हमेशा vulnerable होना नहीं है — कुछ vendors अलग format इस्तेमाल करते हैं। Final confirmation के लिए vendor advisory ही देखें।

Step 2: Shared Hosting (cPanel / hPanel) पर PHP Update कैसे करें?

Shared hosting पर आप आमतौर पर PHP branch (जैसे 8.3) चुन सकते हैं, लेकिन उस branch का security patch hosting company server पर install करती है। इसलिए दोनों बातें ज़रूरी हैं:

1. cPanel: Software → MultiPHP Manager (या Select PHP Version) खोलें। अगर आप 8.1 या पुराने पर हैं, तो domain के लिए supported branch (जैसे 8.3 या 8.4) चुनें।
2. Hostinger hPanel: Website dashboard में Advanced → PHP Configuration में supported version चुनें। Panel के version के हिसाब से path थोड़ा अलग दिख सकता है।
3. Branch बदलने के बाद WordPress Site Health में exact version फिर से देखें।
4. Version fixed list से नीचे दिखे, तो host से पूछें कि उन्होंने upstream release या backport लगाया है या नहीं (नीचे email template है)।

Shared hosting पर .user.ini या ini_set() से CVE-2026-109619 का mitigation लागू नहीं होता — यह server-level setting है, इसके लिए भी host से बात करें।

Step 3: VPS / Dedicated Server पर PHP Patch करें

नीचे के commands examples हैं, हर server के लिए copy-paste fix नहीं। Package manager सिर्फ वही package install करता है जो आपकी configured repository में उपलब्ध है। Ondřej PPA या Remi जैसे third-party repositories का अपना release schedule होता है।

पहले ये 3 चीज़ें पता करें

1. Backup: Website files और database का ताज़ा backup या server snapshot।
2. SAPI: Site PHP-FPM, Apache mod_php या LiteSpeed (LSAPI) में से किस पर चलती है।
3. Service name: Server पर कौन-सी PHP / web server services चल रही हैं:

   systemctl list-units --type=service | grep -Ei "php|fpm|apache|httpd|lsws|nginx"

Ubuntu / Debian (example: PHP 8.3)

sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
# अगर Apache mod_php इस्तेमाल करते हैं, तो उसका package भी:
# sudo apt install --only-upgrade libapache2-mod-php8.3

RHEL / AlmaLinux / Rocky Linux (example)

sudo dnf upgrade --refresh php php-fpm php-cli php-common

Restart: सिर्फ अपने setup के हिसाब से

Advisory हर PHP worker को restart करने को कहती है। Restart से कुछ सेकंड का interruption हो सकता है, इसलिए busy site पर कम traffic वाले समय में करें। नीचे से सिर्फ वही command चुनें जो आपके setup पर लागू हो:

Restart के बाद website खोलकर देखें, फिर Site Health में version और vendor advisory से package status दोबारा confirm करें।

Docker / Container वाली websites

Host OS update करने से container के अंदर का PHP नहीं बदलता। और सिर्फ docker pull करने से पहले से चल रहा container भी patch नहीं होता। सही तरीका:

1. Dockerfile में ऐसा base image चुनें जो patched PHP release या vendor fix वाला हो। Exact version pin करना साफ रहता है, जैसे FROM php:8.3.36-fpm (official php images)।
2. Image rebuild करें और container redeploy करें:

   # Example (Docker Compose)
   docker compose build --pull --no-cache
   docker compose up -d

3. Deploy होने के बाद चल रहे container में version check करें (service name अपने setup से बदलें):

   docker compose exec app php -v

Kubernetes या दूसरे orchestrators में भी यही नियम है: नया patched image build करें, rollout करें और running pods में version confirm करें।

PHP Update के बाद Website टूट जाए तो क्या करें?

8.1 या पुराने version से 8.3/8.4 पर जाने पर कुछ पुराने plugins या themes में error आ सकता है। Safe तरीके से debug करें:

1. wp-config.php खोलें और पहले देखें कि WP_DEBUG पहले से defined है या नहीं। ज़्यादातर sites में define( 'WP_DEBUG', false ); पहले से होता है — नई line जोड़ने के बजाय उसी को बदलें, ताकि duplicate constant न बने।
2. Errors को visitors से छिपाकर सिर्फ log में भेजें। बेहतर है कि log file web root से बाहर रहे (path अपने server के अनुसार बदलें):

   define( 'WP_DEBUG', true );
   define( 'WP_DEBUG_LOG', '/home/USERNAME/logs/wp-debug.log' );
   define( 'WP_DEBUG_DISPLAY', false );
   @ini_set( 'display_errors', 0 );

   अगर WP_DEBUG_LOG को true रखते हैं, तो log wp-content/debug.log में बनेगा, जो public URL से खुल सकता है — काम खत्म होते ही उसे delete करें। WordPress debugging docs

3. Log में देखें कि error किस plugin या theme से आ रहा है।
4. File Manager या SFTP से /wp-content/plugins/ में उस plugin का folder rename करें। Site वापस खुल जानी चाहिए।
5. उस plugin का updated version install करें या कोई alternative चुनें।
6. काम पूरा होने पर WP_DEBUG को वापस false करें और log file हटा दें।

ध्यान दें: Site चलाने के लिए वापस unpatched या EOL PHP पर जाना सुरक्षित option नहीं है।

Temporary Mitigation: Patch तुरंत न हो पाए तो?

PHP की official advisory साफ कहती है: patched release या vendor का confirmed security backport ही पूरा समाधान है। नीचे के उपाय सिर्फ कुछ known attack paths पर exposure कम करते हैं — ये installation को safe नहीं बनाते। ये settings server-level हैं, इसलिए shared hosting users इन्हें अपने host से लागू करवाएं।

CVE-2026-109618 (OOM corruption) के लिए

• memory_limit=-1 administratively set करें: यह predictable PHP memory-limit failure हटाता है, जिस पर confirmed exploit निर्भर है। इसे ऐसे set करें कि application बदल न सके (जैसे FPM pool या Apache में php_admin_value), और check करें कि कोई pool, directory या application setting वापस finite limit न लगा दे।
• Risk समझें: -1 का मतलब है PHP की per-script memory limit पूरी तरह हट जाती है। एक भारी या malicious request पूरे server की RAM खा सकती है और दूसरी sites भी down हो सकती हैं। इसे universally safe setting मत मानिए। Advisory के अनुसार यह complete mitigation भी नहीं है — underlying allocation fail होने पर vulnerable path अब भी पहुंचा जा सकता है।
• Container / cgroup memory limit: Availability boundary के तौर पर इस्तेमाल करें, बेहतर हो कि policy सिर्फ प्रभावित worker को kill करे। RLIMIT_AS या RLIMIT_DATA इस्तेमाल न करें — advisory के अनुसार ये खुद vulnerable allocation failure पैदा कर सकते हैं।
• post_max_size कम रखें: File uploads की ज़रूरत न हो तो 8M, ज़रूरत हो तो 32M। upload_max_filesize को post_max_size से कम रखें।
• Frontend पर limits: Web server या proxy पर decoded request size, input field count, multipart part count, header count और nesting depth सीमित करें — उन requests के लिए भी जिनमें usable Content-Length नहीं है। Application multipart forms इस्तेमाल नहीं करती, तो ऐसी requests PHP तक पहुंचने से पहले block करें।

CVE-2026-109619 (stale global state) के लिए

• session.upload_progress.enabled=0 और हर worker restart: इसे php.ini, FPM pool या ऐसी server configuration में set करें जो request parsing से पहले लागू हो। ini_set() या FPM .user.ini पर भरोसा न करें। यह confirmed session paths को block करता है, दूसरे variants को नहीं।
• सिर्फ PHP 8.5 पर: fatal_error_backtraces=0 administratively set करें और हर worker restart करें। यह सिर्फ confirmed fatal backtrace path को block करता है।
• Per-request INI diagnostics हटाएं: .htaccess के php_value/php_flag या nginx से भेजे जाने वाले PHP_VALUE में invalid या deprecated settings हटाएं। error_reporting, display_errors या @ से warnings छिपाने से कोई फायदा नहीं।
• Attacker-reachable fatal errors और timeouts ठीक करें: खासकर upload, import, callbacks और cleanup paths में।
• Optional: Performance की चिंता न हो तो advisory pm.max_requests=1 पर विचार करने को कहती है, ताकि एक worker सिर्फ एक request handle करे। इससे CPU load काफी बढ़ सकता है।

Example configuration (अपने setup के हिसाब से बदलें)

PHP-FPM pool (जैसे /etc/php/8.3/fpm/pool.d/www.conf) — बदलाव के बाद FPM restart ज़रूरी:

; CVE-2026-109618 exposure reduction (memory_limit=-1 के risks ऊपर पढ़ें)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M

; CVE-2026-109619 confirmed session path
php_admin_flag[session.upload_progress.enabled] = off

; सिर्फ PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off

Apache mod_php (VirtualHost या server config में) — बदलाव के बाद Apache restart ज़रूरी:

php_admin_value memory_limit -1
php_admin_value post_max_size 8M
php_admin_value upload_max_filesize 6M
php_admin_flag session.upload_progress.enabled off

Uploads वाली site पर post_max_size को 32M तक रखें और upload_max_filesize उससे कम। Session upload progress docs

Hosting Provider को भेजने के लिए Email Template

Shared hosting पर हैं और Site Health में version fixed list से पुराना दिख रहा है, तो यह message support ticket में भेजें:

Subject: Urgent: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) patch status

Hello Support Team,

Please confirm the patch status for PHP2Shell
(CVE-2026-109618 and CVE-2026-109619) on my account.

Domain: [yourdomain.com]
Account/Server ID: [your-account-id]
Current PHP version (WordPress Site Health): [e.g. 8.3.30]

1. Has the PHP runtime for my account been updated to a fixed release
   (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or later), or to a vendor
   package that includes the backported fixes?
2. Have all PHP workers (PHP-FPM / LSAPI / Apache) been restarted
   after the update?
3. Until the patch is applied, can you apply the mitigations from the
   official PHP advisory at server level
   (e.g. session.upload_progress.enabled=0)?
4. If my site is on PHP 8.1 or older, which supported version do you
   recommend I switch to?

Thank you,
[Your Name]

Agency और SysAdmin के लिए Remediation Checklist

• Inventory: सभी servers, containers और hosting accounts पर PHP branch, installed package version और SAPI (FPM / mod_php / LSAPI / FrankenPHP) की list बनाएं।
• Priority: Public-facing, mod_php वाली, e-commerce और login/payment वाली sites पहले।
• Backup: Patch से पहले files और database का snapshot।
• Patch: Upstream fixed release या vendor security backport।
• Restart: हर server पर सही PHP service restart करें। Containers rebuild और redeploy करें।
• Verify: Website वाला runtime version (CLI नहीं) और vendor advisory के हिसाब से package status confirm करें।
• EOL cleanup: PHP 8.1 और पुराने branches वाली sites का migration plan।

Compromise का शक हो तो: शुरुआती जांच

नीचे के checks सिर्फ clues देते हैं, इनसे exploitation साबित नहीं होता। Legitimate deployments और plugin updates भी files बदलते हैं, और attacker files के timestamps पुराने भी दिख सकते हैं।

• हाल में बदली गई PHP files की list (path अपने server के अनुसार):

  find /var/www -name "*.php" -type f -mtime -3

• WordPress users list में अनजान administrator accounts।
• /wp-content/uploads/ में अनपेक्षित .php files।
• Server crontab और WordPress cron में अनजान बदलाव।
• Web server और PHP logs में unusual errors, worker crashes और suspicious requests। Advisory के अनुसार logs में error न दिखना भी safety का सबूत नहीं है।

Compromise के ठोस संकेत मिलें तो

1. Files delete या server rebuild करने से पहले relevant logs और suspicious files की copy सुरक्षित रखें, ताकि ठीक से जांच हो सके।
2. Incident की गंभीरता के हिसाब से किसी अनुभवी security professional या hosting security team से जांच करवाएं।
3. जांच के दायरे के अनुसार WordPress admin passwords, database credentials, SFTP/SSH keys, API keys और wp-config.php की salts/keys बदलें।
4. Backup से restore तभी करें जब पक्का हो कि वह backup compromise से पहले का और clean है — वरना backdoor वापस आ सकता है। Restore के बाद भी PHP patch ज़रूर करें।
5. Financial fraud या data theft हुआ है, तो cybercrime.gov.in पर या 1930 helpline पर शिकायत करें।

FAQ: PHP2Shell से जुड़े आम सवाल

Official Sources और Related Article

• PHP Security Advisory, 21 October 2026 (php.net news archive)
• GHSA-w8hw-w9fx-j79w: CVE-2026-109618 (RCE via OOM corruption)
• GHSA-6wmf-4rv5-p3rp: CVE-2026-109619 (RCE via stale global state)
• PHP 8 ChangeLog · PHP Downloads
• Vendor trackers: Ubuntu (CVE-2026-109619), Debian (CVE-2026-109619), Red Hat (CVE-2026-109619)
• WordPress Site Health · Debugging in WordPress
• IT KEEDA पर पढ़ें: Excel Copy Paste काम नहीं कर रहा? Fix