प्लगइन का नाम	AddFunc हेड और फुटर कोड
भेद्यता का प्रकार	क्रॉस-साइट स्क्रिप्टिंग (XSS)
सीवीई नंबर	CVE-2026-2305
तात्कालिकता	कम
CVE प्रकाशन तिथि	2026-04-10
स्रोत यूआरएल	CVE-2026-2305

AddFunc हेड और फुटर कोड प्लगइन XSS (CVE-2026-2305): वर्डप्रेस साइट मालिकों को क्या जानना चाहिए — और WP­Firewall आपको कैसे सुरक्षित रखता है

दिनांक: 10 अप्रैल 2026
गंभीरता (Patchstack सूची): कम (CVSS 6.5)
प्रभावित संस्करण: <= 2.3
पैच किया गया: 2.4
10. आवश्यक विशेषाधिकार: योगदानकर्ता (प्रमाणित)

एक हालिया खुलासा (CVE-2026-2305) वर्डप्रेस के लिए AddFunc हेड और फुटर कोड प्लगइन में एक प्रमाणित संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS) भेद्यता का वर्णन करता है (संस्करण 2.3 तक)। यह भेद्यता एक उपयोगकर्ता को योगदानकर्ता स्तर की पहुंच के साथ कस्टम फ़ील्ड के माध्यम से स्क्रिप्ट-जैसे पेलोड इंजेक्ट करने की अनुमति देती है, जो बाद में अस्वच्छ रूप से प्रस्तुत किए जा सकते हैं — उन पृष्ठों या प्रशासनिक स्क्रीन पर संग्रहीत XSS उत्पन्न करते हैं जहां उन फ़ील्ड का आउटपुट होता है।.

WP­Firewall (एक वर्डप्रेस सुरक्षा और प्रबंधित WAF प्रदाता) के पीछे की टीम के रूप में, मैं आपको जोखिम, वास्तविकवादी हमले के परिदृश्य, पहचान और सफाई के कदमों, और उन स्तरित सुरक्षा उपायों का एक पठनीय, व्यावहारिक विश्लेषण देना चाहता हूं जिन्हें आपको तुरंत लागू करना चाहिए। मैं यह भी समझाऊंगा कि हमारी फ़ायरवॉल क्षमताएँ आपको कैसे सुरक्षित रखती हैं (वर्चुअल पैचिंग और WAF सिग्नेचर सहित), और डेवलपर्स और साइट प्रशासकों के लिए ठोस, सुरक्षित कोड और कॉन्फ़िगरेशन मार्गदर्शन प्रदान करूंगा।.

यह एक वर्डप्रेस सुरक्षा प्रैक्टिशनर के दृष्टिकोण से लिखा गया है — व्यावहारिक, बिना किसी बकवास के, ऐसे पुनरुत्पादनीय कदमों के साथ जिन्हें आप आज उपयोग कर सकते हैं।.

---

कार्यकारी सारांश — क्या हुआ और यह क्यों महत्वपूर्ण है

• प्लगइन AddFunc हेड और फुटर कोड (संस्करण <= 2.3) ने उपयोगकर्ता-प्रदत्त सामग्री को पोस्ट कस्टम फ़ील्ड से आउटपुट में शामिल करने की अनुमति दी बिना पर्याप्त स्वच्छता/एस्केपिंग के।.
• एक प्रमाणित उपयोगकर्ता जिसके पास योगदानकर्ता विशेषाधिकार हैं (जो पोस्ट और कस्टम फ़ील्ड जोड़ने या संपादित करने में सक्षम हैं) एक पेलोड को सहेज सकता है जिसमें स्क्रिप्ट टैग या इवेंट हैंडलर होते हैं।.
• जब वह सामग्री बाद में फ्रंट-एंड पर या एक प्रशासनिक पृष्ठ में उचित एस्केपिंग के बिना प्रस्तुत की जाती है, तो संग्रहीत स्क्रिप्ट आगंतुक या प्रशासक के ब्राउज़र में निष्पादित होती है।.
• प्रभाव इस बात पर निर्भर करता है कि फ़ील्ड कहाँ प्रस्तुत किया गया है:
  • यदि पेलोड फ्रंट-एंड (सार्वजनिक पृष्ठों) में निष्पादित होता है, तो साइट विज़िटर प्रभावित हो सकते हैं (दुष्ट रीडायरेक्ट, नकली फ़ॉर्म, क्रिप्टो-माइनर्स, सामग्री इंजेक्शन)।.
  • यदि पेलोड प्रशासनिक पृष्ठों के भीतर निष्पादित होता है (जैसे, जब एक संपादक या प्रशासक डैशबोर्ड में पोस्ट खोलता है), तो उच्च विशेषाधिकार वाले उपयोगकर्ताओं को लक्षित किया जा सकता है जिससे साइट पर कब्जा हो सकता है: खाता अपहरण, प्लगइन/थीम स्थापना, सेटिंग्स में परिवर्तन, या बैकडोर स्थापित करना।.
• प्लगइन को संस्करण 2.4 में पैच किया गया था। प्रभावित साइटों के लिए तत्काल सही कार्रवाई 2.4 या बाद के संस्करण में अपडेट करना है।.

---

एक योगदानकर्ता क्यों खतरनाक हो सकता है — वास्तविक दुनिया का खतरा मॉडल

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

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

संक्षेप में: उन उपयोगकर्ताओं के योगदान जो आप सामग्री के लिए भरोसा करते हैं, का उपयोग साइट के समझौते में बदलने के लिए किया जा सकता है यदि स्वच्छता/एस्केपिंग गायब है।.

---

सामान्य शोषण प्रवाह (उच्च स्तर, गैर-क्रियाशील)

1. हमलावर एक योगदानकर्ता विशेषाधिकार के साथ खाता पंजीकृत करता है या उपयोग करता है (या एक को समझौता करता है)।.
2. हमलावर एक ड्राफ्ट संपादित करता है या एक पोस्ट बनाता है और एक कस्टम फ़ील्ड में दुर्भावनापूर्ण सामग्री जोड़ता है (उदाहरण के लिए, <script>…</script> या विशेषता-आधारित पेलोड जैसे onerror=… एक अनुमत टैग के अंदर)।.
3. साइट उस सामग्री को पोस्टमेटा में संग्रहीत करती है।.
4. जब पोस्ट एक संदर्भ में लोड होती है जहां प्लगइन या थीम उस कस्टम फ़ील्ड को अस्वच्छित रूप से आउटपुट करती है (फ्रंट-एंड पृष्ठ, प्रशासनिक पूर्वावलोकन, या मेटा बॉक्स), तो ब्राउज़र इंजेक्टेड कोड को चलाता है।.
5. यदि एक व्यवस्थापक प्रभावित पृष्ठ या पोस्ट को प्रशासनिक इंटरफ़ेस में देखता है (या यदि आगंतुकों को लक्षित किया जाता है), तो इंजेक्टेड स्क्रिप्ट कर सकती है:
   • व्यवस्थापक कुकीज़ चुराना (यदि HttpOnly नहीं है - हालांकि आधुनिक सर्वोत्तम प्रथा कुकी चोरी को कम करती है लेकिन सभी साइटें इसका पालन नहीं करती हैं),
   • REST API / प्रशासनिक अंत बिंदुओं के माध्यम से एक नया व्यवस्थापक खाता बनाने के लिए व्यवस्थापक विशेषाधिकारों का उपयोग करना,
   • प्लगइन/थीम फ़ाइलों या सेटिंग्स को संशोधित करना,
   • एक बैकडोर स्थापित करना या आगे के मैलवेयर को स्थायी बनाना,
   • डेटा को बाहर निकालना।.

क्योंकि शोषण अक्सर एक व्यवस्थापक को इंटरैक्ट करने की आवश्यकता होती है (प्रशासन में पोस्ट देखना या एक विशिष्ट पूर्वावलोकन लिंक पर क्लिक करना), पैचस्टैक “उपयोगकर्ता इंटरैक्शन आवश्यक” सूचीबद्ध करता है, लेकिन यह इंटरैक्शन पोस्ट संपादक खोलने या एक तैयार पूर्वावलोकन लिंक के रूप में सरल हो सकता है।.

---

अपनी साइट की सुरक्षा के लिए व्यावहारिक कदम — तात्कालिक क्रियाएँ (चेकलिस्ट)

1. प्लगइन अपडेट करें
   – यदि आप AddFunc Head & Footer Code चला रहे हैं, तो तुरंत संस्करण 2.4 या बाद का अपडेट करें। यह सही समाधान है।.
2. यदि आप तुरंत अपडेट नहीं कर सकते
   – प्लगइन को अस्थायी रूप से हटा दें या निष्क्रिय करें।.
   – प्लगइन के अपडेट होने तक योगदानकर्ता खातों को कस्टम फ़ील्ड संपादित करने या जोड़ने से रोकें।.
   – WAF स्तर पर आभासी पैचिंग लागू करें (नीचे WAF मार्गदर्शन देखें)।.
3. कस्टम फ़ील्ड में दुर्भावनापूर्ण सामग्री के लिए स्कैन करें
   – मेटा मान खोजने के लिए WP­CLI या सीधे DB क्वेरी का उपयोग करें जिसमें <script, onerror=, जावास्क्रिप्ट:, या संदिग्ध HTML।.
       – उदाहरण (पहले अपने DB का बैकअप लें):
          wp db query "SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%';"
       – इसके अलावा खोजें onerror=, ऑनलोड=, जावास्क्रिप्ट: पैटर्न।.
   – प्रविष्टियों की समीक्षा करें और संदिग्ध मेटा मानों को हटा दें या साफ करें।.
4. उपयोगकर्ता खातों का ऑडिट करें
   – सभी योगदानकर्ताओं और संपादकों की पुष्टि करें: क्या वे वैध हैं? पुराने या संदिग्ध खातों को हटा दें।.
   – विशेषाधिकार प्राप्त भूमिकाओं (संपादक, प्रशासक) के लिए मजबूत पासवर्ड और 2FA लागू करें।.
5. समझौते के संकेतों की जांच करें
   – अज्ञात व्यवस्थापक खातों, अप्रत्याशित प्लगइन/थीम फ़ाइलों, हाल ही में संशोधित फ़ाइलों, अनुसूचित कार्यों, और सर्वर से आउटगोइंग कनेक्शनों की तलाश करें।.
   – एक मैलवेयर स्कैन चलाएँ (WP­Firewall का स्कैनर या अन्य प्रतिष्ठित स्कैनर)।.
6. यदि समझौता होने का संदेह हो तो क्रेडेंशियल्स और API कुंजियाँ बदलें
   – व्यवस्थापक पासवर्ड और किसी भी उजागर API कुंजियों को बदलें।.
   – यदि आवश्यक हो तो सत्रों को अमान्य करें (सभी उपयोगकर्ताओं के लिए मजबूर लॉगआउट)।.
7. सफाई से पहले बैकअप लें
   – सुधार से पहले पूरी साइट का बैकअप लें (फ़ाइलें और DB)। यह सबूत को संरक्षित करता है और आपको एक रोलबैक बिंदु देता है।.
8. आगे बढ़ते हुए कस्टम फ़ील्ड को मजबूत करें
   – सहेजने पर सफाई और आउटपुट पर एस्केपिंग की आवश्यकता करें — नीचे कोड अनुशंसाएँ देखें।.

---

दुर्भावनापूर्ण संग्रहीत XSS प्रविष्टियों को सुरक्षित रूप से कैसे खोजें

डेटाबेस में संदिग्ध सामग्री की खोज करना महत्वपूर्ण है लेकिन इसे सावधानी से करना चाहिए:

