अवलोकन

1 जून 2026 को वर्ड प्रतिस्थापक वर्डप्रेस प्लगइन (संस्करण ≤ 0.4) में संग्रहीत क्रॉस-साइट स्क्रिप्टिंग भेद्यता को सार्वजनिक रूप से उजागर किया गया और इसे CVE-2026-3620 सौंपा गया। यह समस्या एक प्रमाणित, केवल प्रशासक द्वारा संग्रहीत XSS है — जिसका अर्थ है कि वर्डप्रेस में प्रशासक विशेषाधिकार वाले उपयोगकर्ता हानिकारक इनपुट को सहेज सकते हैं जो बाद में उचित एस्केपिंग के बिना प्रस्तुत किया जाता है, जिससे साइट आगंतुकों या अन्य प्रशासनिक उपयोगकर्ताओं के ब्राउज़र में जावास्क्रिप्ट निष्पादित होता है।.

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

यह मार्गदर्शन बताता है कि भेद्यता कैसे काम करती है, वास्तविकवादी हमले के परिदृश्य, पहचान संकेतक, रोकथाम और शमन के कदम (अस्थायी सुधार सहित), दीर्घकालिक सख्ती, और मूल कारण को ठीक करने के लिए डेवलपर मार्गदर्शन।.

श्रेय: सार्वजनिक सलाह में उजागर की गई भेद्यता (CVE-2026-3620)। अनुसंधान का श्रेय san6051 (COFFSec) को दिया गया।.

What is Stored XSS and why is an “authenticated admin” vector important?

संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS) तब होती है जब एक हमलावर सर्वर-साइड डेटा (डेटाबेस, विकल्प तालिका, पोस्ट, प्लगइन सेटिंग्स, आदि) में एक हानिकारक स्क्रिप्ट संग्रहीत करता है और वह स्क्रिप्ट बाद में अन्य उपयोगकर्ताओं को उचित एस्केपिंग या स्वच्छता के बिना प्रदान की जाती है। चूंकि पेलोड स्थायी है, इसलिए समय के साथ कई आगंतुकों और उपयोगकर्ताओं पर प्रभाव पड़ सकता है।.

An “authenticated administrator” qualifier means only accounts with Administrator capabilities can save the malicious payload. That reduces the immediate attack surface compared to unauthenticated bugs, but it remains dangerous because:

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

Even “admin-only” stored XSS can lead to full site compromise when combined with real-world attacker techniques.

वर्ड प्रतिस्थापक भेद्यता कैसे काम करती है (उच्च-स्तरीय)

मुख्य तकनीकी समस्या सीधी है:

1. प्लगइन प्रशासकों के लिए प्रतिस्थापन नियम परिभाषित करने के लिए एक UI प्रदान करता है जो डेटाबेस में संग्रहीत होते हैं।.
2. जब उन सेटिंग्स को सहेजा जाता है, तो प्लगइन प्रतिस्थापन सामग्री को उचित रूप से स्वच्छ या मान्य करने में विफल रहता है।.
3. जब प्लगइन उन संग्रहीत मानों को फ्रंट-एंड या प्रशासनिक डैशबोर्ड में प्रदर्शित करता है, तो यह सामग्री को HTML में बिना एस्केप किए आउटपुट करता है, जिससे एम्बेडेड जावास्क्रिप्ट को निष्पादित करने की अनुमति मिलती है।.
4. स्क्रिप्ट साइट के मूल के साथ चलती है, जिससे पीड़ित आगंतुक या प्रशासक के रूप में क्रियाएँ करने की अनुमति मिलती है।.

सामान्य असुरक्षित पैटर्न में शामिल हैं:

• कच्चे HTML या अनएस्केप किए गए पाठ को संग्रहीत करना और इसे सीधे इको करना (जैसे, echo $value;) बजाय esc_html(), esc_attr() या wp_kses() का उपयोग करने के।.
• प्रतिस्थापन स्ट्रिंग्स बनाना जो पृष्ठ HTML या विशेषताओं में उचित एस्केपिंग के बिना डाले जाते हैं।.
• इवेंट हैंडलर्स या javascript: URIs को प्रविष्टियों के हिस्से के रूप में सहेजने की अनुमति देना।.

