Urgent Security Advisory: Add User Meta plugin (<= 1.0.1) — CSRF → Stored XSS (CVE-2025-7688)

Date: 15 August 2025
Author: Hong Kong Security Expert

Summary

• Vulnerability: Cross-Site Request Forgery (CSRF) enabling Stored Cross-Site Scripting (XSS)
• Affected software: Add User Meta WordPress plugin, versions ≤ 1.0.1
• CVE: CVE-2025-7688
• Privilege required: Unauthenticated (attacker may exploit from the web)
• Public fix: None available at time of disclosure
• Recommendation: Mitigate immediately — remove or disable the plugin, apply virtual patching via your WAF or server firewall, and follow the incident response checklist below.

This advisory describes the technical details, exploitation scenarios, detection and containment processes, code-level fixes for plugin authors, virtual patch rules you can deploy immediately, and longer-term hardening guidance.

What happened (short)

The Add User Meta plugin exposes an endpoint or action that allows adding or updating user metadata without proper CSRF protections and without validating or sanitizing input. There is no effective nonce/CSRF check and user-provided data is stored and output without safe escaping. An attacker can craft requests (or trick an authenticated user into submitting one) that persist script-based payloads into user meta fields. Those payloads later render in pages or admin views where the meta values are echoed, resulting in stored XSS.

Because the issue can be exploited by unauthenticated attackers, the risk is elevated: persistent payloads can affect administrators and site visitors alike.

Why this is serious

Stored XSS is among the most dangerous client-side vulnerabilities on platforms like WordPress:

• Persistent execution: malicious JavaScript is stored on the server and executes whenever the vulnerable page is viewed.
• Admin compromise: if an admin views a page or profile where unsafe meta is rendered, attackers can hijack sessions or perform privileged actions.
• Reputation and SEO damage: injected content can deliver spam, ads, or phishing, harming trust and search visibility.
• Automated exploitation: public disclosure commonly triggers automated scans and mass exploitation; act immediately.

This issue has an estimated CVSS-like assessment around 7.1 (medium/high). Given unauthenticated, persistent write capability, treat it as actionable.

Technical analysis

Root causes typically seen in this vulnerability class:

1. Missing CSRF protection (no nonce / no check_admin_referer / wp_verify_nonce).
2. Allowing unauthenticated or insufficiently authorized requests to write user meta.
3. Lack of input validation (accepting arbitrary HTML or script payloads).
4. Unsafe output (echoing meta values without esc_html(), esc_attr(), or wp_kses()).

Typical vulnerable flow:

• Plugin registers an endpoint (AJAX, REST, or form handler) that accepts user_id, meta_key, meta_value.
• The endpoint writes directly to wp_usermeta using add_user_meta() / update_user_meta() without verifying origin or sanitizing meta_value.
• Later, the plugin or other code outputs that meta value in HTML without escaping, allowing <script> tags or event handlers to execute.

Important exploitation notes:

• If the endpoint accepts POSTs from unauthenticated clients, attacker-hosted pages can send requests (CSRF) to store payloads.
• Even if cookies are required, CSRF can run in the context of a logged-in admin (social engineering). This report indicates unauthenticated exploitability in some configurations.
• Stored XSS payloads may trigger in admin interfaces (profile pages, user list), front-end author pages, or any location where the meta value is rendered.

Immediate actions — for site owners / operators

If you operate WordPress sites using Add User Meta (<=1.0.1), take these steps immediately:

1. Take a hot backup (files + database).
2. Disable or remove the plugin immediately if possible (Plugins page or delete plugin folder via SFTP). Removing the plugin prevents new malicious input.
3. If removal is not possible, block access to the plugin’s endpoints via your firewall (WAF, server firewall, .htaccess) — see the WAF rules section below for virtual patches.
4. Scan the database for suspicious values in wp_usermeta:

   SELECT user_id, meta_key, meta_value
   FROM wp_usermeta
   WHERE meta_value LIKE '%<script%'
      OR meta_value LIKE '%javascript:%'
      OR meta_value LIKE '%onerror=%'
      OR meta_value LIKE '%onload=%';

5. Review access logs for suspicious POST requests to plugin-specific URIs and odd User-Agent strings.
6. If you find injected script payloads, isolate affected entries:
   • Remove or sanitize entries (replace with safe values or null).
   • If admin accounts appear compromised (unexpected changes, new admins), rotate passwords and invalidate sessions.
7. Rotate credentials for high-privilege accounts and revoke exposed API keys.
8. Run a full malware scan and search for other indicators of compromise (webshells, modified files).
9. Notify stakeholders and, if needed, restore from a clean backup taken before the compromise.

If you are not confident performing these steps, contact your host or an experienced incident response provider.

Detection indicators (IoCs)

Look for:

• Usermeta entries containing <script>, javascript:, onerror=, onload=, document.cookie, :

  SELECT user_id, meta_key, meta_value
  FROM wp_usermeta
  WHERE lower(meta_value) REGEXP '<script|onerror|onload|javascript:|document.cookie|alert\\(';

  ---

  Virtual patch / WAF mitigations you can apply immediately

  While waiting for an official plugin fix, deploy virtual patching at the HTTP layer (WAF, ModSecurity, nginx rules) to reduce risk.

  Suggested rule categories:

  1. Block or inspect requests that attempt to write usermeta:
     • Block POSTs to known plugin endpoints or requests containing parameter names like meta_key, meta_value, add_usermeta, modify_user_meta.
  2. Block inputs containing script patterns:
     • If a POST body contains <script, javascript:, onerror=, onload=, document.cookie, or eval(, block or challenge.
  3. Enforce same-origin / CSRF protections:
     • Reject POSTs with missing or invalid Referer or Origin headers for endpoints that should be same-origin only.
  4. Rate-limit unauthenticated POSTs to endpoints that modify data.

  Example ModSecurity rule (conceptual — adapt and test):

  # Block attempts to inject 
  			
  				
  			
  					
  
  							
  			
  			
  			
  
  
  
  		
  
  		
  	        
          				
  				 
   
     
   
    
   
   Review My Order
   0 
   
    
   
   
   
   
   Subtotal
   
  Taxes & shipping calculated at checkout
   
    
   
   
     Checkout