प्लगइन का नाम	प्लगइन README पार्सर
कमजोरियों का प्रकार	प्रमाणित संग्रहीत XSS
CVE संख्या	CVE-2025-8720
तात्कालिकता	कम
CVE प्रकाशन तिथि	2025-08-15
स्रोत URL	CVE-2025-8720

प्रमाणित योगदानकर्ता द्वारा README पार्सर में संग्रहीत XSS (<= 1.3.15) — साइट मालिकों और डेवलपर्स को अब क्या करना चाहिए

सारांश: एक संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS) भेद्यता (CVE-2025-8720) वर्डप्रेस README पार्सर प्लगइन के संस्करणों को 1.3.15 तक और शामिल करते हुए प्रभावित करती है। एक प्रमाणित उपयोगकर्ता जिसके पास योगदानकर्ता (या उच्च) विशेषाधिकार हैं, HTML/JavaScript इंजेक्ट कर सकता है जो संग्रहीत होगा और बाद में प्रस्तुत किया जाएगा, जिससे दर्शकों (प्रशासकों सहित) के संदर्भ में स्क्रिप्ट निष्पादन होगा। यह सलाह जोखिम, वास्तविक हमले के परिदृश्य, पहचान तकनीक, और ठोस शमन और मजबूत करने के कदमों को समझाती है जिन्हें आप तुरंत लागू कर सकते हैं।.

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

त्वरित तथ्य

भेद्यता: संग्रहीत क्रॉस-साइट स्क्रिप्टिंग (XSS)
प्रभावित सॉफ़्टवेयर: वर्डप्रेस के लिए README पार्सर प्लगइन
कमजोर संस्करण: <= 1.3.15
CVE: CVE-2025-8720
शोषण के लिए आवश्यक विशेषाधिकार: योगदानकर्ता या उच्च
गंभीरता / CVSS: मध्यम (रिपोर्ट किया गया CVSS 6.5)
आधिकारिक सुधार: प्रकाशन समय पर उपलब्ध नहीं (शमन लागू करें)
प्रकाशित तिथि: 15 अगस्त 2025
रिपोर्टर क्रेडिट: शोधकर्ता जिन्होंने जिम्मेदारी से खुलासा किया

क्या हुआ — साधारण भाषा

README पार्सर प्लगइन एक पैरामीटर स्वीकार करता है जिसका नाम है लक्ष्य जो HTML सामग्री या डेटा ले जा सकता है जिसका उपयोग README-जैसा आउटपुट बनाने के लिए किया जाता है। संस्करण 1.3.15 तक, प्लगइन प्रमाणित उपयोगकर्ताओं से अविश्वसनीय इनपुट को ठीक से साफ़ या एन्कोड नहीं करता है जिनके पास योगदानकर्ता विशेषाधिकार हैं। क्योंकि वह सामग्री संग्रहीत होती है और बाद में प्रस्तुत की जाती है (सर्वर-साइड या क्लाइंट-साइड), एक दुर्भावनापूर्ण योगदानकर्ता HTML या JavaScript डाल सकता है जो प्रस्तुत आउटपुट को देखने वाले किसी भी व्यक्ति के संदर्भ में निष्पादित होगा — प्रशासकों सहित।.

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

यह आपके वर्डप्रेस साइट के लिए क्यों महत्वपूर्ण है

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

इसे किसे पढ़ना चाहिए

Site owners running the README Parser plugin (<= 1.3.15).
बहु-लेखक ब्लॉग या सदस्यता साइटों के व्यवस्थापक जहां उपयोगकर्ताओं के पास योगदानकर्ता विशेषताएँ हैं।.
डेवलपर्स और प्लगइन लेखक जो समान समस्याओं को रोकने के लिए सुरक्षित पैटर्न की तलाश कर रहे हैं।.
वेब होस्ट और प्रबंधित वर्डप्रेस प्रदाता जो होस्ट-स्तरीय वर्चुअल पैचिंग लागू कर रहे हैं।.

हमले के परिदृश्य (वास्तविक)

खुली योगदानकर्ता साइन-अप के साथ सामुदायिक ब्लॉग:

एक हमलावर एक योगदानकर्ता खाता पंजीकृत करता है या प्राप्त करता है और एक तैयार की गई सामग्री या मेटाडेटा प्रस्तुत करता है जिसमें स्क्रिप्ट करने योग्य HTML होता है। लक्ष्य जब एक व्यवस्थापक बाद में प्लगइन व्यवस्थापक पृष्ठ या एक फ्रंट-एंड पृष्ठ पर जाता है जो पार्स किए गए README को प्रस्तुत करता है, तो दुर्भावनापूर्ण स्क्रिप्ट निष्पादित होती है और व्यवस्थापक के संदर्भ में कार्य कर सकती है।.
एक संपादक/लेखक को सामाजिक इंजीनियरिंग करना:

एक हमलावर एक पेलोड इंजेक्ट करता है जो स्वचालित रूप से तब चलता है जब एक संपादक सामग्री का पूर्वावलोकन या संपादन करता है; यदि CSRF सुरक्षा को बायपास किया जाता है तो स्क्रिप्ट XHR POSTs के माध्यम से विशेषाधिकार प्राप्त कार्य कर सकती है।.
सामूहिक वितरण:

चूंकि इंजेक्शन संग्रहीत है, प्रभावित सामग्री के प्रत्येक भविष्य के दर्शक (सदस्य, संपादक, व्यवस्थापक) प्रभावित हो सकते हैं, जिससे विस्फोटक क्षेत्र बढ़ता है।.

आपको अब क्या करना चाहिए - चरण-दर-चरण

If you run WordPress and have the README Parser plugin (<= 1.3.15) installed, follow these steps in order:

तात्कालिक नियंत्रण
- उन भूमिकाओं तक पहुँच को सीमित करें जो प्लगइन-प्रभावित क्षेत्रों को बनाने या संपादित करने में सक्षम हैं। यदि संभव हो तो सार्वजनिक योगदानकर्ता पंजीकरण को अस्थायी रूप से निष्क्रिय करें।.
- यदि आपके पास पहुँच नियंत्रण हैं, तो अस्थायी रूप से अविश्वसनीय खातों को प्लगइन द्वारा उपयोग किए जाने वाले व्यवस्थापक पृष्ठों तक पहुँचने से रोकें।.
प्लगइन को हटा दें या निष्क्रिय करें (यदि आपको इसकी आवश्यकता नहीं है)
- यदि प्लगइन महत्वपूर्ण नहीं है, तो इसे निष्क्रिय करें और आधिकारिक पैच जारी होने तक हटा दें।.
- यदि हटाना संभव नहीं है, तो नीचे दिए गए निर्देशों के अनुसार आभासी पैच लागू करें या इसे मजबूत करें।.
आभासी पैच लागू करें (WAF / फ़ायरवॉल)
- दुर्भावनापूर्ण पेलोड को अवरुद्ध करने के लिए नियम लागू करें लक्ष्य पैरामीटर या अन्य इनपुट जो प्लगइन द्वारा संभाले जाते हैं। उदाहरण नियम इस पोस्ट में बाद में प्रदान किए गए हैं।.
डेटाबेस और व्यवस्थापक उपयोगकर्ताओं का ऑडिट करें
- हाल की परिवर्तनों की खोज करें जो रीडमी-जैसे सामग्री या किसी भी फ़ील्ड को संसाधित करते हैं जो प्लगइन में शामिल हैं , onerror=, javascript:, or other suspicious tokens.



    Reset credentials

Force password resets for administrators and consider invalidating active sessions. Rotate API keys for third-party integrations if applicable.



    Post-incident: update plugin

When an official fixed release is available, update immediately. If you removed the plugin, only reinstall after confirming the fix.



    Review privileges and workflows

Limit who can obtain Contributor or Editor roles and enforce review workflows that sanitize untrusted inputs before rendering.



Detection — what to look for
Search the database and logs for signs of stored XSS and related activity. Run queries from a trusted DBA context and ensure you have a backup.
Example SQL to find likely injected content:
-- Search post content and postmeta for script tags or on* attributes
SELECT ID, post_title, post_date
FROM wp_posts
WHERE post_content LIKE '%

Search access logs for suspicious query strings:

Requests with target= parameters containing encoded script strings: %3Cscript, %3Cimg, %3Con, %3Ciframe
POSTs creating or editing content from low-privilege accounts

Log indicators:

Admin pages returning success on actions shortly after a contributor edit
Multiple previews or admin views for a particular post by administrators after a contributor update