• क्वेरी चलाने या परिवर्तन करने से पहले हमेशा एक बैकअप बनाएं।.
• संदिग्ध प्रविष्टियों की पहचान करने के लिए केवल पढ़ने वाली क्वेरी से शुरू करें, फिर उन्हें मैन्युअल रूप से समीक्षा करें।.
• उदाहरण WP­CLI पहचान क्वेरी:

# <script को शामिल करने वाले पोस्टमेटा को खोजें"

संदिग्ध मेटा मानों को निर्यात करें और उनकी जांच करें, फिर उन्हें स्वच्छ या हटाने का निर्णय लें।.

---

संदिग्ध प्रविष्टियों को साफ करना

यदि आप दुर्भावनापूर्ण मेटा मानों की पहचान करते हैं:

• यदि प्रविष्टि स्पष्ट रूप से दुर्भावनापूर्ण है (पूर्ण 3. ब्लॉक्स), तो मेटा पंक्ति को हटा दें।.
• यदि प्रविष्टि में उपयोगी डेटा है लेकिन साथ में इंजेक्टेड टैग भी हैं, तो सामग्री को स्वच्छ करें:

<?php

यदि आप DB को मैन्युअल रूप से संपादित करने में सहज नहीं हैं, तो अपने डेवलपर या होस्ट से संपर्क करें।.

---

डेवलपर मार्गदर्शन: कस्टम फ़ील्ड का सुरक्षित प्रबंधन (सहेजने का समय स्वच्छता और आउटपुट escaping)

इस तरह की कमजोरियाँ आमतौर पर इनपुट पर स्वच्छता की कमी या अपर्याप्तता और आउटपुट पर escaping की कमी के कारण होती हैं। दोनों सिद्धांतों का पालन करें:

1. सहेजने पर स्वच्छ करें (ताकि संग्रहीत डेटा सुरक्षित हो)
2. आउटपुट पर escaping करें (कभी भी संग्रहीत डेटा पर भरोसा न करें)

अनुशंसित पैटर्न:

• मेटा को सहेजते समय वर्डप्रेस स्वच्छता फ़ंक्शन का उपयोग करें:

<?php

• आउटपुट पर, हमेशा संदर्भ के आधार पर एस्केप करें:

<?php

• बेहतर पैटर्न: एक साफ़ करने वाले कॉलबैक के साथ मेटा पंजीकृत करें (REST के साथ अच्छी तरह से काम करता है):

<?php

• सहेजने या प्रशासन-केवल मेटा को रेंडर करने से पहले हमेशा क्षमता की जांच करें। प्रशासन फ़ॉर्म के लिए नॉनस का उपयोग करें।.

---

WAF और वर्चुअल पैचिंग - तात्कालिक नेटवर्क-स्तरीय सुरक्षा

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

इस प्रकार के स्टोर किए गए XSS के लिए सामान्य WAF निवारण में शामिल हैं:

• संदिग्ध स्क्रिप्ट पेलोड्स को शामिल करने वाले POST अनुरोधों को ब्लॉक करना जो ज्ञात मेटा फ़ील्ड नामों में होते हैं (जैसे, पोस्टमेटा सामग्री, _कस्टम_*).
• अनुरोधों को ब्लॉक करना या साफ़ करना जो शामिल करते हैं 3. टैग, इवेंट हैंडलर एट्रिब्यूट (onerror=, ऑनलोड=), जावास्क्रिप्ट: URI, base64-encoded स्क्रिप्ट सामग्री, या स्पष्ट रूप से अस्पष्टता पैटर्न।.
• निम्न-विशिष्ट उपयोगकर्ताओं से पोस्ट बनाने या अपडेट करने वाले POSTs की दर-सीमा।.
• ज्ञात शोषण हस्ताक्षरों और पेलोड एन्कोडिंग को ब्लॉक करना।.

उदाहरण प्सूडो-नियम (एक सामान्य WAF इंजन के लिए) - केवल वैचारिक:

# प्सूडोकोड WAF नियम: पोस्टमेटा फ़ील्ड में स्क्रिप्ट टैग ब्लॉक करें'

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

WP­Firewall पर हम लक्षित वर्चुअल पैचिंग नियम प्रदान करते हैं जो स्टोर किए गए XSS प्रयासों में उपयोग किए जाने वाले पैटर्न का पता लगाते हैं और उन्हें ब्लॉक करते हैं, जब एक ब्लॉक किया गया प्रयास हुआ तो निगरानी और अधिसूचना के साथ।.

---

WAF नियम उदाहरण — ModSecurity-शैली (उदाहरण, अपने वातावरण के लिए ट्यून करें)

नीचे उदाहरण पैटर्न दिए गए हैं जिन्हें प्रारंभिक बिंदु के रूप में उपयोग किया जा सकता है। ये चित्रात्मक हैं — झूठे सकारात्मक से बचने के लिए सावधानी से परीक्षण करें:

# उदाहरण ModSecurity नियम जो POST शरीर में  टैग का पता लगाता है"

# उदाहरण नियम जो onerror= या onload= जैसे इवेंट विशेषताओं का पता लगाता है"

महत्वपूर्ण: हमेशा नियमों का परीक्षण एक स्टेजिंग वातावरण पर करें ताकि वैध किनारे के मामलों की पहचान की जा सके (कुछ वैध सामग्री में अनुमति प्राप्त HTML शामिल हो सकता है) और नियमों को तदनुसार ट्यून करें।.

---

पहचान — शोषण के लॉग और संकेतक

यदि आपको संदेह है कि शोषण हुआ:

• POSTs के लिए सर्वर एक्सेस लॉग की जांच करें जो पोस्ट बनाते या संशोधित करते हैं (POSTs को /wp-admin/post.php, /wp-json/wp/v2/posts)।.
• संदिग्ध POST पैरामीटर के लिए एप्लिकेशन लॉग की जांच करें (यदि आपके पास हैं)।.
• अपने मैलवेयर स्कैनर से अलर्ट देखें जो संशोधित प्लगइन/थीम फ़ाइलें, अपरिचित फ़ाइलें, या वेबशेल दिखाते हैं।.
• नए बनाए गए प्रशासक खातों के लिए व्यवस्थापक उपयोगकर्ताओं की सूची की जांच करें।.
• अपने सर्वर से अज्ञात होस्टों के लिए आउटगोइंग कनेक्शनों की जांच करें।.
• अज्ञात PHP निष्पादनों के लिए हाल के क्रोन कार्यों और अनुसूचित कार्यों की समीक्षा करें।.

यदि आप पोस्टमेटा में इंजेक्ट की गई सामग्री पाते हैं, तो इसे संभावित समझौता के रूप में मानें: पूर्ण घटना प्रतिक्रिया करें (क्वारंटाइन, फोरेंसिक स्नैपशॉट, यदि आवश्यक हो तो साफ बैकअप से पुनर्स्थापित करें)।.

---

संक्रमण के बाद — सुधार और मजबूत करना

यदि आप साइट के समझौता होने के सबूत पाते हैं:

1. अलग साइट (इसे ऑफलाइन ले जाएं या इनबाउंड एक्सेस को ब्लॉक करें) की जांच करते समय।.
2. साक्ष्य संरक्षित करें: एक पूर्ण स्नैपशॉट लें, लॉग्स को संरक्षित करें (वेब सर्वर, डेटाबेस)।.
3. स्थायी तंत्र की पहचान करें: जोड़े गए व्यवस्थापक उपयोगकर्ताओं, संशोधित wp-config.php, प्रतिस्थापित कोर फ़ाइलों, दुर्भावनापूर्ण प्लगइन्स/थीमों, क्रोन कार्यों, अनुसूचित घटनाओं की जांच करें।.
4. साफ करें: दुर्भावनापूर्ण फ़ाइलों और डेटाबेस प्रविष्टियों को हटा दें। यदि सुनिश्चित नहीं हैं, तो एक स्वच्छ बैकअप से पुनर्स्थापित करें।.
5. क्रेडेंशियल बदलें: सभी पासवर्ड रीसेट करें, API कुंजियाँ रद्द करें, SSH कुंजियाँ घुमाएँ।.
6. पैच करें।: वर्डप्रेस कोर, प्लगइन्स और थीम को नवीनतम संस्करणों में अपडेट करें।.
7. मजबूत करें: फ़ाइल अनुमतियों को सीमित करें, wp-config.php के माध्यम से फ़ाइल संपादन को अक्षम करें (define('DISALLOW_FILE_EDIT', true)), सभी प्रशासकों के लिए 2FA लागू करें, सभी खातों के लिए न्यूनतम विशेषाधिकार की समीक्षा करें।.
8. निगरानी करना: सुरक्षा निगरानी, फ़ाइल अखंडता निगरानी, और महत्वपूर्ण घटनाओं के लिए अलर्टिंग सक्षम करें।.

