CVE-2026-4336: WordPress Ultimate FAQ Accordion XSS Flaw

CVE-2026-4336 Overview

The Ultimate FAQ Accordion plugin for WordPress contains a Stored Cross-Site Scripting (XSS) vulnerability in all versions up to and including 2.4.7. The flaw exists in the FAQ content rendering mechanism where html_entity_decode() is called on post_content during the set_display_variables() function in View.FAQ.class.php at line 746. This converts HTML entity-encoded payloads back into executable HTML. Combined with insufficient output escaping in the faq-answer.php template—where decoded content is echoed without wp_kses_post() or any other sanitization—authenticated attackers with Author-level access or above can inject arbitrary web scripts that execute whenever a user accesses an injected FAQ page.

Critical Impact

Authenticated attackers with Author privileges can inject persistent malicious JavaScript into FAQ content, enabling session hijacking, credential theft, or redirection to malicious sites for any user viewing the FAQ pages.

Affected Products

• Ultimate FAQ Accordion for WordPress versions up to and including 2.4.7
• WordPress sites using the [ultimate-faqs] shortcode
• Any page or post displaying FAQ content via the plugin

Discovery Timeline

• April 9, 2026 - CVE-2026-4336 published to NVD
• April 9, 2026 - Last updated in NVD database

Technical Details for CVE-2026-4336

Vulnerability Analysis

This Stored XSS vulnerability exploits a fundamental flaw in how the Ultimate FAQ Accordion plugin processes and renders FAQ content. The issue stems from the interaction between WordPress's kses sanitization at save time and the plugin's content decoding at render time.

When content is saved to the database, WordPress's kses filter sees HTML entities (like < and >) as plain text rather than HTML tags, allowing entity-encoded payloads to pass through sanitization unchanged. However, when the FAQ content is rendered, the plugin calls html_entity_decode() which converts these entities back into actual HTML markup. Since the faq-answer.php template outputs this decoded content without additional sanitization via wp_kses_post() or esc_html(), malicious scripts execute in the browser context.

The vulnerability is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation), specifically a Stored XSS variant where malicious payloads persist in the database and affect multiple users.

Root Cause

The root cause is a classic sanitize-early, decode-late antipattern combined with missing output escaping. The plugin's ufaq custom post type is registered with 'show_in_rest' => true and defaults to 'post' capability_type, allowing Author-level users to create and publish FAQs via the REST API. At line 746 in View.FAQ.class.php, the call to html_entity_decode() transforms entity-encoded content into raw HTML. The faq-answer.php template then echoes this content directly at line 2 without applying wp_kses_post(), esc_html(), or any other WordPress escaping functions, creating the XSS vector.

Attack Vector

The attack is performed over the network by authenticated users with Author-level privileges or higher. An attacker can craft a malicious FAQ entry containing entity-encoded JavaScript payloads (e.g., <img src=x onerror=alert()>). Because the kses filter at save time treats these entities as harmless text, the payload is stored successfully. When any user—including administrators—views the FAQ page directly or via the [ultimate-faqs] shortcode, the html_entity_decode() function converts the entities back to HTML tags, and the unescaped output in faq-answer.php allows the browser to execute the malicious script.

The vulnerability requires low privilege (Author role) and no user interaction beyond viewing the page. The scope is changed since the XSS payload can affect users in different security contexts than the attacker.

Detection Methods for CVE-2026-4336

Indicators of Compromise

• Presence of HTML entity-encoded script tags (<script>, &lt;script&gt;) in FAQ post content within the wp_posts table
• Unusual JavaScript event handlers in FAQ content (e.g., onerror=, onload=, onclick=) in entity-encoded form
• Reports of unexpected JavaScript execution or browser alerts when viewing FAQ pages
• Web server logs showing Author-level users creating or modifying FAQ posts via REST API endpoints (/wp-json/wp/v2/ufaq)

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect entity-encoded XSS patterns in POST requests to WordPress REST API endpoints
• Monitor database queries for FAQ content containing suspicious encoded HTML entities or JavaScript keywords
• Deploy Content Security Policy (CSP) headers to detect and block inline script execution, generating violation reports for analysis
• Audit WordPress user activity logs for unusual FAQ creation or modification patterns by Author-level accounts

Monitoring Recommendations

• Enable and review WordPress audit logging for all custom post type modifications, specifically the ufaq post type
• Configure browser CSP violation reporting endpoints to capture attempted XSS execution
• Implement real-time alerting for database content matching XSS payload signatures in FAQ tables
• Monitor network traffic for unusual outbound requests from FAQ pages that may indicate successful XSS exfiltration

How to Mitigate CVE-2026-4336

Immediate Actions Required

• Update the Ultimate FAQ Accordion plugin to a patched version beyond 2.4.7 immediately
• Review all existing FAQ content for suspicious HTML entities or encoded JavaScript payloads
• Restrict FAQ creation and editing permissions to trusted Administrator accounts only until patched
• Implement Content Security Policy headers with script-src 'self' to prevent inline script execution as defense in depth

Patch Information

A patch is available via the WordPress Ultimate FAQs Changeset. The fix ensures proper output escaping using wp_kses_post() or equivalent sanitization functions in the faq-answer.php template. Site administrators should update to the latest version available in the WordPress plugin repository. Additional technical details can be found in the Wordfence Vulnerability Report.

Workarounds

• Modify the faq-answer.php template manually to wrap FAQ content output with wp_kses_post() or esc_html() as an interim measure
• Revoke Author and Contributor publishing capabilities for the ufaq custom post type by adjusting capability mappings in a custom plugin or functions.php
• Disable REST API access for the ufaq post type by filtering register_post_type_args to set show_in_rest to false
• Implement server-side input validation to strip or reject entity-encoded HTML tags in FAQ content before database insertion

# Example: Restrict FAQ post type capabilities via wp-cli
# Review current Author capabilities
wp cap list 'author' --allow-root

# Remove publish capability for ufaq post type (requires custom code)
# Add to theme functions.php or custom plugin:
# add_filter('register_post_type_args', function($args, $post_type) {
#     if ($post_type === 'ufaq') {
#         $args['capability_type'] = 'page';
#         $args['map_meta_cap'] = true;
#     }
#     return $args;
# }, 10, 2);