22 सितंबर 2026 को, राष्ट्रीय दिवस की छुट्टी से एक दिन पहले, WordPress ने CVE-2026-87902 को बंद करने के लिए सुरक्षा अपडेट 7.1.2 जारी किया। यह खामी किसी प्लगइन या थीम में नहीं है। यह WordPress के कोर में है, और 4.7.0 से 7.1.1 तक के हर संस्करण को प्रभावित करती है। उसी दिन 11:49 UTC (रियाद समय के अनुसार दोपहर 2:49 बजे) सुरक्षा कंपनी Patchstack ने इसका फ़ायदा उठाने की पहली कोशिश देखी, और चार घंटे से भी कम समय बाद किसी साइट के सर्वर पर फ़ाइल लिखने की पहली कोशिश।

पाँच दिनों में हमला कैसे फैला

फिर यह फैल गया। आज, 28 सितंबर को प्रकाशित CrowdSec की रिपोर्ट के अनुसार, उसके नेटवर्क ने 23 से 27 सितंबर के बीच 30,813 अलग-अलग IP पतों से इस खामी से मेल खाते 322,680 हमले के संकेत दर्ज किए, जो 27 सितंबर को 124,154 संकेतों के साथ चरम पर पहुँचे। सऊदी अरब के राष्ट्रीय साइबर सुरक्षा प्राधिकरण (NCA) ने 23 सितंबर को गंभीर श्रेणी का अलर्ट, संख्या 2026-7873, जारी किया, और अमेरिकी एजेंसी CISA ने 25 सितंबर को इस खामी को ज्ञात शोषित कमज़ोरियों की अपनी सूची में जोड़ा।

आसान शब्दों में, यह खामी क्या करती है

जब कोई विज़िटर कोई पेज माँगता है, तो WordPress तय करता है कि उसे दिखाने के लिए थीम की कौन-सी टेम्पलेट फ़ाइल इस्तेमाल करनी है। बग इसी चरण में है: लॉग इन न किया हुआ हमलावर इसे थीम फ़ोल्डर के बाहर सर्वर पर पड़ी किसी PHP फ़ाइल की ओर मोड़ सकता है, और WordPress उसे चला देगा। WordPress इस खामी को 10 में से 9.2 अंक देता है; CISA इसे 8.1 अंक देती है।

यह साइट पर नियंत्रण में तब बदलती है जब WordPress की सलाह और शोधकर्ताओं की रिपोर्टों में बताई गई शर्तें एक साथ पूरी होती हैं:

  • थीम: सक्रिय थीम में एक फ़ोल्डर है जिसका नाम page- से शुरू होता है। सलाह में ऐसी थीमों में Twenty Twelve, Twenty Fourteen, Neve, Hestia और Sydney के नाम हैं।
  • एक PHP सेटिंग: register_argc_argv चालू है, जो CrowdSec के अनुसार आधिकारिक PHP Docker इमेज में और 8.5 से पुराने PHP वाले cPanel सर्वरों पर डिफ़ॉल्ट है।
  • एक सहायक फ़ाइल: PEAR की pearcmd.php सर्वर पर मौजूद है। हमलावर इसका इस्तेमाल नई PHP फ़ाइलें लिखने के लिए करते हैं, यानी एक बैकडोर जो अपडेट के बाद भी बचा रहता है।

इसलिए यह खामी हर साइट पर एक जैसा असर नहीं डालती, लेकिन Security Affairs इसे यूँ सार में कहता है: कोड चलाने के लिए सर्वर की सेटिंग का मेल खाना ज़रूरी है, और बहुत-से सर्वरों में यह मेल खाती है। एक कारोबारी मालिक को आम तौर पर पता नहीं होता कि कौन-सी थीम सक्रिय है या सर्वर कैसे कॉन्फ़िगर है, इसलिए सुरक्षित मान्यता यही है कि जब तक उलटा साबित न हो, साइट ख़तरे में है।