---

दीर्घकालिक नियंत्रण - भूमिका दुरुपयोग और अविश्वसनीय HTML से जोखिम को कम करें

• उन खातों की संख्या को न्यूनतम करें जो सामग्री संपादित कर सकते हैं; न्यूनतम विशेषाधिकार लागू करें।.
• जहां संभव हो, उपयोगकर्ता-प्रस्तुत सामग्री के लिए अनुमोदन कार्यप्रवाह की आवश्यकता करें (प्रकाशित करने से पहले समीक्षा करें)।.
• यह सीमित करें कि कौन सी भूमिकाएँ कस्टम फ़ील्ड जोड़ सकती हैं या प्लगइन्स का उपयोग कर सकती हैं जो कस्टम फ़ील्ड रेंडरिंग को उजागर करती हैं।.
• योगदानकर्ताओं को फ़ील्ड में HTML एम्बेड करने के जोखिमों के बारे में शिक्षित करें।.
• इंजेक्टेड स्क्रिप्ट के प्रभाव को सीमित करने के लिए सामग्री सुरक्षा नीति (CSP) हेडर का उपयोग करें (यह कुछ XSS हमलों की पहुंच को कम कर सकता है)।.
• कई योगदानकर्ताओं वाली साइटों के लिए, मजबूत भूमिका विभाजन सक्षम करें और मॉडरेशन फ़्लो प्लगइन्स पर विचार करें।.

---

कैसे विश्वसनीय WAF + प्रबंधित सुरक्षा समय-से-उपचार को कम करता है

एक प्रबंधित WAF और सुरक्षा सेवा प्रदान करती है:

• त्वरित आभासी पैचिंग: एप्लिकेशन कोड को संशोधित किए बिना तुरंत शोषण प्रयासों को अवरुद्ध करें।.
• अनुसंधान प्रकाशित होते ही सिग्नेचर अपडेट ताकि नियम उभरते हुए पेलोड को पकड़ सकें।.
• इंजेक्टेड सामग्री को खोजने और सुधारने के लिए मैलवेयर स्कैनिंग और हटाने के उपकरण।.
• निगरानी और अलर्टिंग ताकि आपको 24/7 लॉग देखना न पड़े।.
• घटना प्रतिक्रिया के दौरान मार्गदर्शन और आवश्यकता पड़ने पर रोलबैक सहायता।.

WP­Firewall इन क्षमताओं को विशेष लॉजिक के साथ जोड़ता है जो WordPress के लिए है (अनुरोध पैटर्न, REST एंडपॉइंट, प्रशासनिक एंडपॉइंट) ताकि हम उन हमलों का पता लगा सकें और उन्हें कम कर सकें जो सामान्य WordPress वेक्टर जैसे मेटा में संग्रहीत XSS को लक्षित करते हैं।.

---

व्यावहारिक WAF ट्यूनिंग नोट्स (झूठे सकारात्मक को कम करें)

• आक्रामक ब्लॉकिंग से विश्वसनीय प्रशासक IP को बाहर करने से प्रशासनिक कार्यप्रवाह में रुकावटें रोकने में मदद मिल सकती है - लेकिन इसे सुरक्षा जोखिम के साथ संतुलित करें।.
• उन नियमों का उपयोग करें जो मेटा फ़ील्ड्स (meta[], postmeta, acf, कस्टम फ़ील्ड) के लिए सामान्यतः उपयोग किए जाने वाले पैरामीटर नामों से मेल खाते हैं, बजाय कि सभी टैग को वैश्विक रूप से ब्लॉक करने के। 3. टैग को वैश्विक रूप से ब्लॉक करने के।.
• संदिग्ध लेकिन स्पष्ट रूप से दुर्भावनापूर्ण अनुरोधों को लॉग करें (अलर्ट-केवल मोड) एक अवधि के लिए ब्लॉक करने से पहले - यह आपके साइट के उपयोग पैटर्न के लिए सिग्नेचर को ट्यून करने में मदद करता है।.

---

उदाहरण घटना प्रतिक्रिया प्लेबुक (संक्षिप्त)

1. प्लगइन को 2.4 में अपडेट करें (यदि संभव हो)।.
2. यदि तत्काल अपडेट असंभव है: POST बॉडी में स्क्रिप्ट और इवेंट विशेषताओं की जांच करने के लिए वर्चुअल पैच नियम सक्षम करें जो postmeta पैरामीटर को लक्षित करते हैं।.
3. संदिग्ध मेटा मानों को खोजने के लिए DB क्वेरी चलाएं; समीक्षा के लिए परिणामों को निर्यात करें।.
4. पुष्टि किए गए दुर्भावनापूर्ण प्रविष्टियों को हटा दें और अस्पष्ट प्रविष्टियों को साफ करें।.
5. सभी प्रशासकों के लिए पासवर्ड रीसेट करें; 2FA लागू करें।.
6. संशोधित फ़ाइलों और अज्ञात PHP फ़ाइलों के लिए फ़ाइल सिस्टम को स्कैन करें।.
7. यदि सुधार अनिश्चित है तो साफ बैकअप से पुनर्स्थापित करें।.
8. पुनरावृत्त प्रयासों के लिए लॉग की निगरानी करें; दोषी IP को ब्लॉक करें।.

---

इस प्रकार की बग को समाप्त करने के लिए डेवलपर-फ्रेंडली सिफारिशें

• हमेशा सहेजने पर साफ करें और आउटपुट पर एस्केप करें।.
• WordPress APIs का उपयोग करें: register_post_meta को sanitize कॉलबैक, sanitize_text_field, wp_kses_post, esc_html, esc_attr के साथ।.
• किसी भी प्रशासनिक साइड सहेजने के संचालन के लिए नॉनसेस और क्षमता जांच का उपयोग करें।.
• कच्चा HTML स्टोर करने से बचें जब तक कि यह बिल्कुल आवश्यक न हो; यदि आप ऐसा करते हैं, तो wp_kses के साथ अनुमत टैग और विशेषताओं को सीमित करें।.
• सुरक्षा को CI/CD पाइपलाइन का हिस्सा बनाएं: प्लगइन/थीम रिलीज़ से पहले स्थैतिक विश्लेषण, निर्भरता जांच, और सुरक्षा समीक्षाएँ।.

---

कैसे सत्यापित करें कि आपकी साइट अब कमजोर नहीं है

1. सुनिश्चित करें कि AddFunc हेड और फ़ुटर कोड 2.4 या बाद के संस्करण में अपडेट किया गया है।.
2. सत्यापित करें कि कोई पोस्टमेटा प्रविष्टियाँ नहीं हैं जिनमें 3. या इवेंट विशेषताएँ हैं जिन्हें निष्पादित किया जा सकता है।.
3. पुष्टि करें कि साइट के फ्रंट-एंड और प्रशासनिक पृष्ठ कस्टम फ़ील्ड आउटपुट को एस्केप करते हैं।.
4. अपने WAF लॉग की जांच करें कि क्या कोई प्रयास अवरुद्ध हुए हैं और सुनिश्चित करें कि आपके पास लॉगिंग/अलर्टिंग सक्षम है।.
5. एक पूर्ण मैलवेयर स्कैन चलाएं और फ़ाइल की अखंडता की पुष्टि करें।.

