Community Alert XSS in JSON Importer(CVE202515363)

Cross Site Scripting (XSS) in WordPress JSON Content Importer Plugin






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


Plugin Name WordPress JSON Content Importer Plugin
Type of Vulnerability Cross-Site Scripting (XSS)
CVE Number CVE-2025-15363
Urgency Medium
CVE Publish Date 2026-03-19
Source URL CVE-2025-15363

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.

Quick summary (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.

Key points: 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.

Realistic exploitation scenarios

  • 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. If you cannot update immediately:
    • 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 '%

Search for common JS payload patterns:

  • onerror=
  • onload=
  • javascript: