JSON Content Importer < 2.0.10 — Contributor+ Stored XSS (CVE‑2025‑15363)

Published: 2026-03-19

As Hong Kong–based security professionals with hands‑on experience in WordPress incident response, this post provides a technical breakdown of CVE‑2025‑15363 (stored XSS) affecting JSON Content Importer plugin versions prior to 2.0.10. The aim is pragmatic: explain the mechanics, realistic impact, detection techniques, containment steps, and long‑term hardening measures to reduce risk while you apply the vendor patch.

Resumen rápido (tl;dr)

• A stored XSS exists in JSON Content Importer plugin prior to version 2.0.10.
• The vulnerability can be abused by accounts with Contributor privileges or higher.
• Successful exploitation requires interaction by a privileged user (e.g., viewing a crafted post in admin), so social engineering is commonly involved.
• CVSS (reported value) is 6.5 — medium‑high impact for sites with Contributor roles and active editor/admin review workflows.
• Update to 2.0.10 (or later) as the definitive fix. If you cannot update immediately, apply the temporary mitigations described below.

Why stored XSS matters in WordPress

Stored XSS is dangerous because malicious input is persisted on the site (posts, postmeta, plugin settings, comments, etc.) and executed later in the context of a victim’s browser. In WordPress, admin users are the highest‑value victims: if an attacker can execute script in an administrator’s session, site takeover is possible.

Common post‑exploit consequences:

• Admin session theft (cookie/session hijacking) leading to site takeover.
• Privilege escalation via JavaScript‑driven actions (creating new admin users, changing options via AJAX).
• Installation of persistent backdoors or web shells.
• Distribution of malware or credential‑harvesting forms to site visitors.
• Content injection, SEO spam, and long‑term reputation damage.

How this specific vulnerability works — high level

1. A user with Contributor (or higher) capability submits data to an endpoint or UI provided by the plugin — for example, an import field or an area where JSON content or markup is stored.
2. The plugin persists the data without adequately sanitizing or escaping it when later output inside an admin page (or other page visited by privileged users).
3. An Administrator or Editor opens the affected page in the dashboard (or preview), and the injected JavaScript executes in their browser.
4. The script performs privileged actions (using cookies, calling admin AJAX actions, creating users, exfiltrating tokens), enabling takeover or persistent compromise.

Puntos clave: exploitation requires a privileged user to view the stored payload; the initial attacker only needs contributor access. This is significant for sites that accept contributor submissions or allow content imports from external sources.

Escenarios de explotación realistas

• Volunteer contributors submit drafts on a news site. An attacker includes a crafted JSON payload that executes when an Editor reviews the draft.
• Compromised contractor account or malicious contractor supplies payload via the plugin’s import functionality.
• Sites ingesting remote JSON/RSS: an attacker modifies the source or injects payloads fed to the plugin.
• Social engineering: attacker asks an Editor to “please review my post,” increasing the chance of the payload being viewed.

Immediate action checklist — what to do now (0–72 hours)

1. Update the plugin to 2.0.10 (or later) immediately if you run JSON Content Importer. This is the only permanent fix.
2. Si no puede actualizar de inmediato:
   • Disable or uninstall the plugin until you can patch.
   • Restrict access to the plugin endpoints (see temporary WAF/htaccess examples below).
   • Temporarily remove Contributor capability to interact with the plugin or restrict Contributor role actions.
3. Scan for indicators of compromise (IOCs):
   • Search for script tags in posts, postmeta and other plugin tables.
   • Check files for newly added PHP files or recent modifications.
   • Look for created administrators or unexpected role changes.
4. Force password reset for all administrators and privileged accounts if you detect suspicious activity.
5. Ensure backups are available and take a fresh backup before remediation.

How to detect if you’ve been targeted / exploited

Stored XSS can be stealthy. Use automated scans plus manual database queries and log review.

Search for script tags in the database:

-- Posts containing script tags
SELECT ID, post_title, post_author, post_date
FROM wp_posts
WHERE post_content LIKE '%<script%';

-- Post meta that contains script tags
SELECT post_id, meta_key, meta_value
FROM wp_postmeta
WHERE meta_value LIKE '%<script%';

Search for common JS payload patterns:

• onerror=
• onload=
• javascript:
• <svg onload= or <img onerror=
• <iframe src=

Example WP‑CLI command:

# Search for "<script" in post content using WP-CLI
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"

Server log review:

• Look for suspicious POST requests to plugin endpoints such as admin-ajax.php, plugin import endpoints, or unusual REST calls mapping to plugin routes.
• Check for requests from unfamiliar IPs or spikes in contributor activity.

Browser console evidence: administrators reporting popups, unexpected redirects, or automatic downloads may indicate JS execution.

Comprobaciones del sistema de archivos:

# Find PHP files modified in last 14 days
find /var/www/html -type f -iname '*.php' -mtime -14 -ls

Cuentas de usuario:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user list --role=subscriber --role=contributor --fields=ID,user_login,user_email,user_registered

Respuesta a incidentes: si sospechas de un compromiso

1. Isolate the environment: put the site into maintenance mode or temporarily take it offline; isolate credentials and processes if hosting multiple sites on the same server.
2. Take a full backup (files + DB) immediately for forensics.
3. Identify the attack vector and affected records (use the detection queries above).
4. Limpiar el sitio:
   • Remove malicious entries from post_content/postmeta (manually or via clean backups).
   • Remove injected files and malicious scheduled tasks.
   • Reinstall core and plugin files from known clean sources.
