तात्कालिक: Awesome Support (≤ 6.3.6) में टूटी हुई पहुँच नियंत्रण — वर्डप्रेस साइट के मालिकों को अब क्या करना चाहिए

तारीख: 16 जनवरी, 2026
CVE: CVE-2025-12641
गंभीरता: मध्यम (CVSS 6.5)
प्रभावित संस्करण: Awesome Support ≤ 6.3.6
में ठीक किया गया: 6.3.7

एक हांगकांग सुरक्षा विशेषज्ञ के रूप में, मैं वर्डप्रेस पारिस्थितिकी तंत्र की निगरानी करता हूँ और साइट ऑपरेटरों को व्यावहारिक, प्राथमिकता वाले उत्तरों पर सलाह देता हूँ। Awesome Support प्लगइन (संस्करण 6.3.6 तक) में एक टूटी हुई पहुँच नियंत्रण भेद्यता अनधिकृत अनुरोधों को विशेषाधिकार प्राप्त क्रियाएँ करने की अनुमति देती है जो प्रभावित साइट पर उपयोगकर्ता भूमिकाओं को कम कर सकती हैं। विक्रेता ने 6.3.7 में एक सुधार जारी किया है, लेकिन कई इंस्टॉलेशन बिना पैच के और जोखिम में हैं।.

यह सलाह समझाती है:

• यह भेद्यता वर्डप्रेस साइटों के लिए क्यों महत्वपूर्ण है
• यह पुष्टि करने के लिए कि आपकी साइट प्रभावित है या नहीं
• तात्कालिक निवारण जो आप लागू कर सकते हैं
• दीर्घकालिक सख्ती और घटना प्रतिक्रिया कदम

कार्यकारी सारांश

• समस्या: टूटी हुई पहुँच नियंत्रण — Awesome Support में एक अनुपस्थित प्राधिकरण जांच जो अनधिकृत अनुरोधों को विशेषाधिकार प्राप्त क्रियाएँ (भूमिका कम करना) करने की अनुमति देती है।.
• प्रभाव: भूमिका छेड़छाड़ (प्रशासक का कम होना, विशेषाधिकार में कमी), जो स्थायीता या पूर्ण समझौते के लिए एक कदम हो सकता है।.
• तात्कालिक सुधार: Awesome Support को 6.3.7 या बाद के संस्करण में अपडेट करें।.
• यदि आप तुरंत अपडेट नहीं कर सकते: प्लगइन को निष्क्रिय करें या फ़ायरवॉल/WAF स्तर पर रक्षात्मक नियम लागू करें, फिर नीचे दिए गए घटना-प्रतिक्रिया कदमों का पालन करें।.

पृष्ठभूमि: वर्डप्रेस के लिए “टूटी हुई पहुँच नियंत्रण” का क्या अर्थ है

टूटी हुई पहुँच नियंत्रण उन मामलों को कवर करता है जहाँ प्राधिकरण जांच अनुपस्थित या गलत हैं। वर्डप्रेस में, संवेदनशील संचालन (भूमिकाएँ बदलना, उपयोगकर्ताओं को संपादित करना, प्लगइन सेटिंग्स को संशोधित करना) यह सुनिश्चित करना चाहिए कि अनुरोधकर्ता प्रमाणित है और उसके पास आवश्यक क्षमता है (उदाहरण के लिए, manage_options या edit_users), और कि nonce/referrer जांच मान्य हैं।.

यदि एक प्लगइन इन जांचों को छोड़ देता है, तो अनधिकृत स्क्रिप्टेड अनुरोध ऐसे कार्य कर सकते हैं जैसे उपयोगकर्ताओं को बनाना या कम करना और सेटिंग्स को बदलना। यह Awesome Support समस्या एक अंत बिंदु पर तैयार अनधिकृत अनुरोधों को भूमिका कम करने का कारण बनाती है — यह हमलावरों के लिए एक खतरनाक कदम है जो प्रशासनिक खातों को कमजोर करने और स्थिरता स्थापित करने का लक्ष्य रखते हैं।.

प्रभाव विश्लेषण: एक हमलावर क्या कर सकता है और यह क्यों महत्वपूर्ण है