हमला हफ़्तों में नहीं, घंटों में क्यों आया

सुरक्षा अपडेट अपने स्वभाव से ही बता देता है कि बग कहाँ है, क्योंकि कोड में बदलाव सार्वजनिक होता है। Patchstack कहता है कि पहले पेलोड ठीक उसी पैटर्न से मेल खाते थे जिसे सुधार ने बंद किया, यानी उन्हें लिखने वाले ने किसी स्वतंत्र खोज से नहीं, बल्कि सुधार से ही काम शुरू किया। पहली कोशिशों में साइटों की प्रतिक्रिया देखने के लिए wp-login.php और wp-cron.php जैसी सामान्य WordPress कोर फ़ाइलें माँगी गईं, और फिर फ़ाइलें लिखने की ओर बढ़ा गया।

इस ट्रैफ़िक में ऑटोमेटेड स्कैनरों और प्रकाशित प्रूफ़-ऑफ़-कॉन्सेप्ट कोड के निशान भी हैं। एक कारोबारी मालिक के लिए इसका मतलब है कि कोई ख़ास तौर पर आपकी साइट नहीं चुन रहा। ये टूल हर उस WordPress साइट को खंगालते हैं जहाँ तक वे पहुँच सकते हैं, और हैक हुई साइट और साफ़ साइट के बीच फ़र्क़ बस इतना है कि अपडेट उनसे पहले पहुँचा या नहीं।

क्या आपकी साइट अपने आप अपडेट होती है?

शायद, लेकिन ऐसा मानकर न चलें। WordPress में संस्करण 3.7 से ऑटोमैटिक बैकग्राउंड अपडेट हैं, और 5.6 से नई इंस्टॉलेशन माइनर और मेजर दोनों रिलीज़ अपने आप अपडेट करती हैं। 7.1.2 की घोषणा कहती है कि जो साइटें ऑटोमैटिक बैकग्राउंड अपडेट का समर्थन करती हैं, वे अपने आप अपडेट होना शुरू कर देंगी।

लेकिन ऑटोमैटिक अपडेट wp-config.php में एक लाइन से बंद किए जा सकते हैं। कुछ डेवलपर इन्हें जान-बूझकर बंद करते हैं ताकि कोई अपडेट कस्टमाइज़ की गई थीम को न तोड़े, और कुछ होस्टिंग कंपनियाँ अपडेट अपनी ओर से संभालती हैं। सालों पहले किसी फ़्रीलांसर की बनाई साइट, जिसका अनुबंध कब का ख़त्म हो चुका है, किसी पुराने संस्करण पर पड़ी रह सकती है और किसी को पता भी नहीं चलता। जाँचने के लिए:

  • साइट के एडमिन में लॉग इन करें, डैशबोर्ड मेनू के तहत अपडेट पेज खोलें, और वहाँ आपको मौजूदा संस्करण दिखेगा।
  • सुरक्षित संस्करण 7.1.2 या उसके बाद का है। अगर आपकी साइट किसी पुरानी ब्रांच पर है, तो सुधार 4.7 तक की हर ब्रांच तक पहुँचा है, जिनमें 7.0.6, 6.9.9, 6.8.10 और 4.7.37 शामिल हैं; पूरी सूची स्रोतों में लिंक की गई WordPress सलाह में है।
  • ध्यान दें कि WordPress के अनुसार केवल सबसे नए संस्करण को ही सक्रिय समर्थन मिलता है। पुरानी ब्रांच पर छोड़ी गई साइट को यह सुधार तो मिल गया, लेकिन वह उधार के समय पर चल रही है। नया संस्करण किसी कंपनी की वेबसाइट के लिए क्या लाता है, यह हमने WordPress 7.1: मुख्य नई सुविधाएँ में बताया है।

Elementor भी: एक लिंक काफ़ी है

