WordPress 7.1.2 लगाएँ—बिना लॉगिन कोड चलना दो शर्तों पर निर्भर

29 सितंबर 2026 को 05:39 pm बजे|लेखक: QUASA संपादकीय टीम|5 मिनट पढ़ने का समय| 1

WordPress ने 22 सितंबर 2026 को CVE-2026-87902 के लिए 7.1.2 सुरक्षा संस्करण जारी किया। खामी में बिना लॉगिन भेजा गया अनुरोध पृष्ठ-साँचे की खोज को सक्रिय थीम से बाहर की स्थानीय PHP फ़ाइल तक पहुँचा सकता है; उस फ़ाइल से दूरस्थ कोड तभी चल सकता है जब थीम और सर्वर की आवश्यक स्थितियाँ भी पूरी हों। समर्थित साइटों पर पृष्ठभूमि का स्वचालित अद्यतन शुरू हो सकता है, इसलिए प्रक्रिया शुरू होने के बजाय स्थापित संस्करण देखना ज़रूरी है।

भारत की CERT-In ने 23 सितंबर 2026 की गंभीर चेतावनी में 7.1 शाखा के लिए 7.1.2 और 7.0 शाखा के लिए 7.0.6 सहित पुरानी शाखाओं के अलग सुधार दर्ज किए। प्रभावित स्थापना की जाँच उसकी अपनी शाखा के सुधरे संस्करण से करनी होगी। बिना लॉगिन अनुरोध से स्थानीय PHP फ़ाइल शामिल हो सकती है और संवेदनशील जानकारी खुल सकती है; कोड चलने का परिणाम अतिरिक्त परिस्थितियों पर निर्भर है।

पृष्ठ-साँचे की खामी में दो शर्तें कैसे जुड़ती हैं

Robert Ressl द्वारा बताई गई खामी को WordPress की तकनीकी सुरक्षा सलाह ने गंभीर दर्ज किया है और उसका CVSS 4.0 अंक 9.2 बताया है। बिना प्रमाणित अनुरोध पृष्ठ-साँचे की खोज को मोड़कर सक्रिय थीम के बाहर वेब सर्वर द्वारा पढ़ी जा सकने वाली स्थानीय PHP फ़ाइल शामिल करा सकता है। जोखिम की दो पूर्वशर्तें हैं: सक्रिय थीम में रास्ता खुलने योग्य बनावट और सर्वर पर उस रास्ते से चुनी जा सकने वाली फ़ाइल।

थीम का रास्ता: सक्रिय मूल या उप-थीम के सबसे ऊपरी स्तर पर ऐसा फ़ोल्डर हो जिसका नाम ‘page-’ से शुरू होता है, जैसे ‘page-templates’। इस बनावट के उदाहरणों में Twenty Twelve, Twenty Fourteen, Neve, Hestia और Sydney आते हैं। इस फ़ोल्डर के रास्ते से साँचे की खोज थीम के बाहर पहुँच सकती है।
सर्वर पर लक्ष्य: चुनी हुई स्थानीय फ़ाइल का नाम ‘.php’ पर खत्म हो और वेब सर्वर का खाता उसे पढ़ सके। कोड चलने के लिए उस फ़ाइल का व्यवहार और PHP विन्यास भी अनुकूल होना चाहिए। ‘pearcmd.php’ के साथ ‘register_argc_argv’ चालू होना ऐसे मेल का एक उदाहरण है।

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

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

अपनी शाखा के लिए कौन-सा संस्करण लगाएँ

7.1.2 मौजूदा 7.1 शाखा का सुधार है। पहले की शाखाओं में यही खामी अलग सुरक्षा संस्करणों से सुधारी गई है, इसलिए पूरी संस्करण संख्या को एक ही क्रम में देखकर पैच की स्थिति तय नहीं की जा सकती। नीचे तीर के बाईं ओर शाखा है और दाईं ओर उस शाखा का इस खामी के लिए सुधरा संस्करण; उदाहरण के लिए 6.8 स्थापना का मिलान 6.8.10 से होगा, 6.9.9 से नहीं।

7.1 → 7.1.2; 7.0 → 7.0.6; 6.9 → 6.9.9; 6.8 → 6.8.10; 6.7 → 6.7.9।
6.6 → 6.6.9; 6.5 → 6.5.12; 6.4 → 6.4.12; 6.3 → 6.3.12; 6.2 → 6.2.13।
6.1 → 6.1.14; 6.0 → 6.0.16; 5.9 → 5.9.18; 5.8 → 5.8.17; 5.7 → 5.7.19।
5.6 → 5.6.21; 5.5 → 5.5.22; 5.4 → 5.4.23; 5.3 → 5.3.25; 5.2 → 5.2.28।
5.1 → 5.1.26; 5.0 → 5.0.29; 4.9 → 4.9.33; 4.8 → 4.8.32; 4.7 → 4.7.37।

हर पंक्ति में दाईं ओर दी गई संख्या उसी शाखा का पहला सुधरा संस्करण है। उदाहरण के लिए 7.0.5 प्रभावित है और 7.0.6 में यह सुधार मौजूद है; इसी तरह 4.7.36 प्रभावित है और 4.7.37 में पैच है। इस खामी का सुधार 4.7 शाखा तक सूचीबद्ध है। उससे पुरानी स्थापना के लिए इस सूची में पैच नहीं दिया गया है; उसे सूची के आखिरी अंक के आधार पर सुरक्षित नहीं माना जा सकता।

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

स्वचालित अद्यतन की सफलता कैसे पहचानें

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

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

कई साइटों का प्रबंधन करने वाले प्रशासक के लिए एक सफलता संदेश पर्याप्त नहीं होगा। 7.1.2 पर पहुँची साइट दूसरी साइट की 6.8 या 5.9 स्थापना की स्थिति नहीं बताती। जिस स्थापना में पुरानी संख्या बची है, उसमें बिना लॉगिन अनुरोध वाली खामी के विरुद्ध यह पैच अभी लागू नहीं हुआ है।

यह भी पढ़ें:

साझा करें: