AddFunc हेड और फुटर कोड XSS (CVE-2026-2305): वर्डप्रेस साइट मालिकों को क्या जानना चाहिए

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

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

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

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

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

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

मुख्य बिंदु:

• स्थिरता: दुष्ट सामग्री डेटाबेस में संग्रहीत होती है और बाद में ट्रिगर की जा सकती है।.
• विशेषाधिकार वृद्धि: यदि प्रशासनिक उपयोगकर्ता डैशबोर्ड में संक्रमित सामग्री को देखते हैं, तो एक हमलावर प्रशासन के प्रमाणित सत्र का उपयोग करके पिवट कर सकता है।.
• वास्तविक हमले के वेक्टर में CSRF को XSS के साथ मिलाकर विशेषाधिकार प्राप्त क्रियाएँ करना शामिल है (प्रशासनिक खाते बनाना, विकल्प बदलना, कोड स्थापित करना)।.

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

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

कुछ सलाहकार “उपयोगकर्ता इंटरैक्शन आवश्यक” सूचीबद्ध करते हैं - व्यावहारिक रूप से इंटरैक्शन पोस्ट संपादक खोलने या एक तैयार पूर्वावलोकन लिंक के रूप में सरल हो सकता है।.

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

1. प्लगइन को अपडेट करें - यदि आप AddFunc Head & Footer Code का उपयोग करते हैं, तो तुरंत 2.4 या बाद के संस्करण में अपडेट करें। यह मानक समाधान है।.
2. यदि आप तुरंत अपडेट नहीं कर सकते
   • अस्थायी रूप से प्लगइन को हटा दें या अक्षम करें।.
   • पैच होने तक योगदानकर्ताओं को कस्टम फ़ील्ड जोड़ने या संपादित करने से रोकें।.
   • यदि आपके पास वह क्षमता है तो WAF स्तर पर आभासी पैचिंग लागू करें (नीचे WAF मार्गदर्शन देखें)।.
3. कस्टम फ़ील्ड में दुर्भावनापूर्ण सामग्री के लिए स्कैन करें

   <script, onerror=, javascript:, और अन्य संदिग्ध HTML पैटर्न वाले मेटा मानों को खोजने के लिए WP-CLI या सीधे DB क्वेरी (बैकअप के साथ) का उपयोग करें।.

4. उपयोगकर्ता खातों का ऑडिट करें - योगदानकर्ताओं और संपादकों की पुष्टि करें; पुराने या संदिग्ध खातों को हटा दें। विशेषाधिकार प्राप्त भूमिकाओं के लिए मजबूत पासवर्ड और 2FA लागू करें।.
5. समझौते के संकेतों की जांच करें - अज्ञात प्रशासनिक खाते, अप्रत्याशित प्लगइन/थीम फ़ाइलें, संशोधित फ़ाइलें, अनुसूचित कार्य, या आउटबाउंड कनेक्शन।.
6. क्रेडेंशियल्स को घुमाएं यदि समझौता होने का संदेह है - प्रशासनिक पासवर्ड रीसेट करें, API कुंजियाँ रद्द करें, और सत्रों को अमान्य करें।.
7. सफाई से पहले बैकअप - साक्ष्य को संरक्षित करने और रोलबैक की अनुमति देने के लिए सुधारात्मक परिवर्तनों को करने से पहले पूर्ण फ़ाइलें + DB बैकअप लें।.
8. कस्टम फ़ील्ड को मजबूत करें - सहेजने पर स्वच्छता और आउटपुट पर एस्केपिंग की आवश्यकता है (नीचे डेवलपर मार्गदर्शन देखें)।.

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

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

#  शामिल पोस्टमेटा खोजें"

संदिग्ध मेटा मानों को निर्यात करें, उनका निरीक्षण करें और तय करें कि उन्हें साफ करना है या हटाना है।.

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

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

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

<?php

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

डेवलपर मार्गदर्शन: सहेजने का समय साफ करना और आउटपुट एस्केपिंग

इस प्रकार की बग के लिए मूल कारण आमतौर पर इनपुट पर साफ करने की कमी और आउटपुट पर एस्केपिंग की कमी होती है। दोनों लागू करें:

1. सहेजने पर साफ करें ताकि संग्रहीत डेटा सुरक्षित हो।.
2. आउटपुट पर एस्केप करें ताकि रेंडरिंग कभी भी डेटाबेस सामग्री पर भरोसा न करे।.

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

<?php

<?php

REST अनुरोधों को स्वचालित रूप से साफ करने के लिए एक साफ़ कॉलबैक के साथ मेटा पंजीकरण पर विचार करें:

<?php

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

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

• ज्ञात मेटा फ़ील्ड नामों (postmeta, meta[], acf, आदि) में संदिग्ध स्क्रिप्ट पेलोड शामिल करने वाले POST अनुरोधों को रोकना।.
• टैग, इवेंट एट्रिब्यूट (onerror=, onload=), javascript: URI, base64-encoded स्क्रिप्ट, या ऑबफस्केशन पैटर्न वाले अनुरोधों को ब्लॉक या सैनिटाइज करना।.
• निम्न-privileged उपयोगकर्ताओं से पोस्ट बनाने/अपडेट करने वाले POSTs पर दर-सीमा लगाना।.

वैचारिक pseudo-rule उदाहरण (केवल चित्रण के लिए):

# यदि पोस्ट संपादित करने या REST पोस्ट अंत बिंदु पर POST किया जाए और कोई भी पैरामीटर नाम meta/postmeta/acf जैसा दिखता है.

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

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

प्रारंभिक बिंदु के रूप में उपयोग करने के लिए चित्रण पैटर्न:

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

# onerror= या onload= जैसे इवेंट एट्रिब्यूट का पता लगाने के लिए नियम का उदाहरण"

हमेशा नियमों को अपनी साइट के लिए ट्यून करें ताकि झूठे सकारात्मक कम हों; लॉग-केवल मोड प्रारंभिक ट्यूनिंग अवधि के लिए उपयोगी है।.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

समापन विचार

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

यदि आपको WAF नियमों, वर्चुअल पैचिंग, या घटना के बाद की सफाई को लागू करने में सहायता की आवश्यकता है, तो अपने चुने हुए सुरक्षा प्रदाता या एक विश्वसनीय डेवलपर से संपर्क करें जो WordPress-विशिष्ट अनुरोध पैटर्न और REST एंडपॉइंट को समझता है।.

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

— हांगकांग सुरक्षा विशेषज्ञ