PHP सुरक्षा अपडेट: पहले पैच, फिर सीक्रेट और ऐक्सेस की समीक्षा

PHP ने 21 अक्टूबर 2026 को CVE-2026-109618 और CVE-2026-109619 ठीक करने के लिए 8.5.12, 8.4.27, 8.3.36 और 8.2.35 जारी किए। ये गंभीर कमजोरियाँ प्रमाणीकरण के बिना दूर से कोड चलाने की अनुमति दे सकती हैं। आधिकारिक घोषणा के अनुसार PHP-FPM और Apache mod_php समेत वेब अनुरोध सँभालने वाले इंस्टॉलेशन जोखिम में हैं। पूर्ण सुधार अपडेट है; अस्थायी उपाय उसके बराबर नहीं हैं।

कमजोर इंस्टॉलेशन घुसपैठ का प्रमाण नहीं है। पैच, जाँच और क्रेडेंशियल की पुनर्प्राप्ति को जुड़े काम मानें, लेकिन अपने वातावरण और प्रमाणों के आधार पर निर्णय लें।

पुष्टि करें कि वास्तव में अनुरोध कौन सँभालता है

PHP चलाने वाली सार्वजनिक वेबसाइट, आंतरिक सेवाएँ, कंटेनर और होस्टिंग अकाउंट सूचीबद्ध करें। वेब अनुरोध संसाधित करने वाले रनटाइम का संस्करण और पैच स्थिति जाँचें; कमांड लाइन का संस्करण किसी दूसरे इंस्टॉलेशन का हो सकता है।

प्रबंधित होस्टिंग में ऑपरेटर से लागू पैकेज, संबंधित सेवा और रीस्टार्ट या रोलआउट की पुष्टि माँगें। वितरण प्रदाता पुराने संस्करण में सुधार वापस जोड़ सकते हैं, इसलिए सिर्फ़ मूल संस्करण संख्या देखकर निर्णय न लें। प्रदाता से पैच की पुष्टि लें और PHP टीम की सलाह से दायरा जाँचें। सर्वर कॉन्फ़िगरेशन उजागर करने वाला निदान पेज सार्वजनिक न करें।

जोखिम सीमित करें और भरोसेमंद वातावरण बहाल करें

होस्टिंग या संचालन टीम के साथ तुरंत अपडेट समन्वित करें। घटना के मूल्यांकन में ज़रूरत हो तो संबंधित प्रमाण सुरक्षित रखते हुए बाहरी पहुँच सीमित या प्रभावित सिस्टम अलग करें। केवल लॉग संग्रह पूरा करने के लिए तत्काल रोकथाम न टालें।

जोखिम की अवधि, वेब और सिस्टम लॉग, अनपेक्षित फ़ाइल या प्रोसेस और संबंधित प्रदाताओं की ऑडिट घटनाएँ देखें। अलर्ट न होना या लॉग सामान्य दिखना साबित नहीं करता कि होस्ट अछूता है।

घुसपैठ की पुष्टि हो या उचित संदेह हो तो अपनी घटना प्रक्रिया के अनुसार भरोसेमंद स्रोत से पुनर्निर्माण या बहाली करें। पैच हमलावर के टिके रहने के साधन नहीं हटाता। अविश्वसनीय होस्ट या डिवाइस पर नए सीक्रेट बनाएँ, प्राप्त या स्थापित न करें।

रोटेशन से पहले क्रेडेंशियल का मूल्यांकन करें

प्रभावित प्रोसेस जिन क्रेडेंशियल तक पहुँच सकता था उन्हें सूचीबद्ध करें: ऐप कॉन्फ़िगरेशन, वातावरण चर, डिप्लॉयमेंट टोकन, डेटाबेस क्रेडेंशियल और प्रदाता API कुंजियाँ। अनुमति, दायरा और संभावित खुलासा तय करें। सिर्फ़ घोषणा से संगठन के सभी क्रेडेंशियल लीक होना साबित नहीं होता।

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

ज़रूरत अनुसार सत्र और रिकवरी ऐक्सेस देखें तथा हर बदलाव का जिम्मेदार दर्ज करें। घटना टिकट या लॉग में वास्तविक सीक्रेट न डालें। OWASP

काम पूरा होने पर आपातकालीन ऐक्सेस बंद करें

प्रतिक्रिया देने वालों को अलग अकाउंट, सीमित अनुमति और तय समाप्ति समय दें। बहाली के बाद अस्थायी भूमिकाएँ, सत्र, डिप्लॉयमेंट ऐक्सेस और जानकारी सौंपने वाले लिंक देखें। अब अनावश्यक बचा ऐक्सेस हटाएँ और केवल कैलेंडर रिमाइंडर पर निर्भर होने के बजाय संबंधित सेवा में परिणाम की पुष्टि करें।

तीन अलग नियंत्रणों में अंतर रखें

नियंत्रण	क्या बदलता है	क्या नहीं करता
हैंडऑफ लिंक की समाप्ति	उस लिंक से बाद का ऐक्सेस	प्रदाता का क्रेडेंशियल रद्द नहीं करती
प्रदाता कुंजी रद्द करना	प्रदाता उस कुंजी को स्वीकार करता है या नहीं	सहेजी कॉपी नहीं मिटाता, संक्रमित होस्ट नहीं सुधारता
संदेश या नोट मिटाना	उस सिस्टम में आइटम की उपलब्धता	डाउनलोड, स्क्रीनशॉट या कॉपी टेक्स्ट वापस नहीं लेता

भरोसा बहाल होने के बाद ही अस्थायी हैंडऑफ करें

आपकी प्रक्रिया अनुमति दे तो भरोसेमंद सिस्टम से पासवर्ड-सुरक्षित मेमो बनाएँ, जिसमें सत्यापित प्राप्तकर्ता के लिए न्यूनतम ज़रूरी जानकारी हो। पासवर्ड अलग भेजें और प्लान समर्थन करे तो समाप्ति या ऐक्सेस सीमा लगाएँ। वॉलेट रिकवरी वाक्यांश या निजी कुंजी न डालें।

LOCK.PUB सीमित हैंडऑफ साधन है: वह PHP पैच नहीं कर सकता, संक्रमित डिवाइस नहीं सुधार सकता, प्रदाता कुंजी रद्द नहीं कर सकता और कॉपी वापस नहीं ले सकता। यह सीक्रेट मैनेजर, पहचान नियंत्रण या घटना प्रतिक्रिया का विकल्प नहीं है।

आम सवाल

PHP अपडेट स्थापित करने से जाँच पूरी हो जाती है?

नहीं। वह कमजोरी ठीक करता है; आगे की जाँच, बहाली और क्रेडेंशियल कार्रवाई प्रमाण और जोखिम के दायरे से तय होती है।

मेमो समाप्त होने पर उसमें मौजूद API कुंजी निष्क्रिय होगी?

नहीं। उसे प्रदाता में रद्द या बदलें। कॉपी किया क्रेडेंशियल उसे पहुँचाने वाले लिंक से अलग रहता है।

संबंधित: स्पष्ट सीमाओं के साथ API कुंजी साझा करना।