CVE-2026-0693: WordPress Allow HTML Plugin XSS Vulnerability

CVE-2026-0693 Overview

The Allow HTML in Category Descriptions plugin for WordPress contains a Stored Cross-Site Scripting (XSS) vulnerability affecting all versions up to and including 1.2.4. The vulnerability stems from the plugin unconditionally removing the wp_kses_data output filter for term_description, link_description, link_notes, and user_description fields without properly verifying user capabilities. This design flaw allows authenticated attackers with administrator-level access to inject arbitrary web scripts into category descriptions that execute whenever users access pages displaying the affected category descriptions.

Critical Impact

Authenticated attackers with administrative privileges can inject persistent malicious scripts that execute in the browsers of all users viewing affected category pages, potentially leading to session hijacking, credential theft, and privilege escalation on WordPress multi-site installations.

Affected Products

• Allow HTML in Category Descriptions plugin for WordPress versions up to and including 1.2.4
• WordPress multi-site installations with the vulnerable plugin
• WordPress installations where unfiltered_html capability has been disabled

Discovery Timeline

• 2026-02-14 - CVE CVE-2026-0693 published to NVD
• 2026-02-18 - Last updated in NVD database

Technical Details for CVE-2026-0693

Vulnerability Analysis

This Stored XSS vulnerability (CWE-79) arises from improper output encoding in the Allow HTML in Category Descriptions WordPress plugin. The plugin's core functionality intentionally removes WordPress's built-in sanitization filters to allow HTML content in category descriptions, but it does so without implementing proper capability checks or alternative sanitization mechanisms.

The vulnerability specifically affects WordPress environments where the unfiltered_html capability has been disabled or in multi-site configurations where super-admin controls are in place. In these scenarios, even administrator accounts should not be able to inject arbitrary scripts, but the plugin bypasses these security controls entirely.

When an attacker with administrator-level access crafts a malicious category description containing JavaScript code, the script persists in the database and executes in the context of any user's browser session when they view pages that display the category description. This can lead to session token theft, administrative account compromise, and further propagation of attacks across the WordPress installation.

Root Cause

The root cause lies in the plugin's implementation at line 23 of html-in-category-descriptions.php, where the wp_kses_data filter is unconditionally removed from multiple description fields (term_description, link_description, link_notes, and user_description). WordPress uses wp_kses_data as a security filter to strip potentially dangerous HTML tags and attributes from user-submitted content. By removing this filter without implementing alternative security controls or capability checks, the plugin creates an avenue for persistent script injection regardless of the user's actual permissions to post unfiltered HTML.

Attack Vector

The attack requires network access and authenticated administrator-level credentials to the WordPress installation. An attacker would navigate to the category management interface and create or edit a category description to include malicious JavaScript payload. Once saved, the malicious script is stored in the WordPress database and executed whenever the category description is rendered on the frontend or backend of the site.

The attack is particularly impactful in multi-site WordPress installations where super-admins typically maintain control over script injection capabilities, or in security-hardened WordPress environments where the unfiltered_html capability has been deliberately disabled for all user roles.

Detection Methods for CVE-2026-0693

Indicators of Compromise

• Unexpected JavaScript or HTML tags within category, link, or user description fields in the WordPress database
• Browser console errors or unexpected network requests when viewing category archive pages
• User reports of unusual browser behavior or unexpected redirects when accessing category pages
• Audit log entries showing modifications to category descriptions by administrator accounts

Detection Strategies

• Implement Content Security Policy (CSP) headers to detect and block inline script execution attempts
• Deploy web application firewalls (WAF) with XSS signature detection rules for WordPress environments
• Monitor database tables (wp_terms, wp_term_taxonomy) for suspicious HTML or JavaScript content patterns
• Use WordPress security plugins to scan for known vulnerable plugin versions

Monitoring Recommendations

• Enable and review WordPress audit logs for category description modifications
• Configure real-time alerting for any changes to term metadata in the WordPress database
• Implement browser-based XSS detection through CSP violation reporting endpoints
• Schedule regular automated scans of WordPress installations for vulnerable plugin versions

How to Mitigate CVE-2026-0693

Immediate Actions Required

• Audit existing category descriptions for any malicious script content and sanitize affected entries
• Consider temporarily deactivating the Allow HTML in Category Descriptions plugin until a patched version is available
• Implement Content Security Policy headers to mitigate the impact of any existing XSS payloads
• Review administrator account access and remove unnecessary privileges

Patch Information

Organizations should monitor the WordPress Plugin repository for updated versions of the Allow HTML in Category Descriptions plugin that address this vulnerability. The Wordfence vulnerability report provides additional tracking information for patch availability.

Workarounds

• Deactivate the Allow HTML in Category Descriptions plugin and use alternative methods to format category descriptions
• Implement a Web Application Firewall (WAF) with strict XSS filtering rules for WordPress admin interfaces
• Restrict administrator account access to trusted users only and enforce strong authentication mechanisms
• Deploy Content Security Policy headers with strict script-src directives to prevent inline script execution

# Add CSP headers to WordPress .htaccess for Apache
Header set Content-Security-Policy "script-src 'self'; object-src 'none';"

# For Nginx, add to server block
add_header Content-Security-Policy "script-src 'self'; object-src 'none';";