टेक लॉग

php2shell (CVE-2026-109618 / 109619) का आकलन php -v से नहीं हो सकता: FPM, Docker और distro में वर्शन नंबर कहाँ अलग हो जाते हैं

प्रकाशित: 2026-10-22 · लेखक: GRAMSHIFT

CLI बनाम FPM वर्शन, Docker टैग, distro बैकपोर्ट, और शेयर्ड होस्टिंग पर क्या जाँचें

यह पेज मूल जापानी पेज से AI द्वारा अनुवादित है। कोई अंतर होने पर जापानी संस्करण ही मान्य है। मूल पेज यहाँ देखें: 日本語

अगर वेब रिक्वेस्ट संभालने वाला PHP (PHP-FPM, Apache का mod_php, php-cgi, FrankenPHP, LiteSpeed) 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 से पुराना है, तो वह php2shell के नाम से जाने जाने वाले CVE-2026-109618 और CVE-2026-109619 से प्रभावित है। उपाय है इनमें से किसी वर्शन पर अपग्रेड करना (या distro पैकेज के मामले में फिक्स्ड पैकेज पर) और प्रोसेस रीस्टार्ट करना। जाँचना आपके लोकल php -v को नहीं है, बल्कि “वह PHP जो असल में वेब चला रहा है” और “इंस्टॉल किए पैकेज का वर्शन” जाँचना है।

यह लेख उन चार जगहों पर केंद्रित है जहाँ सिर्फ़ वर्शन नंबर देखकर फ़ैसला करने से गलत निष्कर्ष निकलता है। सभी आँकड़े और स्थिति की जानकारी 2026-10-22 तक की है, और हर बिंदु के स्रोत अंत में सूचीबद्ध हैं।

2026-10-22 तक क्या ज्ञात है

बिंदु	विवरण
CVE	CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) / CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)
गंभीरता	PHP की एडवाइज़री में दोनों को CVSS v4.0 9.2 (Critical) रेट किया गया है
फिक्स्ड वर्शन	8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (2026-10-21 को जारी)
प्रभावित वर्शन	ऊपर दिए फिक्स्ड वर्शनों से पहले के वर्शन (GitHub एडवाइज़री के अनुसार)
दायरा	वेब रिक्वेस्ट संभालने वाला कोई भी PHP। एडवाइज़री में PHP-FPM, mod_php, php-cgi, FrankenPHP और LiteSpeed का नाम है, और mod_php को सबसे ज़्यादा जोखिम वाला बताया गया है। GitHub एडवाइज़री में mod_php के लिए exploit का प्रदर्शन हो चुका है, जबकि FPM और FrankenPHP को “not demonstrated” (प्रदर्शित नहीं) या “conditional” (शर्तों के साथ) बताया गया है। प्रदर्शित न होने का मतलब सुरक्षित होना नहीं है, इसलिए PHP जिस भी तरीके से चलाएँ, फिक्स्ड वर्शन पर अपग्रेड करें
8.1 और उससे पुराने	PHP प्रोजेक्ट की ओर से कोई अपडेट नहीं। 7.4 / 8.0 / 8.1 के लिए न्यूनतम सोर्स बैकपोर्ट प्रकाशित हुए हैं, और कुछ distro व LTS वेंडर फिक्स जारी कर सकते हैं
8.2	2026-12-31 को सपोर्ट समाप्त (8.2.35 के रिलीज़ नोट्स के अनुसार)

PHP की एडवाइज़री कहती है कि “एकमात्र पूर्ण समाधान अपडेट करना है।” अपडेट कर पाने से पहले की अवधि के लिए उपाय इस लेख में आगे दिए गए हैं।

जाल 1: `php -v` और वेब वाला PHP अलग हो सकते हैं

SSH पर टाइप किया गया php -v CLI वाले PHP का वर्शन बताता है। वेब रिक्वेस्ट PHP-FPM प्रोसेस या Apache में लोड हुए mod_php से संभाली जाती हैं, जो अलग बाइनरी और अलग पैकेज हैं। अगर आपने सिर्फ़ CLI के लिए नया PHP इंस्टॉल किया है, कई वर्शन साथ-साथ चलाते हैं, या कोई FPM पूल किसी दूसरे वर्शन की ओर इशारा करता है, तो php -v में फिक्स्ड वर्शन दिखने पर भी वेब वाला हिस्सा पुराना रह सकता है।

वेब वाले हिस्से का असली वर्शन देखने के कई तरीके हैं।

# Debian / Ubuntu पर FPM (हर वर्शन के नाम से अलग)
php-fpm8.3 -v

# RHEL-परिवार में FPM
php-fpm -v

# जाँचें कि Apache में mod_php लोड है या नहीं
apachectl -M | grep -i php

सबसे भरोसेमंद तरीका यह है कि जो PHP असल में वेब के ज़रिए चलता है, उसी से अपना वर्शन बताने को कहा जाए। अनुमान लगाने में मुश्किल नाम वाली एक अस्थायी फ़ाइल रखें, और जाँच होते ही उसे हटा दें।

<?php echo PHP_VERSION, ' ', PHP_SAPI;

अगर PHP_SAPI का मान fpm-fcgi है, तो PHP FPM के तहत चल रहा है; apache2handler का मतलब mod_php है; cgi-fcgi का मतलब CGI है। phpinfo() को खुला न छोड़ें, क्योंकि इससे खुद ही जानकारी लीक होती है।

रीस्टार्ट भी एक ऐसा कदम है जो आसानी से छूट जाता है। पैकेज बदल जाने के बाद भी, पहले से चल रहे php-fpm या Apache प्रोसेस पुराना कोड चलाते रह सकते हैं। कुछ सेटअप पैकेज अपडेट पर अपने आप रीस्टार्ट हो जाते हैं; कुछ नहीं होते। अपडेट के बाद FPM / Apache रीस्टार्ट करें और ऊपर के तरीकों से वेब वाला वर्शन फिर से जाँचें।

जाल 2: Docker में टैग के नाम से फ़ैसला नहीं किया जा सकता

आधिकारिक php इमेज में 8.3 और 8.3-fpm जैसे “moving टैग” (बदलते रहने वाले टैग) हैं, जिनकी सामग्री बदली जाती रहती है, और 8.3.30 जैसे पिन किए गए टैग हैं, जो वर्शन को स्थिर रखते हैं।

Docker Hub पर moving टैग के फिक्स्ड वर्शन पर बदल जाने के बाद भी, आपकी लोकल कॉपी तब तक पुरानी इमेज ही रहती है जब तक आप दोबारा pull न करें। चल रहे कंटेनर भी दोबारा बनाए जाने तक पुरानी इमेज इस्तेमाल करते रहते हैं। FROM php:8.3-fpm वाली Dockerfile भी, अगर बिल्ड कैश में पुराना बेस बचा है, तो पुराने बेस पर ही बनेगी।
पिन किया गया टैग हमेशा के लिए पुराना रहता है, जब तक आप खुद नंबर नहीं बढ़ाते।

फिक्स्ड वर्शन के टैग प्रकाशित हुए हैं या नहीं, यह Docker Hub API से जाँचा जा सकता है।

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

2026-10-22 को चार रिलीज़ लाइनों पर क्वेरी करने के नतीजे ये हैं (समय UTC में)।

फिक्स्ड वर्शन	मिले टैग	Debian-आधारित टैग (`-fpm`, `-apache` आदि) कब दिखे	Alpine-आधारित टैग
8.5.12	54 (RC1 सहित)	2026-10-21 18:59–22:13	2026-10-21 22:12–10-22 01:05
8.4.27	54 (RC1 सहित)	2026-10-21 22:09–22:11	2026-10-21 22:09–10-22 03:58
8.3.36	27	2026-10-21 22:04–22:06	2026-10-21 22:04–10-22 03:56
8.2.35	27	2026-10-21 21:59–22:01	2026-10-21 22:00–10-22 00:58

इसकी जाँच करने पर तीन ऐसी बातें सामने आईं जहाँ सिर्फ़ संख्या देखकर निर्णय लेने से भ्रम हो सकता है।

