पृष्ठभूमि और त्वरित तथ्य

• भेद्यता: प्रमाणित (व्यवस्थापक) स्टोर्ड क्रॉस-साइट स्क्रिप्टिंग (XSS)
• प्रभावित सॉफ़्टवेयर: लिंक हॉपर (प्लगइन) — संस्करण ≤ 2.5
• CVE: CVE-2025-15483
• खोजा गया: ZAST.AI (सुरक्षा शोधकर्ताओं द्वारा सार्वजनिक रूप से रिपोर्ट किया गया)
• शोषण की पूर्वापेक्षाएँ: हमलावर को एक ऐसा तरीका चाहिए जिससे वह एक व्यवस्थापक को एक दुर्भावनापूर्ण मान प्रस्तुत या सहेजने के लिए मजबूर कर सके (उदाहरण के लिए, व्यवस्थापक को एक तैयार की गई व्यवस्थापक पृष्ठ के साथ इंटरैक्ट करने के लिए धोखा देकर या उन्हें सामग्री चिपकाने के लिए मनाकर)।.
• प्रभाव: स्टोर्ड XSS — पेलोड साइट पर बना रहता है। जब एक व्यवस्थापक या अन्य उपयोगकर्ता जिसे पहुंच है, स्टोर किया गया मान देखता है (या जब मेहमान एक सार्वजनिक पृष्ठ देखते हैं जो इसे प्रस्तुत करता है), तो दुर्भावनापूर्ण JavaScript पीड़ित के ब्राउज़र के संदर्भ में निष्पादित होता है।.
• प्रकाशित गंभीरता: कम (पैच स्कोरिंग CVSS 5.9 को इंगित करती है), लेकिन व्यावसायिक प्रभाव स्टोर किए गए पेलोड और उन उपयोगकर्ताओं के विशेषाधिकारों पर निर्भर करता है जो इसके साथ इंटरैक्ट करते हैं।.

हालांकि शोषण के लिए पेलोड को स्टोर करने के लिए व्यवस्थापक इंटरैक्शन की आवश्यकता होती है, परिणाम गंभीर हो सकते हैं: साइट का विकृति, कोड निष्पादन के लिए पिवट (REST/API दुरुपयोग के माध्यम से), कुकी/सत्र चोरी, और चुपचाप स्थायी रहना। हांगकांग के सुरक्षा प्रैक्टिशनर के दृष्टिकोण से: व्यवस्थापक-फेसिंग स्टोर्ड XSS को उच्च प्राथमिकता वाले कंटेनमेंट आइटम के रूप में मानें।.

भेद्यता का तकनीकी सारांश

मूल कारण एक इनपुट मान्यता/आउटपुट एन्कोडिंग दोष है जो प्लगइन के hop_name पैरामीटर से संबंधित है। प्लगइन एक हॉप नाम स्वीकार करता है, इसे डेटाबेस में स्टोर करता है, और बाद में इसे प्रशासन UI और/या सार्वजनिक पृष्ठों में पर्याप्त सफाई या एस्केपिंग के बिना प्रस्तुत करता है। क्योंकि मान स्टोर किया गया है और बाद में प्रस्तुत किया गया है, एक दुर्भावनापूर्ण स्क्रिप्ट जो स्टोर की गई है hop_name एक स्थायी XSS पेलोड बन जाती है।.

प्रमुख तकनीकी बिंदु

• प्रकार: स्टोर्ड XSS (स्थायी) — दुर्भावनापूर्ण मार्कअप डेटाबेस में सहेजा जाता है।.
• इंजेक्शन बिंदु: hop_name पैरामीटर (जब “हॉप” जोड़ने या संपादित करने पर संभवतः एक POST पैरामीटर)।.
• आवश्यक विशेषाधिकार: व्यवस्थापक (साइट की उच्चतम भूमिका)।.
• उपयोगकर्ता इंटरैक्शन: आवश्यक — एक व्यवस्थापक को एक पृष्ठ लोड करना होगा या एक तैयार लिंक पर क्लिक करना होगा; व्यवस्थापक उच्च-मूल्य लक्ष्य है।.
• यहाँ स्टोर की गई XSS क्यों खतरनाक है: व्यवस्थापक विशेषाधिकार प्राप्त REST एंडपॉइंट्स और UI क्रियाओं तक पहुँचते हैं; उनके ब्राउज़र में चलने वाला एक स्क्रिप्ट प्रमाणित क्रियाएँ कर सकता है (उपयोगकर्ता बनाना, प्लगइन्स/थीम्स को संशोधित करना, रहस्यों को निकालना)।.

हम शोषण कोड प्रदान नहीं करेंगे। यह दस्तावेज़ पहचान और रक्षात्मक नियंत्रणों पर केंद्रित है।.

हमले के परिदृश्य और वास्तविक दुनिया का प्रभाव

व्यवस्थापक इंटरफेस में स्टोर की गई XSS को विभिन्न उच्च-प्रभाव वाले हमलों में जोड़ा जा सकता है। संभावित परिदृश्य में शामिल हैं:

1. विशेषाधिकार वृद्धि और अधिग्रहण

   इंजेक्टेड स्क्रिप्ट व्यवस्थापक सत्र कुकीज़, CSRF टोकन चुराती है, या एक नए व्यवस्थापक उपयोगकर्ता बनाने, बैकडोर स्थापित करने, या कॉन्फ़िगरेशन को संशोधित करने के लिए प्रमाणित अनुरोध जारी करती है।.

2. साइट-व्यापी सामग्री और SEO विषाक्तता

   हमलावर विज्ञापन, विषाक्त सामग्री, या बैकलिंक्स को उन पृष्ठों में इंजेक्ट करता है जो आगंतुकों के लिए दृश्य होते हैं, प्रतिष्ठा और खोज रैंकिंग को नुकसान पहुँचाते हैं।.

3. दुर्भावनापूर्ण रीडायरेक्ट और मैलवेयर वितरण

   स्क्रिप्ट आगंतुकों को फ़िशिंग या शोषण पृष्ठों पर रीडायरेक्ट करती है, जिससे खोज इंजनों द्वारा ब्लैकलिस्टिंग होती है।.

4. चुपचाप स्थायीता

   स्क्रिप्ट निर्धारित घटनाएँ (WP क्रॉन) बनाती है, PHP फ़ाइलें लिखती है, या दीर्घकालिक स्थिरता के लिए थीम/प्लगइन फ़ाइलों को संशोधित करती है।.

5. आपूर्ति-श्रृंखला शैली का हमला

   समझौता किए गए व्यवस्थापक सत्रों का उपयोग अन्य क्लाइंट साइटों या केंद्रीय रूप से प्रबंधित साइटों पर जाने के लिए किया जाता है।.

निचला रेखा: व्यवस्थापक-केवल आवश्यकता के बावजूद, प्रभाव गंभीर और तात्कालिक हो सकता है। containment को प्राथमिकता दें।.

यह कितना गंभीर है? खतरे का मॉडल और जोखिम मूल्यांकन

• शोषण जटिलता: मध्यम — हमलावर को एक व्यवस्थापक होना चाहिए या एक व्यवस्थापक को एक दुर्भावनापूर्ण मान प्रस्तुत करने के लिए धोखा देना चाहिए।.
• आवश्यक विशेषाधिकार: उच्च (व्यवस्थापक)।.
• उपयोगकर्ता इंटरैक्शन: आवश्यक (व्यवस्थापक को एक दुर्भावनापूर्ण पेलोड को लोड/क्लिक करना या अन्यथा इंटरैक्ट करना होगा)।.
• शोषण प्रभाव: प्रशासनिक विशेषाधिकारों के कारण संभावित रूप से उच्च, मध्य-स्तरीय CVSS आधार स्कोर के बावजूद।.

जोखिम कारक:

• साइट पर प्रशासकों की संख्या।.
• क्या प्रशासक मजबूत प्रमाणीकरण (2FA) और अद्वितीय क्रेडेंशियल्स का उपयोग करते हैं।.
• क्या hop_name सार्वजनिक रूप से और प्रशासनिक स्क्रीन में प्रदर्शित किया गया है।.
• पहचान और सुधार की गति।.

यदि आपकी साइट पर कई प्रशासक हैं या प्रशासक जो अक्सर अविश्वसनीय सामग्री के साथ इंटरैक्ट करते हैं, तो इसे तत्काल मानें।.

साइट मालिकों और प्रशासकों के लिए तात्कालिक क्रियाएँ

अगले 24-72 घंटों में इन कंटेनमेंट-प्रथम कदमों का पालन करें।.

1. तुरंत प्रशासनिक एक्सपोजर को कम करें।
   • लॉग इन किए गए प्रशासकों की संख्या को सीमित करें।.
   • अस्थायी रूप से अप्रयुक्त प्रशासक खातों को निष्क्रिय करें।.
   • जहां संचालन के लिए संभव हो, /wp-admin/ तक पहुंच को IP द्वारा प्रतिबंधित करें।.
2. प्रशासनिक प्रमाणीकरण को मजबूत करें।
   • सभी प्रशासकों के लिए दो-कारक प्रमाणीकरण (2FA) लागू करें।.
   • प्रशासक पासवर्ड को मजबूत, अद्वितीय मानों में घुमाएं।.
3. प्लगइन को निष्क्रिय या हटा दें (अल्पकालिक कंटेनमेंट)।

   यदि स्वीकार्य हो, तो पैच होने तक या जब तक आप एक आभासी पैच लागू नहीं करते, लिंक हॉपर को निष्क्रिय करें। नोट: निष्क्रियता नए कमजोर लेखन को रोकती है लेकिन संग्रहीत डेटा अभी भी DB में मौजूद हो सकता है और अन्यत्र प्रदर्शित किया जा सकता है।.

4. आभासी पैचिंग लागू करें / एक WAF नियम का अनुरोध करें (तेज शमन)।

   संदिग्ध सामग्री को अवरुद्ध करने के लिए एक नियम लागू करें (आपके WAF या रिवर्स प्रॉक्सी पर)। hop_name पैरामीटर में। नीचे उदाहरण WAF नियम अनुभाग देखें।.

5. संग्रहीत पेलोड के लिए डेटाबेस का ऑडिट करें

   के लिए खोजें <script> प्लगइन-संबंधित तालिकाओं और विकल्पों में टैग और संदिग्ध विशेषताओं की जांच करें। हटाने से पहले विश्लेषण के लिए प्रतियां बनाए रखें।.

6. फ़ाइल अखंडता और मैलवेयर स्कैन करें

   wp-content और रूट में नए या संशोधित PHP फ़ाइलों के लिए स्कैन करें। वेब शेल और अप्रत्याशित अनुसूचित कार्यों की तलाश करें।.

7. सुनिश्चित करें कि बैकअप मौजूद हैं और अलग रखे गए हैं

   तुरंत एक ताजा फ़ाइल+DB बैकअप बनाएं। फोरेंसिक्स के लिए एक ऑफ़लाइन प्रति रखें।.

8. लॉग की निगरानी करें

   लॉग संरक्षण बढ़ाएं और व्यवस्थापक क्रियाओं (उपयोगकर्ता निर्माण, प्लगइन संपादन, REST कॉल) की समीक्षा करें। असामान्य IP से लॉगिन की जांच करें।.

9. अपनी टीम से संवाद करें

   व्यवस्थापकों को सूचित करें कि जब तक उपाय लागू नहीं होते, तब तक प्रशासनिक फ़ील्ड में अविश्वसनीय सामग्री न चिपकाएं।.

पहचान और जांच - क्या देखना है

पहचान के लिए स्वचालित खोजों और मैनुअल निरीक्षण की आवश्यकता होती है।.

1. स्क्रिप्ट-जैसी सामग्री के लिए डेटाबेस में खोजें

   उदाहरण (केवल पढ़ने के लिए):

   SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%<script%';

   एन्कोडेड पेलोड जैसे की भी खोजें %3Cscript, जावास्क्रिप्ट:, और base64 मार्कर।.

2. प्लगइन-विशिष्ट डेटा की खोज करें

   लिंक हॉपर तालिका/विकल्प उपसर्गों की पहचान करें और संदिग्ध सामग्री के लिए फ़ील्ड जैसे की क्वेरी करें hop_name संदिग्ध सामग्री के लिए।.

3. व्यवस्थापक स्क्रीन की जांच करें

   UI स्क्रीन की समीक्षा करें (अधिमानतः स्टेजिंग में) और अनएस्केप्ड मानों के लिए DOM का निरीक्षण करें।.

4. नए बनाए गए व्यवस्थापक उपयोगकर्ताओं और निर्धारित कार्यों की जांच करें

   अप्रत्याशित उपयोगकर्ताओं, भूमिकाओं में परिवर्तनों और नए क्रॉन घटनाओं की तलाश करें।.

5. सर्वर और एक्सेस लॉग की समीक्षा करें

   POST अनुरोधों की खोज करें जिसमें hop_name और संदिग्ध गतिविधियों के समय के चारों ओर एन्कोडेड स्क्रिप्ट अनुक्रम होते हैं।.

6. फ़ाइल प्रणाली की जांच

   अपलोड में संशोधित प्लगइन फ़ाइलों और PHP फ़ाइलों की तलाश करें।.

7. प्रतिष्ठित स्कैनरों का उपयोग करें, उन्हें सच्चाई के रूप में नहीं।

   अपरिवर्तनीय कार्यवाही करने से पहले स्कैनर के निष्कर्षों की मैन्युअल समीक्षा के साथ पुष्टि करें।.

यदि आप संदिग्ध पेलोड पाते हैं, तो सबूत को संरक्षित करें फिर उन्हें हटा दें या साफ करें।.

हार्डनिंग और विकास सुधार (प्लगइन-स्तरीय और साइट-स्तरीय)

सुधार के लिए प्लगइन सुधार और साइट-स्तरीय रक्षात्मक नियंत्रण दोनों की आवश्यकता होती है।.

प्लगइन डेवलपर मार्गदर्शन

• इनपुट को सख्त कार्यों के साथ साफ करें (जैसे, sanitize_text_field(), strip_tags()) और अप्रत्याशित वर्णों को अस्वीकार करें।.
• आउटपुट पर संदर्भ-उपयुक्त कार्यों का उपयोग करके एस्केप करें (esc_html(), esc_attr(), आदि)।.
• संदर्भ-संवेदनशील एन्कोडिंग करें - केवल इनपुट सफाई पर निर्भर न रहें।.

साइट-स्वामी शमन

• एक अनिवार्य उपयोग (mu-) प्लगइन बनाएं जो साफ करता है hop_name कमजोर प्लगइन के स्थायी होने से पहले।.
• उचित स्थानों पर प्रदर्शित सामग्री को केवल पाठ तक सीमित करें।.
• लेबल के लिए लंबाई सीमाएँ और सख्त अनुमत वर्ण सेट लागू करें।.
• इंजेक्टेड इनलाइन स्क्रिप्ट्स की प्रभावशीलता को कम करने के लिए सामग्री-सुरक्षा-नीति (CSP) हेडर लागू करें (जैसे, इनलाइन स्क्रिप्ट्स की अनुमति न दें या सख्त नॉनस का उपयोग करें)। CSP मानक को बढ़ाता है लेकिन यह एकल विफलता का बिंदु नहीं है।.
• यदि प्लगइन अनिवार्य नहीं है, तो इसे हटाने या एक बनाए रखा, सुरक्षित विकल्प के साथ बदलने पर विचार करें।.