यथार्थवादी हमले के परिदृश्य

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

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

प्रभाव और सामान्य हमलावर के लक्ष्य

एक बार संग्रहीत XSS निष्पादित होने पर, हमलावर आमतौर पर निम्नलिखित लक्ष्यों की ओर बढ़ते हैं:

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

CVE और गंभीरता संदर्भ

• CVE पहचानकर्ता: CVE-2026-3620
• प्रभावित संस्करण: वर्ड रिप्लेसर प्लगइन ≤ 0.4
• प्रकार: संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS)
• आवश्यक विशेषाधिकार: प्रशासक
• पैच स्थिति (प्रकटीकरण पर): कोई आधिकारिक प्लगइन पैच उपलब्ध नहीं है
• CVSS आधार: 5.9
• अनुसंधान श्रेय: san6051 (COFFSec)

Even with a “medium” CVSS, treat this vulnerability as urgent for sites where admin accounts are at risk or where administrators accept input from third parties.

पहचान — समझौते के संकेत

प्रमुख पहचान तकनीकें:

1. संदिग्ध प्रतिस्थापन नियमों या प्रविष्टियों के लिए डेटाबेस में खोजें:

   Look for HTML tags (<script>, <iframe>) or event attributes (onclick, onmouseover) stored in options or post meta.

   Example SQL queries:

   SELECT option_name, option_value
   FROM wp_options
   WHERE option_name LIKE '%word_replac%' OR option_name LIKE '%word_replacer%';
   
   SELECT * FROM wp_postmeta WHERE meta_value LIKE '%<script%';
   
   SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';

   Inspect for encoded payloads (base64), “javascript:” URIs, eval(, document.cookie, XMLHttpRequest, fetch(.

2. Scan front-end pages: Crawl public pages and grep for unexpected inline <script> tags or event handlers not originating from known plugins/themes.
3. Audit admin pages and user lists: Check for new admin users and recent changes to plugin/theme files.
4. Server and application logs: Look for POSTs to admin pages or import endpoints, unusual user agents, or source IPs.
5. Malware scanners: Use WordPress-aware scanners to find injected JS or common patterns.
6. आउटबाउंड कनेक्शनों की निगरानी करें: Unexpected outbound HTTPS requests after suspicious entries were added can indicate live exploitation.

Immediate containment & triage (what to do now)

If your site uses the vulnerable Word Replacer plugin (≤ 0.4), act immediately:

1. Isolate admin accounts: Force password reset for all Administrators and enable or enforce MFA.
2. प्लगइन को निष्क्रिय या हटा दें: If safe to do so, deactivate and delete Word Replacer until a patched release is available.
3. Scan for malicious stored content: Search options/postmeta for <script>, javascript:, on* attributes and remove or sanitize suspicious entries. Export data first for forensic preservation if needed.
4. Inspect users and files: Remove unknown admin accounts; compare plugin/theme files against clean copies.
5. बैकअप: Take a full backup (files + DB) immediately for forensic preservation, then create a clean restore point.
6. Logs and forensics: Preserve webserver and PHP logs around the window of possible compromise.
7. संवाद करें: For e-commerce or membership sites, be ready to notify stakeholders if user data may have been exposed.

WAF या सर्वर नियमों के माध्यम से आभासी पैचिंग

If you cannot remove the plugin immediately, virtual patching through a Web Application Firewall (WAF) or server-level rules is an effective temporary mitigation. Operators can deploy rules to:

• Block admin POST submissions that contain <script>, “javascript:” URIs, or inline event handlers in fields associated with the plugin.
• Restrict access to the plugin admin page to trusted IP ranges.
• Sanitize or strip dangerous input patterns on the fly.

Example ModSecurity-style rule (illustrative — test in staging):

SecRule REQUEST_METHOD "@streq POST" "phase:2,chain,deny,id:1003001,log,msg:'Block possible Word Replacer stored XSS payload'"
  SecRule ARGS|ARGS_NAMES "@rx (<script|javascript:|on\w+\s*=|document\.cookie|window\.location)" "t:none,t:urlDecodeUni,log"

Nginx example — block POSTs to a plugin admin page (adjust path & IP list):

location ~* /wp-admin/admin\.php$ {
  if ($request_method = POST) {
    if ($arg_page = "word-replacer") {
      allow 203.0.113.45;   # trusted admin IP
      deny all;
    }
  }
}

Warning: IP-based restrictions can lock out legitimate administrators using dynamic IPs. Test rules in staging before applying to production.

Quick temporary WordPress-level mitigation (mu-plugin)

If you can add a must-use plugin (mu-plugin), you can intercept option updates and sanitize content that looks like it belongs to Word Replacer. Place the file in wp-content/mu-plugins/block-word-replacer-xss.php.

<?php
/**
 * MU plugin: sanitize Word Replacer option updates to remove inline scripts and event handlers.
 * Install: save as wp-content/mu-plugins/block-word-replacer-xss.php
 */

add_filter( 'pre_update_option', function( $new_value, $old_value, $option_name ) {
    if ( strpos( $option_name, 'word_replacer' ) !== false || strpos( $option_name, 'word-replacer' ) !== false ) {
        // Use wp_kses to allow only safe tags and attributes. Adjust allowed tags as needed.
        $allowed = array(
            'a'      => array( 'href' => true, 'title' => true, 'rel' => true ),
            'br'     => array(),
            'em'     => array(),
            'strong' => array(),
            'b'      => array(),
            'i'      => array(),
            'u'      => array(),
            'p'      => array(),
            'ul'     => array(),
            'ol'     => array(),
            'li'     => array(),
        );
        if ( is_string( $new_value ) ) {
            $new_value = wp_kses( $new_value, $allowed );
        }
    }
    return $new_value;
}, 10, 3 );

नोट्स:

• This is a protective stopgap to strip inline JavaScript and unsafe attributes from options matching the plugin. It is not a permanent fix.
• Do not rely on this alone — the plugin code should be fixed at source.

Nginx / Apache blocking for plugin admin UI

If the plugin admin page slug is known (for example: admin.php?page=word-replacer), block direct access by non-trusted IPs at the webserver level.

Nginx example (deny all POSTs to the plugin settings page except specific IPs):

location ~* /wp-admin/admin\.php$ {
  if ( $arg_page = "word-replacer" ) {
    if ( $request_method = POST ) {
      allow 203.0.113.45;  # admin office IP
      deny all;
    }
  }
}

Apache .htaccess example (inside /wp-admin):

<If "%{QUERY_STRING} =~ /page=word-replacer/ && %{REQUEST_METHOD} == 'POST'">
  Require ip 203.0.113.45
</If>

Test carefully — these rules can block legitimate admin activity.

Recovery and clean-up checklist after a confirmed compromise

1. Take the site offline or enable maintenance mode if public traffic is being poisoned.
2. Preserve logs and a forensic backup (full files + DB).
3. Reset credentials for all admin accounts and users with elevated privileges; enforce MFA.
4. Remove malicious replacement entries from the database.
5. Scan and clean the filesystem for injected files or backdoors. Replace modified core, theme and plugin files with fresh copies from trusted sources.
6. Remove unknown plugins/themes and reinstall only from official sources.
7. Rotate API keys, tokens, and any credentials exposed to the admin interface.
8. Restore from a clean backup if infection is widespread and cleanup is not feasible.
9. Re-enable public access only after multiple confirmation scans return clean results.
10. Conduct a post-incident audit to identify how the admin account was compromised (phishing, weak MFA, password reuse) and remediate the root cause.

If you are not confident performing the recovery, engage a professional incident response provider.

Long-term mitigation & best practices

• न्यूनतम विशेषाधिकार का सिद्धांत: Do not use Administrator accounts for everyday tasks; create Editor-level accounts for content editors.
• Minimal admin exposure: Keep the number of admin accounts minimal and review them regularly.
• MFA को लागू करें: सभी प्रशासनिक खातों के लिए बहु-कारक प्रमाणीकरण की आवश्यकता करें।.
• मजबूत पासवर्ड: अद्वितीय, मजबूत पासवर्ड और एक पासवर्ड प्रबंधक का उपयोग करें।.
• फ़ाइल संपादन अक्षम करें: जोड़ें wp-config.php: define( 'DISALLOW_FILE_EDIT', true );
• सॉफ़्टवेयर को अद्यतित रखें: Update WordPress core, themes and plugins; remove unused components.
• Limit plugins: Install plugins from reputable sources and review code for unusual behaviour when possible.
• नियमित स्कैनिंग: Run vulnerability and malware scans and monitor logs for unusual admin activity.
• बैकअप: Maintain automatic backups with offsite copies and periodic restore testing.
• Environment hardening: Use supported PHP versions, correct file permissions, secure hosting and HTTPS everywhere.
• WAF for virtual patching: Use a WAF to apply central rules that can block common exploit payloads while awaiting official plugin patches.

Developer guidance — how to fix this class of bugs properly

Plugin developers should follow these practices to prevent stored XSS:

1. सहेजने पर इनपुट को सैनिटाइज करें: उपयोग करें sanitize_text_field() या sanitize_textarea_field() for plain text. For limited HTML, use wp_kses() एक सख्त व्हाइटलिस्ट के साथ।.
2. रेंडर पर आउटपुट को एस्केप करें: Always escape at the point of output: esc_html(), esc_attr(), esc_url() या wp_kses_post() जैसे उपयुक्त हो।.
3. क्षमता और नॉनसेस जांच: Verify user capabilities and nonces before processing POSTs.
4. कच्चा HTML संग्रहीत करने से बचें: Avoid storing HTML that will later be embedded in attributes or inline scripts.
5. Minimise dynamic JavaScript: Avoid eval() and dynamic JavaScript construction from user content.
6. Document formats and safe defaults: Ensure safe default states for stored values and document expected formats.
7. स्वचालित परीक्षण: Add tests to assert that inputs containing <script> are sanitized/escaped before output.
8. Secure upgrades: Provide clear upgrade paths and changelogs when sanitisation changes stored data formats.

होस्ट और प्रबंधित वर्डप्रेस प्रदाताओं के लिए

Hosting providers can mitigate exposure by:

• Scanning client sites for the vulnerable plugin and notifying customers promptly.
• Temporarily blocking the plugin admin page at the platform level until customers remediate.
• Offering a one-click virtual patch that blocks requests attempting to save script tags to plugin options.
• Assisting customers with forced password resets and enabling MFA.
• Quarantining sites showing active signs of compromise and offering cleanup support where permitted.

Indicators to search for in monitoring and logs

• POST requests to admin pages containing: “<script”, “javascript:”, “onmouseover=”, “onload=”, “document.cookie”, “fetch(“, “XMLHttpRequest(“.
• Unexpected new Administrator accounts.
• File change events in wp-content/plugins या 3. , अप्रत्याशित प्रशासनिक उपयोगकर्ताओं, या में परिवर्तनों के लिए shortly after suspicious admin POSTs.
• Outbound connections to unknown domains originating from the webserver.

Recommended immediate action plan — step by step

1. If the plugin is installed and can be removed safely, deactivate and delete Word Replacer (preferred).
2. If removal is not possible, apply a virtual patch via your WAF or server rules that block suspicious admin POSTs.
3. Force-reset admin passwords and enable MFA.
4. Audit the database for suspicious replacement entries and sanitize or remove them.
5. Scan and clean the site with a WordPress-aware malware scanner and perform file integrity checks.
6. फोरेंसिक विश्लेषण के लिए लॉग और बैकअप को संरक्षित करें।.
7. Monitor traffic and admin logs closely for at least two weeks after remediation.