CVE-2026-35672

Technical summary

CVE-2026-35672 is an authentication bypass in phpMyFAQ's API v4.0 layer affecting versions prior to 4.1.3. The vulnerability stems from improper token validation where an empty api.apiClientToken is treated as valid. Attackers bypass the x-pmf-token header check by sending an empty value, gaining write access to sensitive endpoints: /api/v4.0/faq/create, /api/v4.0/category, and /api/v4.0/question. The flaw is classified under CWE-1188 (Initialization with Hard-Coded Network Resource Configuration Data), reflecting the reliance on a default, non-restrictive token state. The CVSS 3.1 score of 7.5 (HIGH) reflects high integrity impact with network-accessible attack surface, no privilege escalation required, and no user interaction needed.

Business impact

Compromise of FAQ content represents a reputational and operational risk. Attackers can inject false information into customer-facing documentation, degrade user trust, or embed malicious links that redirect users to phishing or malware distribution sites. For organizations using phpMyFAQ as a customer support or internal knowledge hub, unauthorized modification can cause support team inefficiency, customer confusion, and potential compliance violations if FAQ data contains regulated content (PII, security guidance, compliance statements). The attack requires no sophistication and leaves audit trails vulnerable if logging is not independently secured.

Affected systems

phpMyFAQ prior to version 4.1.3 is affected. Organizations running any prior release should assume exposure if their phpMyFAQ instance is accessible via network (internet-facing or internal network with API exposure). Assess your deployment: check the installed version via the phpMyFAQ admin panel or source inspection. This impacts both on-premises installations and any managed hosting scenarios where the FAQ system is internet-reachable.

Exploitability

Exploitability is trivial. No authentication, no special tools, no user interaction, and no complex configuration required. An attacker needs only HTTP client capabilities to craft POST requests to the affected endpoints with an empty x-pmf-token header. The attack surface is large: any network path to the API is sufficient. No CISA KEV listing exists at this time, but the low barrier to exploitation and high availability of phpMyFAQ installations mean practical exploitation risk is substantial. Automated scanning for vulnerable instances is feasible.

Remediation

Upgrade phpMyFAQ to version 4.1.3 or later immediately. This patch rectifies token validation logic to reject empty tokens and enforce proper API authentication. If immediate upgrade is not feasible, apply compensating controls: restrict API endpoint access at the network layer (firewall, reverse proxy, WAF rules) to trusted IP ranges; implement rate limiting on API endpoints; enable and monitor API access logs for anomalous POST activity to /api/v4.0/faq/create, /api/v4.0/category, and /api/v4.0/question; and regenerate any default API tokens and rotate credentials.

Patch guidance

Verify your current phpMyFAQ version in the admin settings or via the source tree. Download version 4.1.3 or later from the official phpMyFAQ repository and follow the vendor's upgrade guide. Test the patch in a non-production environment first to confirm compatibility with existing FAQ data and any customizations. After upgrade, confirm API token validation is functioning by attempting an unauthenticated request to the affected endpoints—it should be rejected. Consult the official phpMyFAQ release notes for version 4.1.3 to confirm the specific changes addressing this vulnerability.

Detection guidance

Monitor API access logs for POST requests to /api/v4.0/faq/create, /api/v4.0/category, or /api/v4.0/question with empty or missing x-pmf-token headers. Search for successful (HTTP 200–201) responses to these endpoints without valid authentication context. Implement WAF rules to flag or block POST requests to these endpoints lacking a non-empty x-pmf-token header. Review FAQ creation/modification audit logs for entries created outside normal business hours or by unrecognized users. If running a vulnerable version, treat any FAQ changes created after the vulnerability publication date (2026-05-28) as potentially malicious until verified.

Why prioritize this

Despite not yet appearing on CISA's KEV catalog, this vulnerability merits immediate prioritization due to: (1) zero authentication required, (2) network-accessible attack surface, (3) trivial exploitation complexity, (4) integrity-focused impact (content tampering), and (5) likely widespread deployment of phpMyFAQ in customer support environments. Organizations should treat this as a high-priority patch candidate similar to KEV-listed items. Delay increases the window for opportunistic exploitation or mass scanning.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects a HIGH severity: Network-accessible (AV:N), no special conditions required (AC:L), no privilege or authentication needed (PR:N/UI:N), and significant integrity impact (I:H) with no confidentiality or availability impact. The score appropriately captures the real-world risk of widespread content injection across a customer-facing or internal knowledge base without requiring attacker sophistication.

Frequently asked questions