Look for indicators of compromise such as suspicious admin accounts created after suspected injection, unexpected plugin files, modified themes, or rogue cron jobs.

Practical hardening and developer fixes
If you maintain the README Parser plugin (or any plugin that accepts and renders user-supplied HTML), apply these secure coding practices:


    Sanitize input on entry, escape on output
Sanitize user-supplied input when saving and escape at output. Use WordPress APIs: sanitize_text_field(), esc_html(), esc_attr(), esc_url(), and wp_kses() with an explicit whitelist.


    Use wp_kses for controlled HTML
If a limited subset of HTML is required, whitelist tags and attributes. Avoid allowing on* attributes or javascript:/data: protocols.
$allowed = array(
  'a' => array(
    'href' => true,
    'title' => true,
    'rel'   => true,
  ),
  'br' => array(),
  'em' => array(),
  'strong' => array(),
  'p' => array(),
  'ul' => array(),
  'li' => array(),
);
$clean_html = wp_kses( $input, $allowed );


    Enforce capability checks and nonces
if ( ! current_user_can( 'edit_posts' ) ) {
  return;
}
if ( ! isset( $_POST['my_plugin_nonce'] ) || ! wp_verify_nonce( $_POST['my_plugin_nonce'], 'my_plugin_save' ) ) {
  return;
}


    Escape output in all contexts
Use esc_attr() for attributes, esc_html() for text nodes, and only print wp_kses()-sanitised HTML.


    Restrict fields that accept raw HTML
If target was intended as a slug or ID, treat it as such and do not accept HTML.


    Use Content Security Policy (CSP) as defence-in-depth
Apply a CSP header that disallows inline scripts and external untrusted sources. Test before roll-out to avoid breaking functionality.
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self';


    Log and monitor content changes
Maintain an audit trail of posts and meta changes (user ID, timestamp) to speed investigation if something is injected.



Virtual patching / WAF rules you can deploy now
If an official plugin update is not yet available, virtual patching via a Web Application Firewall (WAF) or host-level filtering is the fastest way to protect sites at scale. The rules below target common stored XSS payloads. Tune them to reduce false positives on sites that legitimately allow HTML.
Example ModSecurity rule set (conceptual)
# Block suspicious script tags in 'target' parameter (URL or POST data)
SecRule ARGS:target "(?i)(%3C|<)\s*script" "id:100001,phase:2,deny,status:403,msg:'Blocked XSS attempt - script tag in target',log"

# Block javascript: and data: in URL-like inputs
SecRule ARGS:target "(?i)javascript:|data:text/html" "id:100002,phase:2,deny,status:403,msg:'Blocked XSS attempt - protocol in target',log"

# Block common on* event attributes inside parameters (encoded or plain)
SecRule ARGS:target "(?i)on\w+\s*=" "id:100003,phase:2,deny,status:403,msg:'Blocked XSS attempt - event handler attribute in target',log"

# Block suspicious encoded payloads (double-encoded 

NGINX (lua / pseudocode)
# if ngx_lua available, inspect request args
access_by_lua_block {
  local args = ngx.req.get_uri_args()
  local target = args["target"]
  if target then
    local lower = string.lower(target)
    if string.find(lower, "

Regex tips for signatures: detect , , on\w+\s*=, javascript:, encoded forms like %3Cscript, and double-encoded sequences like %253C or %25 patterns. Limit rules to the specific parameter(s) the plugin uses (e.g., target) to reduce false positives.

If you operate an application-level filter, create a rule to forbid HTML tags or on* attributes inside the target parameter and either reject or sanitise them before saving.

Safe remediation code snippets (plugin-level fixes)
If you maintain the affected plugin and want a quick remediation before an upstream patch, sanitise the target parameter on save and escape on output.
Sanitise before saving:
if ( isset( $_POST['target'] ) ) {
    // Remove HTML tags entirely if this parameter is meant to be plain text
    $target_clean = sanitize_text_field( wp_unslash( $_POST['target'] ) );

    // OR: allow only safe HTML using wp_kses
    $allowed = array( 'a' => array( 'href' => true, 'title' => true ) );
    $target_clean = wp_kses( wp_unslash( $_POST['target'] ), $allowed );

    update_post_meta( $post_id, 'plugin_readme_target', $target_clean );
}
Output with safety:
$stored = get_post_meta( $post_id, 'plugin_readme_target', true );
// Use esc_attr if printing into an attribute, or esc_html if in text node
echo esc_html( $stored );
If target is used to build a URL, validate with esc_url_raw() on save and esc_url() on render.

Incident response — when you suspect compromise
If you find evidence of exploitation:

Isolate the site: Put the site into maintenance mode and block public access if feasible.
Snapshot and backup: Create a full backup (files and DB) before making changes.
Clean injected content: Remove malicious HTML from posts, postmeta and options. Use SQL updates carefully and only after backing up.
Audit users and reset credentials: Reset admin passwords, force password resets for privileged accounts, and revoke suspicious admin users.
Scan for persistence: Check theme and plugin files for new or modified files, scheduled tasks (wp_cron), and wp-config.php for added code.
Reinstall plugins/themes from trusted sources: Replace plugin files with fresh copies from the official WordPress repository after confirming the plugin version is untampered.
Restore if necessary: If you cannot clean safely, restore from a known-good backup and apply WAF rules until a patch is available.
Consider professional response: For large or sensitive sites, engage incident-response specialists.


Recommendations for site owners and hosts

Limit Contributor capability where feasible. Require moderator review of submitted content on community sites.
Enable multi-factor authentication for all administrators.
Use host-level or application-level filtering that supports virtual patching while awaiting official fixes.
Keep audit logs and activity monitoring active. Detecting suspicious admin page views after contributor updates is a key indicator.
Educate editors and admins to avoid previewing untrusted content in admin consoles until content has been sanitized or reviewed.


For plugin authors — guidelines to prevent similar issues

Treat all user input as hostile, even from authenticated users.
Assume that stored data may be rendered in contexts that allow script execution (admin pages, front-end, REST responses).
Provide escaping and sanitising options in code; do not rely solely on output context.
Document expected input for each field and enforce validation on save.
Consider storing both raw data and a sanitized/rendered variant — ensure the sanitized variant is used for presentation.
Conduct threat modelling: consider where saved plugin metadata might later be rendered in admin screens accessed by privileged users.


Example detection regexes and DB-SQL queries
Quick regex examples (for log scanning or SIEM):

Detect script tag: (?i)(<|%3[cC])\s*script
Detect event handlers: (?i)on[a-z]+\s*=
Detect javascript: protocol: (?i)javascript\s*:
Detect double-encoding: (?i)%25[0-9a-f]{2}

SQL search examples:
-- Find meta values with html/script content
SELECT meta_id, post_id, meta_key, meta_value
FROM wp_postmeta
WHERE meta_value REGEXP '(?i)


What about Content Security Policy (CSP) and browser defenses?
CSP is a powerful additional defence that reduces the impact of XSS by disallowing inline scripts and restricting script origins. Implementing a strict CSP may require refactoring; however, a moderate CSP (for example, script-src 'self' and forbidding unsafe-inline) raises the bar for exploitation.
Note: CSP complements but does not replace proper input sanitisation and escaping.

Recovery checklist (quick)

Deactivate/remove README Parser plugin (if possible) or restrict access
Apply WAF signatures blocking target payloads (see examples)
Search DB for suspicious HTML and clean
Rotate admin passwords and revoke sessions
Audit users and recent admin actions
Reinstall plugin from the official repository after an official fix
Apply developer hardening measures to plugin code
Add a CSP header as defence-in-depth
Enable monitoring to detect future attempts


Example: Minimal aggressive ModSecurity rule to block target parameter
Use with caution — test for false positives.
SecRule REQUEST_METHOD "@streq POST" "id:100200,phase:2,pass,nolog,chain"
  SecRule ARGS:target "(?i)(%3C|<)\s*(script|img|iframe|svg|object)|javascript:|on[a-z]{1,20}\s*=" "id:100201,phase:2,deny,status:403,msg:'Aggressive protection - blocked possible stored XSS in target parameter'"

# This drops POSTs that include script-like content in target. If your site legitimately posts HTML in 'target', use a less aggressive rule that logs and alerts first.

Timeline and disclosure notes

Vulnerability published: 15 August 2025
CVE assigned: CVE-2025-8720
Required privilege: Contributor (authenticated)
Official vendor patch: Not available at time of writing — follow the vendor’s update channels and apply this guidance until a patch is released


Final recommendations — prioritized

If you can remove the plugin without impacting functionality: do so immediately.
If removal is not possible: deploy targeted WAF rules to block the target parameter from carrying script-like content and monitor logs carefully.
Audit and clean the database for injected content.
Short-term: restrict contributor signups and limit privileges.
Mid-term: patch plugin code using wp_kses() and strict capability/nonces; long-term: adopt CSP and continuous monitoring.


Stored XSS remains a frequent and serious issue because it combines persistent data with contexts that can be powerful (administrator browsers). Defend in layers: remove or update vulnerable software, sanitise input and escape output rigorously, enforce least privilege for users, and apply targeted virtual patching while waiting for upstream fixes.
— Hong Kong Security Researcher

हांगकांग सुरक्षा वर्डप्रेस README पार्सर XSS(CVE20258720)

प्रमाणित योगदानकर्ता द्वारा README पार्सर में संग्रहीत XSS (<= 1.3.15) — साइट मालिकों और डेवलपर्स को अब क्या करना चाहिए

त्वरित तथ्य

क्या हुआ — साधारण भाषा

यह आपके वर्डप्रेस साइट के लिए क्यों महत्वपूर्ण है

इसे किसे पढ़ना चाहिए

हमले के परिदृश्य (वास्तविक)

आपको अब क्या करना चाहिए - चरण-दर-चरण

Detection — what to look for

Practical hardening and developer fixes

Virtual patching / WAF rules you can deploy now

Example ModSecurity rule set (conceptual)

NGINX (lua / pseudocode)

Safe remediation code snippets (plugin-level fixes)

Incident response — when you suspect compromise

Recommendations for site owners and hosts

For plugin authors — guidelines to prevent similar issues

Example detection regexes and DB-SQL queries

What about Content Security Policy (CSP) and browser defenses?

Recovery checklist (quick)

Example: Minimal aggressive ModSecurity rule to block `target` parameter

Timeline and disclosure notes

Final recommendations — prioritized

टैग:

WP Security Vulnerability Report

HK Security Alert WordPress AI Pack Bypass(CVE20257664)

HK Security NGO alerts NextGEN Directory Deletion(CVE20257641)

Safeguarding Hong Kong Websites Against Cyber Threats(CVE20268425)

Hong Kong Security Alert XSS in WordPress(CVE20260743)

Hong Kong NGO Warns WordPress Data Exposure(CVE20261867)

Community Alert Hub Theme Authorization Weakness(CVE20250951)

HK Security Authenticated WooCommerce POs File Deletion(CVE20255391)

Diza Theme Local File Inclusion Advisory(CVE202568543)

हांगकांग सुरक्षा वर्डप्रेस README पार्सर XSS(CVE20258720)

प्रमाणित योगदानकर्ता द्वारा README पार्सर में संग्रहीत XSS (<= 1.3.15) — साइट मालिकों और डेवलपर्स को अब क्या करना चाहिए

त्वरित तथ्य

क्या हुआ — साधारण भाषा

यह आपके वर्डप्रेस साइट के लिए क्यों महत्वपूर्ण है

इसे किसे पढ़ना चाहिए

हमले के परिदृश्य (वास्तविक)

आपको अब क्या करना चाहिए - चरण-दर-चरण

Detection — what to look for

Practical hardening and developer fixes

Virtual patching / WAF rules you can deploy now

Example ModSecurity rule set (conceptual)

NGINX (lua / pseudocode)

Safe remediation code snippets (plugin-level fixes)

Incident response — when you suspect compromise

Recommendations for site owners and hosts

For plugin authors — guidelines to prevent similar issues

Example detection regexes and DB-SQL queries

What about Content Security Policy (CSP) and browser defenses?

Recovery checklist (quick)

Example: Minimal aggressive ModSecurity rule to block target parameter

Timeline and disclosure notes

Final recommendations — prioritized

टैग:

WP Security Vulnerability Report

HK Security Alert WordPress AI Pack Bypass(CVE20257664)

HK Security NGO alerts NextGEN Directory Deletion(CVE20257641)

आपको यह भी पसंद आ सकता है

Example: Minimal aggressive ModSecurity rule to block `target` parameter