• एक प्रशासक को एक निम्न भूमिका में कम करना, उनके प्लगइनों, उपयोगकर्ताओं, या सुरक्षा सेटिंग्स को प्रबंधित करने की क्षमता को हटाना — अक्सर चुपचाप।.
• अलर्ट को निष्क्रिय करने, पुनर्प्राप्ति क्रियाओं को बाधित करने, या नियंत्रण पुनः प्राप्त करने के लिए सामाजिक-इंजीनियरिंग के साथ संयोजन करने के लिए कम करने का उपयोग करें।.
• अन्य भेद्यताओं के साथ कम करने की श्रृंखला बनाकर बैकडोर बनाना, खाते जोड़ना, या सामग्री को संशोधित करना।.
• स्वचालित स्कैनर और अवसरवादी हमलावर ज्ञात कमजोर प्लगइन एंडपॉइंट्स के लिए स्कैन करते हैं और उन्हें बड़े पैमाने पर शोषण कर सकते हैं।.

यह कैसे तय करें कि आप प्रभावित हैं

1. Awesome Support प्लगइन संस्करण जांचें: WordPress डैशबोर्ड → प्लगइन्स → Awesome Support — यदि ≤ 6.3.6 तो आप प्रभावित हैं।.
2. 16 जनवरी 2026 के आसपास और पहले संदिग्ध गतिविधियों के लिए लॉग की जांच करें:
   • प्लगइन एंडपॉइंट्स पर अप्रत्याशित POST/GET।.
   • अचानक भूमिका-परिवर्तन घटनाएँ, विशेष रूप से प्रशासक खातों का पदावनन।.
   • उच्च विशेषाधिकार वाले नए खाते या क्षमता स्तरों में परिवर्तन।.
3. भूमिका-परिवर्तन घटनाओं और संबंधित आईपी पतों के लिए उपयोगकर्ता ऑडिट लॉग की समीक्षा करें (यदि उपलब्ध हो)।.
4. वर्तमान उपयोगकर्ता भूमिकाओं और प्लगइन फ़ाइलों की तुलना हाल के बैकअप या प्रकटीकरण से पहले लिए गए स्नैपशॉट्स के साथ करें।.

तत्काल शमन (चरण-दर-चरण)

1. Awesome Support को 6.3.7 या बाद के संस्करण में अपडेट करें — यदि संभव हो तो पहले यह करें। महत्वपूर्ण साइटों के लिए, जब समय मिले तो स्टेजिंग पर परीक्षण करें; अन्यथा अपडेट के लिए एक छोटा रखरखाव विंडो लागू करें।.
2. यदि आप तुरंत पैच नहीं कर सकते हैं, तो ये तात्कालिक कार्रवाई करें:
   • हमले की सतह को हटाने के लिए अस्थायी रूप से Awesome Support प्लगइन को अक्षम करें।.
   • उन प्लगइन एंडपॉइंट्स पर अनधिकृत POST/GET अनुरोधों को अवरुद्ध करने वाले फ़ायरवॉल या WAF नियम लागू करें जो भूमिकाएँ या उपयोगकर्ता विशेषताओं को बदल सकते हैं (नीचे उदाहरण)।.
   • संदिग्ध आईपी और स्वचालित स्कैनिंग पैटर्न को अवरुद्ध या दर-सीमा करें।.
   • जहां संभव हो, आईपी अनुमति सूचियों के साथ प्लगइन एंडपॉइंट्स तक पहुंच को प्रतिबंधित करें (केवल प्रशासक नेटवर्क)।.
3. प्रशासक पासवर्ड को घुमाएँ और सभी प्रशासक खातों के लिए दो-कारक प्रमाणीकरण (2FA) की आवश्यकता करें।.
4. संदिग्ध परिवर्तनों के लिए उपयोगकर्ता खातों की जांच करें; सत्यापन के बाद ही किसी भी पदावनत प्रशासकों को फिर से सक्षम करें।.
5. यदि आप समझौते के सबूत (अज्ञात फ़ाइलें, अनुसूचित कार्य, नए खाते) पाते हैं, तो साइट को अलग करें, ज्ञात-भले बैकअप से पुनर्स्थापित करें, और फोरेंसिक समीक्षा करें।.

WAF / वर्चुअल पैचिंग: अब क्या करें (अनुशंसित नियम और पैटर्न)

एक फ़ायरवॉल या WAF आपको प्लगइन को अपडेट करने से पहले तत्काल शमन प्रदान कर सकता है। नीचे उन रक्षात्मक नियम पैटर्न हैं जिन्हें आप होस्टिंग फ़ायरवॉल, WAF, या रिवर्स-प्रॉक्सी में लागू कर सकते हैं। ये उदाहरण वैचारिक हैं; इन्हें अपने वातावरण के अनुसार अनुकूलित करें और सटीक शोषण पेलोड प्रकाशित न करें।.

उदाहरण 1 — प्लगइन-संवेदनशील एंडपॉइंट्स पर अप्रमाणित अनुरोधों को ब्लॉक करें

लॉजिक: यदि अनुरोध admin-ajax.php या प्लगइन पथों को लक्षित करता है और भूमिका/उपयोगकर्ता संशोधन से संबंधित पैरामीटर शामिल करता है, और कोई वर्डप्रेस प्रमाणीकरण कुकी मौजूद नहीं है, तो इसे ब्लॉक करें।.

यदि (request.uri.path ~ /admin-ajax.php/ या request.uri.path ~ /wp-content/plugins/awesome-support/) और

उदाहरण 2 — दर-सीमा निर्धारित करें और स्कैनिंग पैटर्न को ब्लॉक करें