“हाल ही में अपडेट हुआ” का मतलब “ठीक हो चुका” नहीं है। पिन किया गया टैग 8.3.35 2026-10-21 के दौरान दोबारा बनाया गया था, लेकिन उसके अंदर PHP_VERSION अब भी 8.3.35 ही था। अपडेट का समय नहीं, अंदर का वर्शन देखें।
digest अलग होने पर भी सामग्री एक जैसी हो सकती है। 8.3 और 8.3.36 के टैग digest (मल्टी-आर्किटेक्चर इंडेक्स का मान) अलग थे, लेकिन amd64 इमेज एक ही थी और दोनों में PHP_VERSION=8.3.36 था। इसी तरह 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm और 8.2-fpm में भी amd64 इमेज का PHP_VERSION ठीक किया गया वर्शन था।
8.1 और उससे पुराने वर्शन के लिए कोई ठीक की गई आधिकारिक इमेज नहीं है। 8.1-fpm का आखिरी अपडेट 2025-12-31 को हुआ था।

अपनी लोकल इमेज और चल रहे कंटेनर जाँचने के लिए:

# लोकल रूप से pull की गई इमेज का PHP वर्शन
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# दोबारा pull करें और कंटेनर फिर से बनाएँ
docker compose pull
docker compose up -d

# अगर आप अपनी इमेज खुद बनाते हैं, तो बेस इमेज दोबारा pull करके फिर build करें
docker compose build --pull

# चल रहे कंटेनर के अंदर का वर्शन
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

आखिरी कमांड में app की जगह अपनी सर्विस का नाम लिखें। हर आधिकारिक इमेज एक ही PHP_VERSION के साथ बनी होती है, इसलिए कंटेनर के अंदर CLI का वर्शन उसी कंटेनर के FPM / Apache के वर्शन के बराबर होता है (PHP सीधे होस्ट पर इंस्टॉल हो तो पिटफॉल 1 लागू होता है)।

FrankenPHP में PHP अंदर ही जुड़ा होता है, इसलिए FrankenPHP का वर्शन और उसमें जुड़े PHP का वर्शन अलग-अलग संख्याएँ होती हैं। 2026-10-21 को जारी FrankenPHP 1.13.2 के रिलीज़ नोट्स के अनुसार Docker इमेज PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 के साथ और static binary PHP 8.5.12 के साथ बनाई गई हैं।

पिटफॉल 3: डिस्ट्रो पैकेज “पुरानी संख्या के साथ ही ठीक” होते हैं

Ubuntu और RHEL सिर्फ़ फ़िक्स को पुराने वर्शन में पोर्ट करते हैं (बैकपोर्टिंग)। php -v में दिखने वाली संख्या पुरानी ही रहती है, इसलिए “8.3.36 से कम है, यानी असुरक्षित” जैसी संख्यात्मक जाँच ठीक किए जा चुके सिस्टम को भी असुरक्षित बता देगी। इसी तरह सिर्फ़ संख्या देखकर निश्चिंत भी नहीं हुआ जा सकता। निर्णय पैकेज वर्शन और हर डिस्ट्रो के सिक्योरिटी ट्रैकर के आधार पर लें।

2026-10-22 तक हर ट्रैकर में सूचीबद्ध ठीक किए गए पैकेज (दोनों CVE के लिए एक जैसे):

डिस्ट्रो	पैकेज	ठीक किया गया वर्शन	स्रोत
Ubuntu 22.04 (jammy)	php8.1	8.1.2-1ubuntu2.28	USN-8948-1
Ubuntu 24.04 (noble)	php8.3	8.3.6-0ubuntu0.24.04.13	USN-8948-1
Ubuntu 26.04 (resolute)	php8.5	8.5.4-0ubuntu1.5	USN-8948-1
Ubuntu (stonking)	php8.5	8.5.9-0ubuntu2.1	USN-8948-1
Ubuntu 14.04 / 16.04 / 18.04 / 20.04	php5 / php7.0 / php7.2 / php7.4	Ubuntu Pro (Legacy Support सहित) के ज़रिए उपलब्ध	USN-8948-2
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1	DLA-4848-1
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1	DSA-6574-1
RHEL 10	php / php8.4	8.3.36-1.el10_2 / 8.4.27-1.el10_2	Red Hat
RHEL 9	php (डिफ़ॉल्ट)	8.0.30-8.el9_8.1	Red Hat
RHEL 9	php module 8.2 / 8.3	8.2.35-1.module+el9.8.0… / 8.3.36-1.module+el9.8.0…	Red Hat
RHEL 8	php module 7.4 / 8.2	7.4.33-8.module+el8.10.0… / 8.2.35-1.module+el8.10.0…	Red Hat

