CVE-2026-1804: WordPress WDES Responsive Popup XSS Flaw

CVE-2026-1804 Overview

The WDES Responsive Popup plugin for WordPress contains a Stored Cross-Site Scripting (XSS) vulnerability in the wdes-popup-title shortcode. This security flaw exists in all versions up to and including 1.3.6 due to insufficient input sanitization and output escaping on user-supplied attributes. Authenticated attackers with contributor-level access or higher can exploit this vulnerability to inject arbitrary web scripts into pages, which execute whenever a user accesses the compromised page.

Critical Impact

Authenticated attackers with contributor-level access 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 compromise of the WordPress site.

Affected Products

• WDES Responsive Popup plugin for WordPress versions up to and including 1.3.6
• WordPress installations using vulnerable versions of the WDES Responsive Popup plugin

Discovery Timeline

• February 11, 2026 - CVE-2026-1804 published to NVD
• February 11, 2026 - Last updated in NVD database

Technical Details for CVE-2026-1804

Vulnerability Analysis

This Stored Cross-Site Scripting vulnerability resides in the shortcode processing functionality of the WDES Responsive Popup plugin. The vulnerability occurs because user-supplied attributes passed to the wdes-popup-title shortcode are not properly sanitized before being stored in the database, nor are they adequately escaped when rendered in the HTML output.

When a contributor or higher-privileged user creates or edits a post containing the vulnerable shortcode with malicious JavaScript payload, the script is stored persistently in the WordPress database. Subsequently, when any visitor—including administrators—views the page containing the injected content, the malicious script executes within their browser context.

The vulnerability has been identified in the plugin's source code, specifically in lib/view/title.php at line 77 and wdes-popup.php at line 111, where attribute handling occurs without adequate security controls.

Root Cause

The root cause of this vulnerability is the failure to implement proper input validation, sanitization, and output escaping for user-controlled shortcode attributes. WordPress provides several built-in functions for sanitizing and escaping data (such as sanitize_text_field(), esc_html(), esc_attr(), and wp_kses()), but the vulnerable code paths do not adequately employ these security measures, allowing malicious content to pass through unfiltered.

Attack Vector

The attack requires network access and authentication with at least contributor-level privileges on the target WordPress installation. The attacker crafts a malicious shortcode with XSS payload in the attributes and embeds it within a post or page. Once the content is saved and published (or in preview/draft state depending on permissions), the malicious script persists in the database. Any user who subsequently views the affected page will trigger script execution in their browser context.

The attack does not require user interaction beyond normal page viewing, and the scope is changed (affecting resources beyond the vulnerable component's security context) since the injected scripts can access session tokens, cookies, and perform actions on behalf of the victim user across the WordPress site.

Detection Methods for CVE-2026-1804

Indicators of Compromise

• Unexpected JavaScript or HTML content within posts or pages using the wdes-popup-title shortcode
• Database entries in wp_posts table containing suspicious script tags or encoded JavaScript payloads associated with popup content
• User reports of browser security warnings or unexpected behavior when viewing specific pages

Detection Strategies

• Review WordPress posts and pages for suspicious shortcode usage patterns, particularly examining attributes of wdes-popup-title shortcodes for script injection attempts
• Implement Web Application Firewall (WAF) rules to detect and block XSS patterns in shortcode attributes during post creation and editing
• Enable and monitor WordPress audit logging to track content modifications by contributor-level users
• Deploy content security policy (CSP) headers to detect and report inline script execution attempts

Monitoring Recommendations

• Configure real-time alerting for database modifications to posts containing the affected shortcode
• Monitor server access logs for patterns indicating reconnaissance or exploitation attempts
• Implement browser-side Content Security Policy reporting to identify script injection attempts
• Review contributor-level user activity for anomalous content creation patterns

How to Mitigate CVE-2026-1804

Immediate Actions Required

• Update the WDES Responsive Popup plugin to a patched version as soon as one becomes available
• Audit all existing posts and pages using the wdes-popup-title shortcode for malicious content
• Consider temporarily disabling the WDES Responsive Popup plugin until a patch is available
• Review and restrict contributor-level access privileges where possible
• Implement Content Security Policy headers to mitigate the impact of potential XSS exploitation

Patch Information

Organizations should monitor the Wordfence Vulnerability Report for updates on patch availability. The vulnerable code has been identified in the title.php source file and wdes-popup.php. Users should update to a version higher than 1.3.6 when available.

Workarounds

• Temporarily deactivate the WDES Responsive Popup plugin if popup functionality is not critical
• Restrict contributor and author role capabilities using a role management plugin to prevent shortcode usage
• Implement server-side input filtering through a WAF to block malicious shortcode attributes
• Deploy strict Content Security Policy headers to prevent inline script execution

# Add Content Security Policy header in .htaccess as a mitigation measure
# This helps prevent inline script execution from XSS attacks
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';"

# Or in nginx configuration
# add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';";