उदाहरण WAF / वर्चुअल पैच नियम और सिफारिशें

HTTP स्तर पर वर्चुअल पैचिंग अक्सर सबसे तेज़ समाधान होता है। नीचे विक्रेता-स्वतंत्र रक्षात्मक पैटर्न और वैचारिक नियम दिए गए हैं। उन्हें आपके वातावरण के अनुसार समायोजित करें ताकि झूठे सकारात्मक कम हों।.

उच्च-स्तरीय नियम तर्क (वैचारिक)

• उन प्रशासनिक अंत बिंदुओं पर POST अनुरोधों को ब्लॉक करें जो शामिल हैं hop_name संदिग्ध पैटर्न: 9. या विशेषताओं जैसे onload=, इवेंट विशेषताएँ (त्रुटि होने पर=, 11. साइट मालिकों के लिए तात्कालिक कदम), जावास्क्रिप्ट:, और एन्कोडेड समकक्ष (%3Cscript, आदि)।.
• उन अनुरोधों को लॉग करें और ब्लॉक करें जो किसी भी पैरामीटर में इवेंट विशेषताओं को शामिल करते हैं जब सत्र एक प्रशासनिक खाते से संबंधित हो।.
• प्रशासनिक संशोधन क्रियाओं को थ्रॉटल करें और नए आईपी से आने वाले अनुरोधों के लिए संवेदनशील अंत बिंदुओं के लिए पुनः प्रमाणीकरण की आवश्यकता करें।.

नमूना वैचारिक ModSecurity-जैसे नियम

# Block script tags and inline event handlers in hop_name parameter
SecRule ARGS:hop_name "(?i)(<\s*script\b|onerror\s*=|onload\s*=|javascript:|%3Cscript|%3C%2Fscript)" \
  "id:100001,phase:2,deny,log,status:403,msg:'Blocked possible stored XSS in hop_name parameter'"

# Block encoded script sequences anywhere
SecRule ARGS_NAMES|ARGS|REQUEST_HEADERS "(?i)(%3Cscript|%3E%3C|%3C%2Fscript%3E|%3Cimg|<svg)" \
  "id:100002,phase:2,deny,log,status:403,msg:'Blocked encoded script-like payload'"

संचालन संबंधी मार्गदर्शन:

• स्पष्ट स्क्रिप्ट मार्करों और एन्कोडेड समकक्षों को ब्लॉक करने से शुरू करें, फिर झूठे सकारात्मक को कम करने के लिए पुनरावृत्ति करें।.
• प्रशासनिक सत्रों के लिए लॉगिंग को बढ़ाएं ताकि आप जल्दी से ब्लॉक किए गए प्रयासों की जांच कर सकें।.
• WAF नियमों को पहुंच प्रतिबंधों ( /wp-admin/ के लिए IP अनुमति सूची) और परतित रक्षा के लिए 2FA प्रवर्तन के साथ संयोजित करें।.

रिकवरी और पोस्ट-घटना चेकलिस्ट

यदि समझौता होने का संदेह है, तो एक संरचित पुनर्प्राप्ति प्रक्रिया का पालन करें:

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

   यदि बैकअप से पुनर्स्थापित कर रहे हैं, तो सुनिश्चित करें कि बैकअप समझौते से पहले का है और इसमें इंजेक्टेड पेलोड्स नहीं हैं।.

6. सत्यापित करें
   • स्वतंत्र मैलवेयर स्कैन और मैनुअल कोड समीक्षाएँ चलाएँ।.
   • साइट की कार्यक्षमता को मान्य करें और पुष्टि करें कि कोई स्थायीता नहीं है।.