यह तालिका सीधे दिखाती है कि सिर्फ़ संख्याएँ काफ़ी क्यों नहीं हैं। Ubuntu 24.04 का ठीक किया गया PHP 8.3.6 से शुरू होने वाला वर्शन है, जो upstream के 8.3.36 से काफ़ी कम है। RHEL 9 का डिफ़ॉल्ट PHP 8.0.30 पर ही रहते हुए ठीक किया गया है, जबकि upstream अब 8.0 के लिए फ़िक्स जारी नहीं करता। Debian upstream जैसी संख्याओं (8.2.35 / 8.4.27) पर आ गया है।

कुछ पैकेज अभी ठीक नहीं हुए हैं (2026-10-22 तक)।

RHEL 9 का php module 8.4 “affected, no fix” (प्रभावित, फ़िक्स नहीं) के रूप में सूचीबद्ध है।
Debian forky (testing) में php8.4 8.4.26-1 है, जिसे “vulnerable” चिह्नित किया गया है। sid (unstable) का php8.4 8.4.27-1 है और ठीक किया जा चुका है।

अपने सर्वर की जाँच के लिए उदाहरण कमांड:

# Debian / Ubuntu: इंस्टॉल किया गया वर्शन और उपलब्ध वर्शन
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: क्या इस सर्वर पर यह CVE ठीक किया जा चुका है
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# RHEL-परिवार: क्या इस CVE को ठीक करने वाला अपडेट मौजूद है, और इंस्टॉल किया गया वर्शन
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

पैकेज का नाम (php8.3-fpm आदि) अपने वातावरण के अनुसार बदलें। दिखाए गए वर्शन की तुलना ऊपर की तालिका या ट्रैकर के “ठीक किया गया वर्शन” से करें; यदि वह बराबर या उससे ऊपर है, तो फ़िक्स मौजूद है। उसके बाद पिटफॉल 1 में बताया गया रीस्टार्ट और वेब-साइड जाँच पूरी करें।

यदि आप PHP डिस्ट्रो के अपने पैकेज के बजाय किसी थर्ड-पार्टी रिपॉज़िटरी से इंस्टॉल करते हैं, तो आपको उसी रिपॉज़िटरी के अपडेट देखने होंगे। PHP की एडवाइज़री में कहा गया है कि स्वयंसेवकों द्वारा चलाए जाने वाले rpms.remirepo.net पर खुलासे वाले दिन अपडेट उपलब्ध नहीं होंगे, और डिस्ट्रो पैकेज या अपने बिल्ड पर जाने की सलाह दी गई है।

पिटफॉल 4: शेयर्ड होस्टिंग और मैनेज्ड वातावरण में आप PHP खुद अपग्रेड नहीं कर सकते

शेयर्ड होस्टिंग और मैनेज्ड PHP एनवायरनमेंट में PHP रनटाइम प्रोवाइडर ही बदलता है। यहाँ भी सिर्फ़ संस्करण संख्या काफ़ी नहीं है: अगर प्रोवाइडर PHP खुद बनाता है या फ़िक्स बैकपोर्ट करता है, तो संस्करण संख्या पुरानी ही रह सकती है।

तीन काम आप खुद कर सकते हैं।

वेब साइड का संस्करण जाँचें। समस्या 1 की अस्थायी फ़ाइल से PHP_VERSION और PHP_SAPI प्रिंट करें और फिर उसे तुरंत हटा दें। अगर कंट्रोल पैनल में PHP संस्करण चुनने का विकल्प है, तो यह भी नोट कर लें कि आपने कौन-सा संस्करण चुना है।
प्रोवाइडर की सूचना पढ़ें, और न हो तो पूछें। पूछें: “मेरे प्लान के किन PHP संस्करणों में CVE-2026-109618 और CVE-2026-109619 के फ़िक्स लागू किए जाएँगे, और कब (या क्या लागू हो चुके हैं)?” संस्करण संख्या के बजाय CVE नंबर से पूछने पर बैकपोर्ट को भी शामिल करता हुआ जवाब मिलता है।
अगर आपने असमर्थित संस्करण चुना है, तो अपग्रेड करें। PHP प्रोजेक्ट 8.1 और उससे पुराने संस्करणों के लिए फ़िक्स जारी नहीं करता, और 8.2 का सपोर्ट 2026-12-31 को समाप्त हो जाता है। जब तक प्रोवाइडर ने फ़िक्स बैकपोर्ट न किए हों, संस्करण बदलना ही भरोसेमंद रास्ता है।

