PHP2Shell कैसे ठीक करें

1 server पर हर PHP खोजें

कई servers एक से अधिक PHP चलाते हैं: सिस्टम पैकेज, कंट्रोल पैनल द्वारा इंस्टॉल संस्करण (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), containers और cron द्वारा उपयोग किए जाने वाले command-line builds। वेब अनुरोध सर्व करने वाले हर PHP को update करना ज़रूरी है।

php -v चलाएँ, ps aux | grep php-fpm से php-fpm प्रोसेस की सूची देखें, और अपने पैनल का PHP selector जाँचें।

2 ठीक किए गए संस्करण पर update करें

ठीक किए गए upstream संस्करण हैं 8.5.12, 8.4.27, 8.3.36 और 8.2.35। distribution पैकेज पुराने संस्करण नंबर के साथ भी fix रख सकते हैं — changelog में CVE-2026-109618 और CVE-2026-109619 देखें।

PHP 8.1 और पुराने संस्करणों को PHP प्रोजेक्ट से कोई रिलीज़ नहीं मिलती। source से build करने वालों के लिए 7.4, 8.0 और 8.1 के न्यूनतम source backports प्रकाशित किए गए हैं, लेकिन स्थायी समाधान किसी समर्थित ब्रांच पर जाना है।

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

3 हर PHP प्रोसेस restart करें

पैकेज इंस्टॉल करने से पहले से चल रहा कोड नहीं बदलता। PHP-FPM, Apache (mod_php के लिए), LiteSpeed, FrankenPHP, queue workers और supervisors को restart करें। containers के लिए नई image rebuild या pull करें — उसी image को restart करने से patch इंस्टॉल नहीं होता।

4 सत्यापन करें

हर binary के लिए php -v चलाएँ और पुष्टि करें कि चल रहे प्रोसेस नए build का उपयोग कर रहे हैं (उदाहरण के लिए ls -l /proc/$(pgrep -o php-fpm)/exe में “deleted” नहीं दिखना चाहिए)। फिर यह चेकर दोबारा चलाएँ।

5 यदि आप आज update नहीं कर सकते

नीचे दिए आंशिक बचाव उपाय लागू करें और जब तक update न कर सकें, सीमित करें कि साइट तक कौन पहुँच सकता है। ये जोखिम कम करते हैं; उसे ख़त्म नहीं करते।

6 सेंधमारी के संकेतों की जाँच करें — और secrets बदलें

यदि कोई कमज़ोर साइट इंटरनेट से पहुँच योग्य थी, तो 20 अक्टूबर 2026 से आगे की गतिविधि की समीक्षा करें: PHP-FPM या Apache error log में PHP worker crashes (SIGSEGV), web root में नई या बदली गई PHP फ़ाइलें, नए cron jobs, नए administrator खाते, और अप्रत्याशित outbound कनेक्शन।

चूँकि CVE-2026-109619 बिना कोई कोड चलाए PHP प्रोसेस की मेमोरी उजागर कर सकता है, इसलिए साफ़ file system इस बात का प्रमाण नहीं है कि कुछ लीक नहीं हुआ। जोखिम में रही साइटों के database पासवर्ड, API keys, payment और mail credentials बदलें, और user sessions अमान्य करें।

7 update के बाद

यह fix एक नई hard memory limit लाता है: उस तक पहुँचने वाला प्रोसेस तुरंत समाप्त कर दिया जाता है और shutdown handlers नहीं चलते। जाँचें कि मेमोरी दबाव में आपका एप्लिकेशन कैसा व्यवहार करता है, memory_limit की post_max_size और max_input_nesting_level के साथ समीक्षा करें, और patch से पहले सेट किया गया कोई भी अस्थायी memory_limit = -1 वापस लें। expose_php = Off से संस्करण छिपाना वैकल्पिक hardening है, fix नहीं।

आंशिक बचाव उपाय (php.net और सुरक्षा सलाहों से)

ये केवल ज्ञात हमले के रास्तों को सीमित करते हैं। php.net के अनुसार update करना ही एकमात्र सुरक्षित विकल्प है।

; php.ini / FPM pool (php_admin_value) — इसके बाद सभी workers restart करें
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M यदि uploads आवश्यक हैं
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

इन्हें php.ini, PHP-FPM pool (php_admin_value) या server कॉन्फ़िगरेशन में सेट करें — ini_set() या .user.ini से नहीं — और workers restart करें। सुरक्षा सलाहों और शोध टीम के अन्य उपाय:

• memory_limit = -1 उन कुछ रास्तों को रोकता है जो PHP की अपनी memory सीमा पर निर्भर हैं, लेकिन memory ख़त्म होने की स्थिति operating system को सौंप देता है — इसे केवल cgroup v2 memory.max सीमा के साथ उपयोग करें। RLIMIT_AS या RLIMIT_DATA का उपयोग न करें; ये वही कमज़ोर रास्ते सक्रिय कर सकते हैं।
• max_input_nesting_level को उतना कम करें जितना आपके forms अनुमति दें।
• PHP-FPM का pm.max_requests कम करें ताकि workers अधिक बार recycle हों (performance पर असर पड़ता है)।
• web server या proxy पर request size, field-count और nesting सीमाएँ लगाएँ; अमान्य या deprecated per-request INI सेटिंग्स हटाएँ।
• SELinux या AppArmor नीतियाँ सीमित कर सकती हैं कि सेंधमारी का शिकार worker क्या चला सकता है — ये असर कम करती हैं, memory disclosure को नहीं रोकतीं।

संदर्भ

• php.net — सुरक्षा सलाह और रिलीज़ घोषणाएँ
• php.net — PHP 8 ChangeLog
• php.net — समर्थित संस्करण
• php.net — डाउनलोड
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation — Today’s PHP security release
• php2shell.com — Wiz Research × OpenAI Codex Security × Calif
• Wiz Research · OpenAI · Calif

स्रोत: php.net सुरक्षा सलाह, 21 अक्टूबर 2026। अंतिम सत्यापन 2026-10-23।