Authenticated Contributor Stored XSS in README Parser (<= 1.3.15) — What Site Owners and Developers Must Do Now

Summary: A stored Cross-Site Scripting (XSS) vulnerability (CVE-2025-8720) affects the WordPress README Parser plugin versions up to and including 1.3.15. An authenticated user with Contributor (or higher) privileges can inject HTML/JavaScript which will be stored and later rendered, leading to script execution in the context of viewers (including administrators). This advisory explains the risk, realistic attack scenarios, detection techniques, and concrete mitigations and hardening steps you can apply immediately.

Prepared by a Hong Kong-based security researcher with incident-response and hardening experience. The guidance below is practical and prioritised for site owners, developers and operators.

Quick facts

• Vulnerability: Stored Cross-Site Scripting (XSS)
• Affected software: README Parser plugin for WordPress
• Vulnerable versions: <= 1.3.15
• CVE: CVE-2025-8720
• Required privileges to exploit: Contributor or higher
• Severity / CVSS: Medium (reported CVSS 6.5)
• Official fix: Not available at publication time (apply mitigation)
• Date published: 15 August 2025
• Reporter credit: Researcher(s) who disclosed responsibly

What happened — plain language

The README Parser plugin accepts a parameter named target that can carry HTML content or data used to build a README-like output. In versions up to 1.3.15, the plugin does not properly sanitize or encode untrusted input from authenticated users with Contributor privileges. Because that content is stored and later rendered (server-side or client-side), a malicious contributor can insert HTML or JavaScript which will execute in the context of anyone who views the rendered output — including administrators.

This is a stored (persistent) XSS vulnerability. Persistent XSS is more dangerous than reflected XSS because the injected script persists in storage and can affect multiple users repeatedly.

Why this matters to your WordPress site

• Contributor accounts are commonly available on community or multi-author sites. Contributors can often create and edit posts or provide metadata that plugins may parse.
• Stored XSS can be used to:
  • Steal administrator session cookies or authentication tokens (if protections are weak).
  • Perform actions on behalf of an authenticated victim (via forged admin requests).
  • Install backdoors or webshells if combined with other vulnerabilities or social engineering.
  • Display misleading content or redirect visitors.
• A successful stored XSS that runs in an admin’s browser can lead to full site takeover.

Who should read this

• Site owners running the README Parser plugin (<= 1.3.15).
• Administrators of multi-author blogs or membership sites where users have Contributor privileges.
• Developers and plugin authors seeking secure patterns to prevent similar issues.
• Web hosts and managed WordPress providers implementing host-level virtual patching.

Attack scenarios (realistic)

1. Community blog with open contributor sign-ups:

   An attacker registers or obtains a contributor account and submits content or metadata with a crafted target payload containing scriptable HTML. When an administrator later visits the plugin admin page or a front-end page that renders the parsed README, the malicious script executes and can act in the admin’s context.

2. Social-engineering an editor/author:

   An attacker injects a payload that runs automatically when an editor previews or edits content; the script can perform privileged actions via XHR POSTs if CSRF protections are bypassed.

3. Mass distribution:

   Because the injection is stored, every future viewer of the affected content (subscribers, editors, admins) may be impacted, increasing the blast radius.

What you should do now — step-by-step

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

1. Immediate containment
   • Restrict access to roles that can create or edit the plugin-affected fields. Temporarily disable public contributor registration if possible.
   • If you have access controls, temporarily disallow untrusted accounts from reaching the admin pages used by the plugin.
2. Remove or deactivate the plugin (if you do not need it)
   • If the plugin is not critical, deactivate and remove it until an official patch is released.
   • If removal is not possible, apply virtual patches or harden per the instructions below.
3. Apply virtual patch (WAF / firewall)
   • Deploy rules to block malicious payloads in the target parameter or other inputs handled by the plugin. Example rules are provided later in this post.
4. Audit the database and admin users
   • Search for recent changes to readme-like content or any fields processed by the plugin containing , onerror=, javascript:, or other suspicious tokens.
   • Run DB queries to find entries with suspicious HTML (examples below).
   • Check admin activity logs for unexpected account changes, new admin users, or plugin modifications.
5. Reset credentials
   • Force password resets for administrators and consider invalidating active sessions. Rotate API keys for third-party integrations if applicable.
6. Post-incident: update plugin
   • When an official fixed release is available, update immediately. If you removed the plugin, only reinstall after confirming the fix.
7. Review privileges and workflows
   • Limit who can obtain Contributor or Editor roles and enforce review workflows that sanitize untrusted inputs before rendering.

-- Search post content and postmeta for script tags or on* attributes
SELECT ID, post_title, post_date
FROM wp_posts
WHERE post_content LIKE '%

# 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 

# 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, "

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 );
}

$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 );

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

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.