उसी हफ़्ते, लोकप्रिय WordPress पेज बिल्डर Elementor ने एक खामी ठीक की जो केवल संस्करण 4.3.0 और 4.3.1 में थी। अगर कोई साइट एडमिनिस्ट्रेटर लॉग इन रहते हुए ख़ास तौर पर तैयार किया गया लिंक खोलता है, तो हमलावर अपने नियंत्रण वाला एडमिनिस्ट्रेटर खाता बना सकता है, और यह लिंक ईमेल, चैट या कमेंट से आ सकता है। BleepingComputer के अनुसार, ये संस्करण 2 मिलियन तक साइटों पर चलते हैं। सुधार 24 सितंबर को 4.3.2 में आया, और प्रकाशन के समय उस साइट ने किसी सक्रिय शोषण की सूचना नहीं दी थी।

सुनिश्चित करें कि Elementor 4.3.2 या उसके बाद के संस्करण पर है, और इसे टीम का नियम बनाएँ: साइट के एडमिन में लॉग इन रहते हुए संदेशों या कमेंट के लिंक न खोलें।

अगर आपकी साइट 22 सितंबर से अपडेट नहीं हुई है

  • अभी अपडेट करें: अगर डेवलपर को डर है कि अपडेट से कुछ टूट जाएगा, तो Patchstack के अनुसार pagename पैरामीटर में डायरेक्टरी ट्रैवर्सल की कोशिशों को ब्लॉक करके, या register_argc_argv को बंद करके यह रास्ता अस्थायी रूप से बंद किया जा सकता है। यह होस्टिंग कंपनी या डेवलपर का काम है, और यह अपडेट की जगह नहीं लेता।
  • मानकर चलें कि आपकी साइट की टोह ली गई है: डेवलपर या होस्टिंग कंपनी से ऐसी PHP फ़ाइलें खोजने को कहें जिन्हें किसी ने नहीं जोड़ा, ख़ासकर /tmp और /var/tmp में, जहाँ Patchstack ने poc87902.php और wp-pear-rce-flag.php जैसी फ़ाइलों को सफल कोड निष्पादन का संकेत बताया है।
  • अगर कुछ मिले: इसे अपडेट नहीं, एक घटना मानकर संभालें। एडमिन खातों, डेटाबेस और होस्टिंग के पासवर्ड बदलें, साइट को किसी साफ़ बैकअप से बहाल करें, फिर उसे अपडेट करें।
  • अगर साइट में ग्राहकों का डेटा है: यानी वह ऑर्डर, संपर्क फ़ॉर्म या खाते संग्रहीत करती है, तो सऊदी डेटा और आर्टिफ़िशियल इंटेलिजेंस प्राधिकरण (SDAIA) की व्यक्तिगत डेटा उल्लंघन की घटनाओं से जुड़ी गाइड के अनुसार नियंत्रक को ऐसे उल्लंघन की जानकारी मिलने के 72 घंटों के भीतर सक्षम प्राधिकरण को सूचित करना होता है जो डेटा या उससे जुड़े लोगों को नुक़सान पहुँचा सकता है।

Origami की राय

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

इसीलिए हमारा मानना है कि वेबसाइट रखरखाव अनुबंध में गंभीर सुरक्षा अपडेट इंस्टॉल करने की अधिकतम समय-सीमा तय होनी चाहिए, एक स्टेजिंग कॉपी अनिवार्य होनी चाहिए जहाँ अपडेट लाइव साइट से पहले टेस्ट हों, और सर्वर से बाहर रखे गए नियमित बैकअप होने चाहिए। और अगर अपडेट इसलिए टलते रहते हैं कि थीम इस तरह कस्टमाइज़ की गई है कि हर अपडेट पर टूट जाती है, तो यह WordPress की नहीं, साइट बनाने के तरीक़े की समस्या है, और इसे अगली खामी से पहले ठीक किया जाना चाहिए।

निष्कर्ष: तीन क़दम

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

स्रोत