7. रिपोर्ट करें और सीखें

   जब उपलब्ध हो, तो विक्रेता द्वारा प्रदान किए गए पैच लागू करें और घटना प्रतिक्रिया प्लेबुक को तदनुसार अपडेट करें।.

प्लगइन्स और व्यवस्थापक स्वच्छता के लिए दीर्घकालिक सर्वोत्तम प्रथाएँ

• न्यूनतम विशेषाधिकार का सिद्धांत: केवल आवश्यक होने पर व्यवस्थापक भूमिका प्रदान करें।.
• व्यवस्थापक ऑडिटिंग और कर्तव्यों का पृथक्करण: संचालन और नियमित सामग्री प्रबंधन के लिए अलग-अलग व्यवस्थापक खातों का उपयोग करें।.
• मजबूत प्रमाणीकरण लागू करें: सभी व्यवस्थापकों के लिए 2FA; डिफ़ॉल्ट उपयोगकर्ता नामों से बचें।.
• साइट को मजबूत करना: /wp-admin/ के लिए आईपी प्रतिबंध, संवेदनशील क्रियाओं के लिए पुनः प्रमाणीकरण, और व्यवस्थापक एंडपॉइंट्स के लिए दर-सीमा।.
• सॉफ़्टवेयर को अद्यतित रखें: विश्वसनीय फीड्स से प्लगइन चेंजलॉग और विक्रेता सलाह की निगरानी करें।.
• स्टेजिंग/परीक्षण: उत्पादन रोलआउट से पहले स्टेजिंग में अपडेट को मान्य करें।.
• बैकअप और संरक्षण: नियमित, ऑफसाइट बैकअप और एक प्रलेखित पुनर्स्थापना प्रक्रिया बनाए रखें।.
• घटना प्रतिक्रिया: एक रनबुक होनी चाहिए जिसमें containment, forensic preservation, और recovery शामिल हो।.
• विक्रेता चयन और कोड समीक्षा: स्पष्ट सुरक्षा प्रथाओं के साथ सक्रिय रूप से बनाए रखे जाने वाले प्लगइन्स को प्राथमिकता दें; उन प्लगइन्स के लिए कोड समीक्षा पर विचार करें जो प्रशासनिक प्रवाह को प्रभावित करते हैं।.

परिशिष्ट: रक्षात्मक कमांड, SQL, और mu-plugin उदाहरण (केवल रक्षात्मक)

निम्नलिखित रक्षात्मक, केवल-पढ़ने योग्य क्वेरी और समस्या डेटा को खोजने और कम करने में मदद करने के लिए नमूना कोड हैं। विनाशकारी कमांड चलाने से पहले हमेशा बैकअप लें।.

1. संदिग्ध स्ट्रिंग्स के लिए केवल-पढ़ने योग्य DB खोज (MySQL)

-- सामान्य स्थानों में शाब्दिक <script टैग के लिए खोजें;

2. एन्कोडेड पेलोड्स के लिए खोजें

SELECT option_name FROM wp_options WHERE option_value LIKE '%3Cscript%';
SELECT meta_id, meta_value FROM wp_postmeta WHERE meta_value LIKE '%3Cscript%';

3. WP-CLI खोज

wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';"

4. हॉप_नाम को साफ करने के लिए रक्षात्मक PHP mu-plugin (संकल्पना)

एक फ़ाइल बनाएं wp-content/mu-plugins/ (जैसे, 01-sanitize-hopname.php) आने वाले को साफ करने के लिए hop_name POST मानों को DB में कमजोर प्लगइन के लिखने से पहले। यह एक अस्थायी समाधान है और इसे स्टेजिंग में परीक्षण किया जाना चाहिए।.

<?php
/*
Plugin Name: MU - Sanitize Link Hopper hop_name
Description: Defensive filter to sanitize hop_name POST param before plugin stores it. Site owners: tailor for plugin endpoints and test in staging.
*/

add_action( 'admin_init', function() {
    // Only run on POST requests in admin context
    if ( 'POST' !== $_SERVER['REQUEST_METHOD'] || ! is_admin() ) {
        return;
    }

    // Candidate parameter name (from public report)
    $param = 'hop_name';

    if ( ! empty( $_POST[ $param ] ) ) {
        $raw = $_POST[ $param ];

        // Basic sanitization: strip tags and remove suspicious event handlers/JS pseudo-schemes
        $clean = wp_strip_all_tags( $raw ); // strips tags
        $clean = preg_replace( '#(on\w+\s*=)#i', '', $clean ); // remove inline event handlers
        $clean = preg_replace( '#javascript\s*:#i', '', $clean ); // remove javascript: pseudo-scheme
        $clean = preg_replace( '#(data:text/html;base64,)#i', '', $clean ); // remove data: base64 markers

        // Limit length to reasonable size (example: 255 chars)
        $clean = substr( $clean, 0, 255 );

        // Replace the POST value so plugin receives sanitized input
        $_POST[ $param ] = $clean;
    }
});

नोट्स: यह mu-plugin एक अस्थायी रक्षात्मक उपाय है। स्टेजिंग में परीक्षण करें। Mu-plugins जल्दी चलते हैं और यदि अत्यधिक आक्रामक होते हैं तो कार्यक्षमता को तोड़ सकते हैं।.

5. त्वरित फ़ाइल प्रणाली जांच

# हाल ही में संशोधित PHP फ़ाइलें खोजें

6. WP-CLI के माध्यम से प्रशासनिक उपयोगकर्ताओं और हाल के परिवर्तनों का ऑडिट करें

wp user list --role=administrator

(WP-CLI और अंतिम_लॉगिन रिकॉर्ड करने वाले प्लगइन्स की आवश्यकता हो सकती है।)

अंतिम नोट्स और अनुशंसित समयरेखा

• दिन 0 (अब): प्रशासनिक अंत बिंदुओं पर स्क्रिप्ट-जैसे इनपुट को ब्लॉक करने के लिए WAF नियम लागू करें; 2FA लागू करें; जहां संभव हो, IP द्वारा प्रशासनिक पहुंच को प्रतिबंधित करें; प्रशासनिक टीम को सूचित करें कि वे प्रशासनिक क्षेत्रों में अज्ञात सामग्री न चिपकाएं।.
• दिन 0–1: डेटाबेस और फ़ाइल स्कैन चलाएं; यदि आवश्यक हो तो mu-plugin स्वच्छता लागू करें; फोरेंसिक्स के लिए एक साफ़ बैकअप बनाएं।.
• दिन 1–7: दुर्भावनापूर्ण संग्रहीत सामग्री और कलाकृतियों को हटा दें; क्रेडेंशियल्स, API कुंजी और रहस्यों को घुमाएं; यदि आवश्यक हो तो अच्छे बैकअप से पुनर्स्थापित करें।.
• सप्ताह 1+: विक्रेता पैच लागू करें या प्लगइन को एक सुरक्षित विकल्प से बदलें। यदि कोई आधिकारिक पैच उपलब्ध नहीं है, तो प्लगइन कार्यक्षमता को स्थायी रूप से हटाने या पुनर्विकास पर विचार करें।.
• चल रहा: लॉग और WAF अलर्ट की निगरानी करें, प्रयास किए गए शोषण के लिए आने वाले ब्लॉकों का निरीक्षण करें, और प्रशासनिक गतिविधि लॉग की समीक्षा करें।.

यदि आपको सहायता की आवश्यकता है, तो WordPress घटना प्रतिक्रिया और वर्चुअल पैचिंग में अनुभवी एक पेशेवर सुरक्षा सलाहकार से संपर्क करें। प्रारंभिक सीमांकन और सावधानीपूर्वक फोरेंसिक संरक्षण क्षति को सीमित करने और विश्वास को बहाल करने के लिए महत्वपूर्ण हैं।.