होस्टिंग प्रोवाइडर के अनुसार स्थिति (2026-10-22 तक)

शेयर्ड होस्टिंग में PHP रनटाइम आम तौर पर प्रोवाइडर ही अपडेट करता है, और कई प्रोवाइडरों की सूचनाओं में लिखा है कि “उपयोगकर्ताओं को कोई कार्रवाई करने की आवश्यकता नहीं है।” उपयोगकर्ता को दो काम करने हैं: अपने प्रोवाइडर की आधिकारिक सूचना देखना, और अगर कंट्रोल पैनल में पुराना PHP संस्करण चुना है, तो तय करना कि सूचना में सुझाए गए संस्करण (जिसका फ़िक्स्ड रिलीज़ मौजूद हो) पर जाना है या नहीं।

नीचे की तालिका में सिर्फ़ वही बातें संक्षेप में दी गई हैं जो हर प्रोवाइडर के आधिकारिक पेजों (घोषणाओं और मेंटेनेंस जानकारी) में लिखी हैं; सूचनाओं के शब्दों को अपने शब्दों में लिखा गया है। सूचनाएँ प्रगति के साथ अपडेट होती रहती हैं, इसलिए असली स्थिति हमेशा संदर्भित आधिकारिक पेज पर ही जाँचें।

प्रोवाइडर / सेवा	आधिकारिक सूचना के मुख्य बिंदु	सूचना की तारीख/समय	स्रोत
エックスサーバー	“PHP 8.2–8.5 के लिए, सभी प्रभावित सर्वरों पर फ़िक्स पैच लागू करने का काम पूरा हो गया है।” पुराने संस्करणों के बारे में सूचना कहती है कि “कुछ संस्करणों के लिए फ़िक्स पैच तैयार हैं और सत्यापन पूरा होने पर क्रम से लागू किए जाएँगे,” और अन्य पुराने संस्करणों पर भी काम चल रहा है	10/22 6:45 पर जैसा लिखा था (पेज 13:15 तक अपडेट हुआ)	メンテナンスの進捗状況
シン・レンタルサーバー	घोषणा पेज पर Xserver जैसी ही “मेंटेनेंस प्रगति” दी गई है, लेकिन Shin Rental Server की PHP स्थिति के बारे में विशेष रूप से कोई कथन मुझे नहीं मिला (सपोर्ट से पूछें)	-	お知らせ
ConoHa WING	“आप जो PHP संस्करण अभी उपयोग कर रहे हैं उसे बनाए रखते हुए हम सुरक्षा पैच लागू कर रहे हैं।” सूचना के अनुसार उपयोगकर्ताओं को आम तौर पर संस्करण बदलने की ज़रूरत नहीं है, लेकिन PHP 5.x और 7.x के लिए बदलाव की ज़रूरत पड़ सकती है। एहतियात के तौर पर फ़ाइल मैनेजर और वेबमेल अस्थायी रूप से बंद हैं; वेबसाइट डिस्प्ले और ईमेल भेजना/प्राप्त करना सामान्य रूप से जारी है	10/22	【重要】PHPの脆弱性への弊社対応について
さくらのレンタルサーバ	“हमारे कंट्रोल पैनल से चुने जा सकने वाले सभी PHP संस्करणों के लिए कमज़ोरी पर हमारी कार्रवाई पूरी हो गई है।” सूचना कहती है कि “ग्राहकों से किसी तत्काल कार्रवाई की आवश्यकता नहीं है,” और आगे चलकर नवीनतम समर्थित संस्करण पर जाने की सलाह देती है। सूचना के अनुसार वेबमेल पर 10/22 13:45 को काम पूरा हुआ और phpMyAdmin पर काम जारी है	10/22 (13:45 को अपडेट)	PHPの脆弱性（CVE-2026-109618、CVE-2026-109619）への対応状況について
ロリポップ！	फ़िक्स्ड संस्करणों के रिलीज़ से पहले एहतियाती मेंटेनेंस की सूचना (सर्विस साइट, यूज़र पेज आदि बारी-बारी से बंद होंगे; साइटें बिना पूर्व सूचना के बंद या सीमित की जा सकती हैं)। 10/22 तक PHP फ़िक्स पूरा होने की घोषणा करने वाली कोई सूचना मुझे नहीं मिली (सपोर्ट से पूछें)	10/21	【重要】PHPの脆弱性への予防措置に伴うメンテナンス実施のお知らせ
ヘテムル	“PHP 8.x और PHP 7.4 के लिए हमने आधिकारिक फ़िक्स्ड संस्करण लागू कर दिए हैं”; अन्य संस्करणों के लिए “हमने आधिकारिक फ़िक्स के आधार पर अपने स्तर पर फ़िक्स किए हैं।” क्योंकि “सभी संस्करणों में कुछ कार्यक्षमता (session.upload_progress) बंद कर दी गई है,” उपयोगकर्ताओं से अपनी साइटें जाँचने को कहा गया है। चूँकि पुराने संस्करणों को आगे फ़िक्स न मिलें, सूचना नए संस्करण पर जाने की सलाह देती है	10/21 19:44 को पोस्ट; 10/22 12:18 और 13:20 को अपडेट	【一部完了】【重要】PHPの脆弱性への予防措置に伴うメンテナンス実施のお知らせ
mixhost	“PHP फ़िक्स पैकेज लागू करने का काम 22 अक्टूबर 2026 को लगभग 10:18 बजे पूरा हुआ।” “PHP संस्करण संख्या बदले बिना लागू किया गया”; “ग्राहकों को किसी कार्रवाई की आवश्यकता नहीं है।” सूचना PHP 8.2 से नीचे के संस्करणों के उपयोगकर्ताओं को समर्थित संस्करण (8.2 या उससे नया) इस्तेमाल करने की सलाह देती है	10/22	【完了】PHPの重大な脆弱性への対応について
KAGOYA	रेंटल सर्वर सेवा के लिए PHP 8.2–8.5 को फ़िक्स्ड संस्करणों के सत्यापन के बाद क्रम से अपडेट किया जाएगा (लक्षित संस्करण अभी तय हो रहे हैं)। मैनेज्ड डेडिकेटेड, शेयर्ड और WordPress-विशेष सर्वरों के लिए स्थायी फ़िक्स की योजना अभी बन रही है; अंतरिम उपाय के रूप में सूचना साइटों को ऑफ़लाइन करने या एक्सेस सीमित करने पर विचार करने का सुझाव देती है	10/21 18:20 को पोस्ट; 10/22 10:35 को अपडेट	PHPの脆弱性に関する当社サービスへの影響について
Zenlogic（IDCフロンティア）	आपातकालीन मेंटेनेंस (10/21 22:00–10/22 18:00; समाप्ति समय बदल सकता है) के दौरान फ़िक्स लागू किए गए। PHP 5.3 को नवीनतम संस्करण पर अपडेट किया जाएगा और वापस नहीं लौटाया जा सकेगा; 7.4 और 8.1 अपडेट हो सकते हैं। सूचना कहती है कि अपडेट के बाद डिस्प्ले या व्यवहार में समस्या आए तो एप्लिकेशन की तरफ़ से ठीक करना होगा	10/21	【ホスティング】緊急メンテナンス作業のお知らせ
ColorfulBox	“आप जो PHP संस्करण अभी उपयोग कर रहे हैं उसे बनाए रखते हुए सर्वर की ओर से पैच किए गए संस्करणों पर अपडेट पूरा हो गया है।” सूचना कहती है कि “ग्राहकों को स्वयं PHP संस्करण बदलने या स्विच करने की आवश्यकता नहीं है”	10/22	【重要】PHPの脆弱性に対するセキュリティアップデート完了のお知らせ
お名前.com レンタルサーバー	“आप जो PHP संस्करण अभी उपयोग कर रहे हैं उसे बनाए रखते हुए हम सुरक्षा पैच लागू कर रहे हैं।” सूचना के अनुसार संस्करण बदलना आम तौर पर ज़रूरी नहीं है, लेकिन PHP 5.x और 7.x के लिए ज़रूरी हो सकता है। एहतियात के तौर पर फ़ाइल मैनेजर और वेबमेल अस्थायी रूप से बंद हैं	10/22	【重要】PHPの脆弱性への弊社対応について
CORESERVER（V2）	“हमारे द्वारा उपलब्ध कराए जाने वाले सभी PHP संस्करणों के लिए कमज़ोरी पर हमारी कार्रवाई पूरी हो गई है”; “ग्राहक की ओर से PHP संस्करण बदलने जैसी किसी कार्रवाई की आवश्यकता नहीं है।” मेंटेनेंस 10/22 0:00–11:13 तक चला और पूर्ण बताया गया है	10/21 को पोस्ट (10/22 को पूर्ण)	PHP脆弱性の対応（CORESERVER V2）【完了】
XREA	“PHP 7.4 और उसके बाद के संस्करणों (7.4 / 8.0 / 8.1 / 8.2 / 8.3 / 8.4 / 8.5) के लिए कमज़ोरी पर हमारी कार्रवाई पूरी हो गई है।” इन संस्करणों के उपयोगकर्ताओं को संस्करण बदलने की ज़रूरत नहीं है। सूचना में 7.4 से नीचे के संस्करणों के बारे में कुछ नहीं कहा गया है	10/21 को पोस्ट (10/22 0:50 को पूर्ण)	PHP脆弱性の対応（XREA）【完了】
バリューサーバー	“PHP 7.4 और उसके बाद के संस्करणों के लिए कमज़ोरी पर हमारी कार्रवाई पूरी हो गई है।” सूचना कहती है कि इन संस्करणों के उपयोगकर्ताओं को संस्करण बदलने की ज़रूरत नहीं है	10/21 को पोस्ट (10/22 0:50 को पूर्ण)	PHP脆弱性の対応（VALUESERVER）【完了】
ABLENET	“PHP में पहचानी गई दो कमज़ोरियों के संबंध में, हमने अपने रेंटल सर्वर एनवायरनमेंट के लिए सुरक्षा अपडेट की प्रारंभिक कार्रवाई कर ली है।” सूचना में यह नहीं बताया गया कि कौन-से संस्करण शामिल हैं या उपयोगकर्ताओं को कोई कार्रवाई करनी है या नहीं	10/22 13:04	PHPの脆弱性に関するセキュリティアップデートの対応について
WebARENA（レンタルサーバー）	10/22 तक मुझे कोई आधिकारिक सूचना नहीं मिली (सपोर्ट से पूछें)	-	WebARENA お知らせ（2026年）

जहाँ मुझे आधिकारिक सूचना नहीं मिली या खुल नहीं सकी, वहाँ तालिका में “पुष्टि नहीं हो सकी” या “नहीं मिली” लिखा है। वहाँ जानकारी का न होना यह नहीं दर्शाता कि प्रोवाइडर ने कार्रवाई नहीं की है। अपने प्रोवाइडर की घोषणाओं और सपोर्ट से सीधे जाँचें।

तुरंत अपडेट न कर पाने की स्थिति में शमन उपाय

PHP एडवाइज़री में ऐसी सेटिंग्स दी गई हैं जो अपडेट करने तक अटैक सरफ़ेस घटाती हैं। हालाँकि एडवाइज़री खुद स्पष्ट कहती है कि ये “आपको सुरक्षित नहीं बनातीं।” मुख्य उपाय ये हैं:

CVE-2026-109619 के लिए: php.ini, FPM पूल या सर्वर कॉन्फ़िगरेशन में session.upload_progress.enabled=0 सेट करें और सभी वर्कर्स को रीस्टार्ट करें (इसके लिए ini_set() और FPM की .user.ini काम नहीं करतीं)। PHP 8.5 में fatal_error_backtraces=0 भी सेट करें।
CVE-2026-109618 के लिए: memory_limit=-1 को इस तरह सेट करें कि एप्लिकेशन उसे ओवरराइड न कर सके, और post_max_size घटाएँ (अपलोड न हों तो 8M, हों तो 32M)। RLIMIT_AS / RLIMIT_DATA को विकल्प के तौर पर इस्तेमाल न करें।