यदि (IP द्वारा "/wp-content/plugins/awesome-support/" के लिए अनुरोध > 10 60 सेकंड में) {

उदाहरण 3 — प्रशासनिक क्रियाओं के लिए वैध नॉनसेस या रेफरर्स की कमी वाले अनुरोधों को ब्लॉक करें

यदि (request.method == POST और request.body में "role" या "user_id" है) {

उदाहरण 4 — HTTP के माध्यम से प्लगइन PHP फ़ाइलों के लिए सीधे पहुंच को अस्वीकार करें

<FilesMatch "\.(php)$">
    Require all denied
</FilesMatch>
# Allow admin-ajax and front-end required files as needed

सावधान रहें: अत्यधिक व्यापक अस्वीकृति नियम कार्यक्षमता को तोड़ सकते हैं। यदि आप सुनिश्चित नहीं हैं तो लक्षित WAF वर्चुअल पैचिंग को प्राथमिकता दें।.

पहचान: समझौते के संकेत (IoCs) और निरीक्षण के लिए लॉग

• ऑडिट लॉग में अप्रत्याशित भूमिका-परिवर्तन घटनाएँ: प्रशासन → संपादक/सदस्य।.
• जब कोई प्रशासनिक सक्रिय नहीं था, तब बाहरी IP से प्लगइन एंडपॉइंट्स पर POST अनुरोध।.
• भूमिका परिवर्तनों या कॉन्फ़िगरेशन अपडेट के बाद लॉगिन विफलताएँ।.
• प्रकटीकरण समय के आसपास नए प्रशासनिक स्तर के खाते बनाए गए।.
• wp-content/uploads या प्लगइन फ़ोल्डरों में अज्ञात PHP फ़ाइलें जोड़ी गईं।.
• अपरिचित IPs/डोमेन के लिए आउटबाउंड कनेक्शन (संभव C2 कॉलबैक)।.

कहाँ देखें:

• admin-ajax.php, प्लगइन पथों, या अजीब क्वेरी स्ट्रिंग्स के लिए वेब सर्वर पहुंच और त्रुटि लॉग।.
• वर्डप्रेस debug.log (यदि सक्षम हो) और प्लगइन-विशिष्ट लॉग।.
• फ़ाइल संशोधनों और क्रॉन नौकरियों के लिए होस्टिंग नियंत्रण पैनल लॉग।.
• टाइमस्टैम्प किए गए अंतर के लिए बैकअप।.

यदि आपको संदिग्ध गतिविधि मिले:

• फोरेंसिक विश्लेषण के लिए लॉग और सबूतों को संरक्षित करें।.
• आगे के परिवर्तनों से पहले साइट या फ़ाइल प्रणाली का स्नैपशॉट लें।.
• यदि आपको सहायता की आवश्यकता हो तो एक विश्वसनीय सुरक्षा पेशेवर या आपके होस्ट की घटना टीम से संपर्क करें।.

घटना प्रतिक्रिया प्लेबुक (व्यावहारिक अनुक्रम)

1. शामिल करें:
   • कमजोर प्लगइन को निष्क्रिय करें।.
   • जांच करते समय साइट को रखरखाव मोड में डालें या ट्रैफ़िक को प्रतिबंधित करें।.
   • शोषण पैटर्न को ब्लॉक करने के लिए फ़ायरवॉल/WAF नियम लागू करें।.
2. जांच करें:
   • लॉग इकट्ठा करें (वेब, एप्लिकेशन, होस्टिंग)।.
   • परिवर्तनों की पहचान करें (उपयोगकर्ता, फ़ाइलें, अनुसूचित कार्य)।.
   • समझौते का समय और प्रवेश वेक्टर निर्धारित करें।.
3. समाप्त करें:
   • बैकडोर, अज्ञात फ़ाइलें और अनधिकृत उपयोगकर्ताओं को हटा दें।.
   • प्लगइन अपडेट को 6.3.7 या बाद के संस्करण में लागू करें।.
   • व्यवस्थापक क्रेडेंशियल और API कुंजी को घुमाएँ; पासवर्ड रीसेट करने के लिए मजबूर करें।.
4. पुनर्प्राप्त करें:
   • यदि आवश्यक हो तो एक साफ बैकअप से पुनर्स्थापित करें।.
   • यदि कोर अखंडता संदिग्ध है तो साइट को फिर से बनाएं।.
   • खातों को मजबूत करें (2FA, न्यूनतम विशेषाधिकार, प्लगइन ऑडिट)।.
5. सीखे गए पाठ:
   • समीक्षा करें कि प्लगइन पैच क्यों नहीं हुआ।.
   • पैचिंग शेड्यूल और निगरानी लागू करें।.
   • अपडेट में देरी को कम करने के लिए परीक्षण और स्टेजिंग वर्कफ़्लो में सुधार करें।.

हार्डनिंग चेकलिस्ट: अपने हमले की सतह को कम करें

• सहमति SLA के भीतर WordPress कोर, थीम और प्लगइन्स को अपडेट रखें।.
• न्यूनतम विशेषाधिकार लागू करें: प्रशासनिक खातों को सीमित करें और उपयुक्त भूमिकाओं का उपयोग करें।.
• उच्च विशेषाधिकार वाले उपयोगकर्ताओं के लिए दो-कारक प्रमाणीकरण की आवश्यकता है।.
• उपयोगकर्ता और भूमिका परिवर्तनों के लिए ऑडिट लॉगिंग बनाए रखें।.
• अप्रयुक्त प्लगइन्स और थीम्स को हटा दें।.
• दूरस्थ, अपरिवर्तनीय भंडारण में बैकअप रखें और नियमित रूप से पुनर्स्थापनों का परीक्षण करें।.
• प्रशासनिक पहुंच को मजबूत करें: जहां संभव हो /wp-admin और wp-login.php को प्रतिबंधित करें।.
• मजबूत, अद्वितीय पासवर्ड और एक पासवर्ड प्रबंधक का उपयोग करें।.
• फ़ाइल अखंडता निगरानी और नियमित मैलवेयर स्कैनिंग लागू करें।.
• अनावश्यक सेवाओं या सर्वर प्रबंधन पोर्ट को उजागर करने से बचें।.

शमन के बाद परीक्षण और मान्यता

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

आभासी पैचिंग क्यों उपयोगी है

आभासी पैचिंग (फायरवॉल/WAF पर लक्षित नियम लागू करना) आपको कोड अपडेट को सुरक्षित रूप से परीक्षण और लागू करने का समय देती है। यह विशेष रूप से उपयोगी है जब:

• तात्कालिक अपडेट के लिए उच्च-उपलब्धता साइटों के लिए स्टेजिंग और पुनरावृत्ति परीक्षण की आवश्यकता होती है।.
• कई साइटों को केंद्रीय रूप से सुरक्षित किया जाना चाहिए जबकि अपडेट लागू किए जा रहे हैं।.
• आपको परिवर्तन-नियंत्रण प्रक्रियाओं का पालन करते हुए तेजी से जोखिम को कम करने की आवश्यकता है।.

आभासी पैच सटीक होने चाहिए ताकि वैध ट्रैफ़िक को बाधित न करें।.

साइट के मालिकों को क्या बचना चाहिए

• अपडेट को नजरअंदाज करना - देरी जोखिम को बढ़ाती है।.
• हमलावरों की मदद करने वाले शोषण विवरण या PoC डेटा को सार्वजनिक रूप से प्रकाशित करना।.
• कमजोर, डिफ़ॉल्ट, या साझा प्रशासनिक खातों का उपयोग करना।.
• जोखिम को खारिज करना क्योंकि प्लगइन “महत्वपूर्ण नहीं है” - हमलावर भूमिका प्रबंधन का शोषण करके अन्यत्र बढ़ते हैं।.

नमूना घटना: एक हमलावर श्रृंखला कैसे विकसित हो सकती है

1. स्वचालित स्कैनर कमजोर प्लगइन एंडपॉइंट का पता लगाते हैं।.
2. अप्रमाणित अनुरोध एक प्रशासक को पदावनत करते हैं।.
3. हमलावर कमजोर प्रशासनिक नियंत्रण या सामाजिक-इंजीनियरिंग का उपयोग करके आगे के पांव जमाता है।.
4. बैकडोर या नए उच्च-विशेषाधिकार खाते किसी अन्य कमजोरियों या समझौता किए गए प्रशासनिक प्रवाह के माध्यम से स्थापित किए जाते हैं।.
5. डेटा निकासी, स्पैम इंजेक्शन, या पूर्ण साइट अधिग्रहण होता है।.

पुनर्प्राप्ति चेकलिस्ट (घटना के बाद)

• प्लगइन को 6.3.7 या बाद के संस्करण में अपडेट करें।.
• प्रशासनिक क्रेडेंशियल्स को रीसेट करें और API कुंजियों को घुमाएं।.
• अनधिकृत खातों और अनुसूचित कार्यों को हटा दें।.
• मैलवेयर, बैकडोर, या इंजेक्टेड कोड के लिए स्कैन करें।.
• यदि आवश्यक हो, तो साफ बैकअप से समझौता किए गए फ़ाइलों को पुनर्स्थापित करें।.
• निगरानी को फिर से सक्षम करें और पुनरावृत्ति को रोकने के लिए एक पैचिंग SLA लागू करें।.

प्रबंधित सुरक्षा और तीसरे पक्ष की सहायता

यदि आपको सहायता की आवश्यकता है, तो एक विश्वसनीय सुरक्षा पेशेवर, आपके होस्टिंग प्रदाता, या एक प्रबंधित सुरक्षा टीम से संपर्क करें। पूछें:

• सबूत कि पैच लागू किया गया था (परिवर्तन लॉग, संस्करण सत्यापन)।.
• रोकथाम के बाद अवरुद्ध शोषण प्रयासों को दिखाने वाले लॉग या रिपोर्ट।.
• महत्वपूर्ण साइटों के लिए सुरक्षित स्टेजिंग और अपडेट प्रक्रियाओं पर मार्गदर्शन।.

शासन और प्रक्रिया: पैचिंग अंतर को कम करें

• एक प्लगइन सूची और प्राथमिकता सूची बनाए रखें; महत्वपूर्ण प्लगइनों की निकटता से निगरानी करें।.
• एक पैचिंग SLA परिभाषित करें (उदाहरण के लिए, महत्वपूर्ण पैच 48-72 घंटों के भीतर लागू किए जाते हैं)।.
• स्टेजिंग परीक्षणों को स्वचालित करें ताकि अपडेट को जल्दी से मान्य किया जा सके।.
• प्लगइन संस्करणों के लिए केंद्रीकृत निगरानी का उपयोग करें और कमजोर घटकों के लिए स्वचालित अलर्ट।.

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

प्रश्न: यदि मैं 6.3.7 में अपडेट करता हूं, तो क्या मैं पूरी तरह से सुरक्षित हूं?
उत्तर: अपडेट इस विशिष्ट कमजोरियों को ठीक करता है। साथ ही, मैलवेयर स्कैन चलाएं, समझौते के संकेतों की जांच करें, और लॉग की निगरानी करें। अपडेट जोखिम को कम करते हैं लेकिन व्यापक सुरक्षा स्वच्छता का स्थान नहीं लेते।.

प्रश्न: क्या मैं अपडेट करने के बजाय WAF पर भरोसा कर सकता हूं?
उत्तर: WAFs मजबूत रोकथाम हैं लेकिन कोड अपडेट का विकल्प नहीं हैं। वे कुछ हमले के वेक्टर को छोड़ सकते हैं या गलत सकारात्मक बना सकते हैं। जैसे ही यह सुरक्षित हो, अपडेट करें।.

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

प्राथमिकता वाली कार्रवाई सूची

1. Awesome Support संस्करण की पुष्टि करें। यदि ≤ 6.3.6 है, तो 6.3.7+ के लिए तत्काल अपडेट का कार्यक्रम बनाएं।.
2. यदि आप तुरंत अपडेट नहीं कर सकते हैं, तो प्लगइन को निष्क्रिय करें या साइट को रखरखाव मोड में डालें।.
3. प्लगइन एंडपॉइंट्स पर अप्रमाणित अनुरोधों को अवरुद्ध करने के लिए फ़ायरवॉल या WAF नियम लागू करें; दर-सीमा और IP प्रतिष्ठा अवरोध का उपयोग करें।.
4. क्रेडेंशियल्स को घुमाएं और प्रशासनिक उपयोगकर्ताओं के लिए 2FA लागू करें।.
5. अप्रत्याशित पदावनति या नए प्रशासनिक खातों के लिए उपयोगकर्ता भूमिकाओं का ऑडिट करें।.
6. मैलवेयर स्कैन और फ़ाइल-इंटीग्रिटी जांच चलाएं।.
7. अवरुद्ध शोषण प्रयासों के लिए लॉग की निगरानी करें और आवश्यकतानुसार नियमों को समायोजित करें।.
8. एक पैचिंग SLA और स्वचालित निगरानी का दस्तावेज़ीकरण और कार्यान्वयन करें।.

समापन: रक्षा को प्राथमिकता दें

टूटी हुई पहुंच नियंत्रण बग insidious होते हैं क्योंकि वे व्यावसायिक-तर्क कोड में रहते हैं जिसे डेवलपर्स मानते हैं कि केवल प्रमाणित उपयोगकर्ताओं द्वारा ही कॉल किया जाएगा। वर्डप्रेस साइट मालिकों के लिए व्यावहारिक takeaway सरल है: प्लगइन अपडेट और फ़ायरवॉल सुरक्षा को संचालन आवश्यकताओं के रूप में मानें। अब Awesome Support को 6.3.7 में अपडेट करें, या आभासी पैचिंग लागू करें और जब तक आप अपडेट और सुरक्षा की पुष्टि नहीं कर लेते तब तक प्लगइन को अक्षम करें। भूमिकाओं और लॉग की समीक्षा करें - फिर पैचिंग और निगरानी प्रक्रियाओं को मजबूत करें ताकि स्वचालित शोषण के लिए जोखिम को कम किया जा सके।.

यदि आपको एक संक्षिप्त चेकलिस्ट या आपके होस्टिंग वातावरण के लिए अनुकूलित एक पूर्व-निर्मित WAF नियम की आवश्यकता है, तो उत्तर दें:

• होस्टिंग प्रकार (साझा, cPanel, nginx, Apache, प्रबंधित WP होस्ट)
• क्या आपके पास पहले से एक WAF है (और यदि ज्ञात है तो कौन सा प्रकार)
• क्या आप अपडेट के लिए साइट को अस्थायी रूप से ऑफ़लाइन ले जा सकते हैं

मैं नियमों और एक चरण-दर-चरण योजना का मसौदा तैयार करूंगा जिसे आप लागू कर सकते हैं या अपने होस्ट को सौंप सकते हैं।.