5. Restablecer credenciales:
   • Force password reset for all admin users.
   • Rotate API keys, webhook secrets, and tokens stored on the site.
6. Verify integrity with malware scans and log inspection for persistence or beaconing.
7. Restaura desde una copia de seguridad limpia si es necesario.
8. Review and harden: update the plugin to 2.0.10+, re‑examine user roles and remove unnecessary contributor accounts, and deploy temporary request filtering where needed.

If you are unsure at any step, engage a qualified WordPress security professional; persistent backdoors can be subtle and difficult to detect.

Short‑term mitigations and virtual patching (WAF rules)

If you cannot patch immediately, virtual patching with a properly configured WAF can reduce exposure. The examples below are generic and must be adapted and tested for your environment.

1. Block common XSS payload patterns in requests targeting plugin endpoints:
   • Block if request contains “<script”, “onerror=”, “onload=”, “javascript:”, “svg/onload”, “img/onerror”.
2. Rate limit POST requests to plugin endpoints and admin AJAX.
3. Restrict REQUEST_URI patterns that match plugin import paths if those endpoints are unused.

Example ModSecurity style rule (adapt to your WAF platform):

# Example pattern-based WAF rule — adapt IDs & syntax to your WAF
SecRule REQUEST_URI "@pm /wp-admin/admin.php /wp-admin/admin-ajax.php /wp-json/" \
 "phase:2,t:none,chain,log,deny,msg:'Block potential stored XSS to plugin import endpoints',id:1000001"
  SecRule REQUEST_BODY|ARGS|ARGS_NAMES|XML:/* "@rx (<script\b|onerror\s*=|onload\s*=|javascript:|alert\(|<svg\b.*onload)" \
  "t:none,log,deny,status:403"

Important: pattern matching may produce false positives. Run in log mode initially to tune rules before enforcing deny.

Temporary .htaccess protection for plugin folder:

# Deny access to plugin admin endpoints unless from trusted IPs (example)
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/wp-content/plugins/json-content-importer/ [NC]
  # Allow trusted admin IP e.g. 203.0.113.5
  RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.5$
  RewriteRule ^.* - [F,L]
</IfModule>

Or deny public access to specific plugin PHP files unless strictly necessary.

Recomendaciones de endurecimiento (a largo plazo)

• Keep everything updated — WordPress core, themes, and plugins.
• Enforce least privilege: only grant Contributor or higher when required; consider manual approval for new contributors.
• Require two‑factor authentication for elevated roles.
• Reduce attack surface: uninstall or disable unused plugins, especially those that parse or import remote content.
• Sanitizar y escapar:
  • Perform server‑side sanitization on input that may be output to admin pages.
  • Ensure plugin output is escaped using esc_html, esc_attr, wp_kses_post where appropriate.
• Implement a Content Security Policy (CSP) where compatible to limit inline script execution.
• Prefer role‑scoped preview workflows that avoid exposing raw HTML from contributors to admins.
• Log and monitor admin activity, file changes, and set up integrity checking (file hashes) and scheduled malware scans.
• Harden file permissions and disable file editing by defining DISALLOW_FILE_EDIT in wp-config.php.
• Choose plugins with active maintenance and a good security track record.

Developer checklist — what to fix in plugin code

If you are auditing or maintaining code:

• Validate and sanitize all user‑controlled input before persisting to the database. Use wp_kses() / wp_kses_post() with a strict allowed set when HTML is expected.
• Escape output when rendering in admin pages: esc_html(), esc_attr(), wp_kses_post(). Never echo unescaped HTML coming from untrusted users into admin pages.
• Use nonce and capability checks on endpoints that accept input.
• Avoid rendering raw JSON or unchecked data inside inline script blocks. If serializing data into JS, use wp_json_encode() and appropriate escaping.
• Do not trust user roles alone — add contextual validation where appropriate.

Useful detection & cleanup scripts

Practical queries and commands you can run immediately.

-- Search for "onerror=" and "onload=" in post content
SELECT ID, post_title, post_modified
FROM wp_posts
WHERE post_content LIKE '%onerror=%' OR post_content LIKE '%onload=%' OR post_content LIKE '%javascript:%';

-- Search for "<script" occurrences in postmeta
SELECT post_id, meta_key
FROM wp_postmeta
WHERE meta_value LIKE '%<script%';

WP‑CLI example (use with caution and backups):

# Replace dangerous script tags with sanitized entity (backup first)
wp db query "UPDATE wp_posts SET post_content = REPLACE(post_content, '

<?php
// Put in an mu-plugin to sanitize post content when saved by contributors
add_action('save_post', 'hk_sanitize_contributor_content', 10, 3);
function hk_sanitize_contributor_content($post_ID, $post, $update) {
  if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) return;
  $user = wp_get_current_user();
  if (in_array('contributor', (array)$user->roles)) {
    $clean = wp_kses($post->post_content, wp_kses_allowed_html('post'));
    if ($clean !== $post->post_content) {
      // Prevent infinite loop: remove action, update, re-add
      remove_action('save_post', 'hk_sanitize_contributor_content', 10);
      wp_update_post(array('ID' => $post_ID, 'post_content' => $clean));
      add_action('save_post', 'hk_sanitize_contributor_content', 10, 3);
    }
  }
}
?>