यूके का NCSC सलाह देता है कि जिस सिस्टम को तुरंत अपडेट या शमित न किया जा सके, उसे ऑफ़लाइन करने पर विचार करें, और अपडेट या शमन लागू करने से पहले समझौते (compromise) के संकेत जाँचें।

स्रोत (2026-10-22 को जाँचे गए)

php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
php.net: Upcoming Critical PHP Security Release (2026-10-20)
php.net: PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 की रिलीज़ घोषणाएँ
GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
Docker Hub: आधिकारिक php इमेज
FrankenPHP 1.13.2 रिलीज़ नोट्स
Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
Red Hat: CVE-2026-109618 / CVE-2026-109619 (ठीक किए गए पैकेज के वर्शन Red Hat के VEX डेटा से लिए गए हैं)
NCSC: Critical security issue affecting PHP

अक्सर पूछे जाने वाले प्रश्न

अगर php -v में फिक्स्ड वर्शन दिख रहा है, तो क्या मैं php2shell (CVE-2026-109618 / 109619) से सुरक्षित हूँ?

ज़रूरी नहीं। php -v सिर्फ CLI वाले PHP का वर्शन बताता है। वेब रिक्वेस्ट संभालने वाला PHP-FPM या Apache का mod_php अलग बाइनरी और अलग पैकेज हो सकता है। FPM का वर्शन php-fpm8.3 -v से देखें (RHEL-परिवार में php-fpm -v)। या फिर वेब से एक अस्थायी फ़ाइल खोलें जो PHP_VERSION और PHP_SAPI प्रिंट करे, और जाँच होते ही उसे हटा दें। अगर अपडेट के बाद आपने FPM या Apache को रीस्टार्ट नहीं किया, तो वे पुराना कोड ही चलाते रह सकते हैं।

अगर मैं Docker का php:8.3-fpm इस्तेमाल करता हूँ, तो क्या php2shell ठीक हो चुका है?

2026-10-22 तक Docker Hub पर php:8.3-fpm को PHP 8.3.36 पर बदल दिया गया है। लेकिन आपकी लोकल इमेज तब तक पुरानी रहती है जब तक आप उसे दोबारा pull न करें, और चल रहे कंटेनर दोबारा बनाए जाने तक पुरानी इमेज ही इस्तेमाल करते रहते हैं। docker compose pull और docker compose up -d चलाएँ (अगर अपनी इमेज खुद बनाते हैं तो docker compose build --pull)। फिर कंटेनर के अंदर php -r 'echo PHP_VERSION;' चलाकर पुष्टि करें कि वर्शन 8.3.36 या उससे नया है। 8.3.30 जैसे पिन किए गए टैग तब तक पुराने रहते हैं जब तक आप खुद नंबर नहीं बढ़ाते।

Ubuntu और RHEL में अब भी PHP 8.3.6 या 8.0.30 दिख रहा है। क्या वे php2shell से प्रभावित हैं?

सिर्फ़ वर्शन नंबर से यह नहीं बताया जा सकता। Ubuntu और RHEL फिक्स को पुराने वर्शनों में बैकपोर्ट करते हैं, इसलिए पैकेज ठीक हो सकता है जबकि उसका नंबर पुराना ही रहता है। 2026-10-22 तक फिक्स Ubuntu 24.04 में php8.3 8.3.6-0ubuntu0.24.04.13 और RHEL 9 में php 8.0.30-8.el9_8.1 में है। अपने इंस्टॉल किए पैकेज का वर्शन (apt-cache policy या rpm -q) अपने distro के सिक्योरिटी ट्रैकर में दिए फिक्स्ड वर्शन से मिलाएँ। Ubuntu पर pro fix CVE-2026-109618 से, या RHEL-परिवार में dnf updateinfo list --cve CVE-2026-109618 से भी जाँच की जा सकती है।