CVE-2026-9626: Stored XSS in JSON API User WordPress Plugin ≤4.1.0

Technical summary

The vulnerability stems from insufficient input sanitization in the post_comment() function of the JSON API User plugin. The function accepts the 'content' parameter from API requests and passes it directly to wp_insert_comment() without applying HTML sanitization. Additionally, the implementation allows authenticated callers to set comment_approved=1, which auto-approves comments and circumvents the WordPress moderation queue. This combination allows stored XSS payloads to persist in the comment database and execute in the context of any user's browser that views the compromised page.

Business impact

Stored XSS in a widely-used plugin can enable attackers to compromise visitor sessions, steal authentication tokens, deface content, or redirect users to malicious sites. Since subscriber-level access is the minimum requirement, compromised user accounts or social engineering of contributors becomes an attack vector. Organizations relying on this plugin for community engagement or membership features face reputational damage and potential loss of visitor trust if their sites are used to distribute malware or phishing payloads.

Affected systems

The JSON API User plugin for WordPress in versions up to and including 4.1.0 is affected. Any WordPress installation using this plugin with the REST API endpoint accessible is in scope. The vulnerability requires the attacker to have at least subscriber-level credentials, so sites with open user registration, guest contributions, or compromised user accounts are at elevated risk.

Exploitability

Exploitation requires authentication with subscriber-level privileges or higher, which limits the attack surface compared to unauthenticated XSS. However, this is a low bar in many WordPress environments—subscriber accounts are often freely registered or created by site administrators for legitimate users. Once an attacker gains such access, injecting a payload is straightforward: a single crafted API request to the post_comment endpoint. The self-approval mechanism ensures the payload persists without moderation, making detection and removal more difficult.

Remediation

Update the JSON API User plugin to a patched version that sanitizes the 'content' parameter before passing it to wp_insert_comment() and removes the ability to bypass comment moderation via API. Verify the availability of a patched release by consulting the plugin's official repository or vendor advisory. In the interim, disable the post_comment API endpoint if not in active use, restrict access to the REST API to trusted IP ranges, or lower the minimum user role required to approve comments to reduce attacker capability.

Patch guidance

Check the JSON API User plugin's update status in your WordPress admin dashboard or on the official WordPress plugin repository. Install any available security update immediately. After patching, audit existing comments created after the vulnerability was introduced to identify and remove any malicious payloads. Test the patched version in a staging environment before deploying to production to ensure compatibility with your theme and other plugins. Verify against the vendor advisory that your installed version number matches the patched version number provided by the plugin maintainer.

Detection guidance

Monitor API access logs for POST requests to the /wp-json/json-api-user/post_comment endpoint from low-privilege accounts. Look for suspicious patterns in comment_content parameters, such as script tags, event handlers (onclick, onerror, onload), or encoded payloads. Review comments created without moderation flags or with comment_approved=1 set directly via API. In WordPress, inspect the wp_comments table for entries with post_type='comment' and meta values indicating API-sourced creation. Consider implementing Web Application Firewall (WAF) rules to block requests containing common XSS payloads before they reach the WordPress application.

Why prioritize this

Although the CVSS score of 6.4 (Medium) reflects the authentication requirement, the ease of exploitation, high prevalence of the plugin, and persistence of the payload warrant prioritization. Stored XSS on a public-facing site creates continuous risk to all visitors, not just the attacker. The low barrier to entry (subscriber access) and potential for large-scale compromise through a single injected comment make this a strong candidate for rapid patching, especially for sites with significant user bases or sensitive content.

Risk score, explained

The CVSS 3.1 score of 6.4 reflects: Network-based attack vector (AV:N), low attack complexity (AC:L), low privilege requirement (PR:L), no user interaction required (UI:N), and changed scope (S:C) affecting resources beyond the vulnerable component. Confidentiality and integrity impacts (C:L/I:L) are assigned because XSS can exfiltrate session data and modify page content. No availability impact (A:N) is assessed because the attack does not disrupt service. The Medium severity appropriately balances the persistence and cross-user impact of stored XSS against the authentication gate that limits initial access.

Frequently asked questions