CVE-2026-2121: WordPress Weaver Show Posts XSS Vulnerability

CVE-2026-2121 Overview

The Weaver Show Posts plugin for WordPress contains a Stored Cross-Site Scripting (XSS) vulnerability in the add_class parameter affecting all versions up to and including 1.8.1. The vulnerability stems from insufficient input sanitization and output escaping on user-supplied attributes, allowing authenticated attackers with Administrator-level access to inject arbitrary web scripts into pages. These malicious scripts execute whenever a user accesses an injected page.

This vulnerability primarily impacts WordPress multisite installations where Administrators do not have the unfiltered_html capability, as this is the primary security control that would otherwise prevent such script injection.

Critical Impact

Authenticated attackers with Administrator privileges can inject persistent malicious scripts that execute in the browsers of all users viewing affected pages, potentially leading to session hijacking, credential theft, or further site compromise.

Affected Products

• Weaver Show Posts plugin for WordPress versions up to and including 1.8.1
• WordPress multisite installations without unfiltered_html capability for Administrators

Discovery Timeline

• 2026-03-21 - CVE-2026-2121 published to NVD
• 2026-03-23 - Last updated in NVD database

Technical Details for CVE-2026-2121

Vulnerability Analysis

This Stored Cross-Site Scripting vulnerability exists within the Weaver Show Posts plugin's widget functionality, specifically in the posts-widgets.php file. The vulnerability is classified under CWE-79 (Improper Neutralization of Input During Web Page Generation).

The core issue lies in how the plugin handles the add_class parameter without proper sanitization before storing it in the database or escaping it when rendering output. When an authenticated Administrator configures a widget or shortcode with a malicious add_class value, the unsanitized input is stored persistently and later rendered without proper escaping, causing the injected script to execute in the context of any user's browser session viewing the affected page.

While this vulnerability requires Administrator-level authentication, it becomes particularly relevant in WordPress multisite environments. In these configurations, site Administrators may not possess the unfiltered_html capability—a deliberate security restriction imposed by Super Admins. This vulnerability bypasses that intended security boundary, allowing compromised or malicious Administrators to inject scripts they would otherwise be prevented from adding.

Root Cause

The root cause is insufficient input validation and output escaping in the widget parameter handling code within posts-widgets.php. Specifically, the add_class parameter accepts user input that is directly incorporated into HTML output without being passed through WordPress sanitization functions such as esc_attr() or wp_kses(). This allows HTML entities and JavaScript event handlers to be injected and stored in the database.

Attack Vector

The attack is network-based and requires the attacker to have Administrator-level authentication to the WordPress site. The attacker accesses the widget configuration interface or uses a shortcode with the vulnerable add_class parameter. By injecting a payload such as an event handler attribute containing JavaScript, the attacker can store malicious content that executes when any user—including Super Admins—views a page containing the compromised widget.

The vulnerability affects pages rendered for all site visitors, making it a stored/persistent XSS issue with the potential to impact a wide audience despite the high privilege requirement for exploitation.

Detection Methods for CVE-2026-2121

Indicators of Compromise

• Unusual JavaScript code or event handlers (such as onerror, onload, onmouseover) appearing in widget configurations or shortcode attributes
• Unexpected script tags or encoded JavaScript within the add_class parameter values in the WordPress database
• Browser developer console showing execution of unfamiliar scripts on pages using Show Posts widgets
• Reports from users experiencing unexpected redirects, pop-ups, or credential prompts on affected pages

Detection Strategies

• Review the wp_options table for widget configurations containing suspicious script patterns or HTML event handlers
• Implement Web Application Firewall (WAF) rules to detect XSS payloads in POST requests to widget save endpoints
• Use WordPress security plugins to scan for known XSS patterns in stored content
• Monitor administrator activity logs for unusual widget configuration changes

Monitoring Recommendations

• Enable comprehensive logging of all WordPress admin actions, particularly widget and shortcode modifications
• Configure Content Security Policy (CSP) headers to detect and report inline script execution violations
• Regularly audit plugin configurations across all sites in multisite installations
• Set up alerts for database modifications to widget-related options

How to Mitigate CVE-2026-2121

Immediate Actions Required

• Update the Weaver Show Posts plugin to the latest version that addresses this vulnerability
• Review all existing widget configurations for potentially malicious add_class parameter values
• Temporarily disable the Weaver Show Posts plugin if an update is not yet available
• Audit Administrator accounts for unauthorized access or suspicious activity

Patch Information

Organizations should check the WordPress Plugin Repository for updated versions of the Weaver Show Posts plugin that include proper input sanitization and output escaping for the add_class parameter. For detailed vulnerability information, refer to the Wordfence Vulnerability Report.

Workarounds

• Remove or restrict Administrator access in multisite environments to only trusted users pending a patch
• Implement server-side input validation using a Web Application Firewall to block XSS payloads
• Enable Content Security Policy headers to mitigate the impact of any successfully injected scripts
• Consider temporarily replacing the plugin with an alternative that has been audited for XSS vulnerabilities

# WordPress wp-config.php CSP Header Configuration
# Add to your theme's functions.php or use a security plugin

# Example: Add Content Security Policy header to mitigate XSS impact
add_action('send_headers', function() {
    header("Content-Security-Policy: script-src 'self' 'unsafe-inline' https://trusted-cdn.com;");
});