---

WP­Firewall से मुफ्त सुरक्षा के साथ शुरू करें

आपकी वर्डप्रेस साइट की सुरक्षा जटिल नहीं होनी चाहिए। यदि आप प्लगइन अपडेट की समीक्षा करते समय और किसी संदिग्ध सामग्री को साफ करते समय तत्काल आधारभूत सुरक्षा चाहते हैं, तो WP­Firewall की मुफ्त बेसिक योजना के लिए साइन अप करने पर विचार करें। मुफ्त योजना में एक सक्रिय रूप से प्रबंधित फ़ायरवॉल, असीमित बैंडविड्थ, एक WAF, एक मैलवेयर स्कैनर, और OWASP टॉप 10 जोखिमों के लिए शमन कवरेज शामिल है - जो कई सामान्य शोषण प्रयासों को अवरुद्ध करने के लिए पर्याप्त है और आपकी टीम को सुरक्षित रूप से सुधार लागू करने के लिए समय देती है। यहाँ WP­Firewall बेसिक को मुफ्त में आजमाएं: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(यदि आप स्वचालित मैलवेयर हटाने और IP ब्लैकलिस्ट जैसी अधिक उन्नत नियंत्रण चाहते हैं, तो हमारी भुगतान योजनाएँ उन सुविधाओं को एक मामूली वार्षिक लागत पर जोड़ती हैं।)

---

अंतिम सिफारिशें - प्राथमिकता कार्रवाई सूची (संक्षिप्त)

1. AddFunc हेड और फ़ुटर कोड को अब 2.4+ में अपडेट करें।.
2. यदि आप तुरंत अपडेट नहीं कर सकते हैं, तो प्लगइन को अवरुद्ध या अक्षम करें और WAF वर्चुअल पैचिंग नियम लागू करें।.
3. दुर्भावनापूर्ण कस्टम-फील्ड प्रविष्टियों को स्कैन और हटाएं।.
4. उपयोगकर्ताओं का ऑडिट करें और विशेषाधिकार प्राप्त खातों के लिए पासवर्ड/2FA लागू करें।.
5. कस्टम फ़ील्ड के लिए सेव-टाइम सैनिटाइजेशन और आउटपुट-टाइम एस्केपिंग को मजबूत करें।.
6. तत्काल सुरक्षा और निगरानी प्राप्त करने के लिए WP­Firewall या एक प्रबंधित WAF का उपयोग करें।.

---

समापन विचार

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

अपडेट लागू करें, संदिग्ध मेटा मानों के लिए स्कैन करें और उन्हें हटाएं, और अपनी साइट के सामने एक WAF रखें - सुरक्षित कोड के लिए स्थायी विकल्प के रूप में नहीं, बल्कि एक आवश्यक मुआवजा नियंत्रण के रूप में जो आपको मूल कारण को ठीक करते समय समय खरीदता है। यदि आप WAF नियमों, वर्चुअल पैचिंग, या एक पोस्ट-घटना सफाई को लागू करने में मदद चाहते हैं, तो WP­Firewall की टीम तेज, वर्डप्रेस-जानकारी शमन में विशेषज्ञता रखती है।.

यदि आप चरण-दर-चरण ऑडिट या सहायता चाहते हैं, तो अपने सुरक्षा प्रदाता से संपर्क करें या WP­Firewall की मुफ्त योजना पर भरोसा करें ताकि आप सुधार करते समय तुरंत बुनियादी सुरक्षा प्राप्त कर सकें।.

सुरक्षित रहें, और कस्टम फ़ील्ड को अविश्वसनीय इनपुट के रूप में मानें - साफ़ करें, बचाएँ, और समीक्षा करें।.

— WP-Firewall सुरक्षा टीम