8.7

CVSS Score

4.0

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-35672

CVE-2026-35672: phpMyFAQ - Authentication Bypass via Empty API Token

phpMyFAQ before 4.1.3 contains an authentication bypass vulnerability in API v4.0 where the default empty api.apiClientToken allows unauthenticated users to create and modify FAQ entries. Attackers can send an empty x-pmf-token header to bypass token validation and inject malicious content via POST endpoints /api/v4.0/faq/create, /api/v4.0/category, and /api/v4.0/question.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-35672

CVE-2026-35672:

8.7

CVSS Score

4.0

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

SSVC / BOD 26-04 ↗

Exploitation pocAutomatable YesTech Impact Partial

Select your environment

→SSVCDeferfix on upgrade

Runtime reachability resolves your actual outcome.Book a demo

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
thorsten/phpmyfaq	composer	<= 4.1.2	4.1.3
phpmyfaq/phpmyfaq	composer	<= 4.1.2	4.1.3

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The root cause of the vulnerability is an authentication bypass in the phpMyFAQ\Controller\AbstractController::hasValidToken function. This function is responsible for validating the API token for several write-access API endpoints. The vulnerability is triggered because the application, by default, initializes the API token (api.apiClientToken) to an empty string during installation. The hasValidToken function used a strict inequality comparison (!==). When an attacker sends a request with an empty x-pmf-token header to a vulnerable endpoint, the check becomes '' !== '', which evaluates to false, thereby incorrectly validating the request and bypassing authentication. This allows an unauthenticated attacker to create and modify content such as FAQs, categories, and questions.

The patch addresses this in three key places:

AbstractController.php: The hasValidToken function is modified to first check if the configured token is empty and reject the request if so. It also replaces the weak comparison with the constant-time hash_equals function to prevent timing attacks.
Installer.php: The installation logic is changed in startInstall to generate a cryptographically secure random token, ensuring new installations are not vulnerable by default.
Update.php: A new update step, applyUpdates413, is added to check for and replace empty tokens in existing installations, remediating systems that are already deployed with the insecure default.

Vulnerable functions

phpMyFAQ\Controller\AbstractController::hasValidToken

src/phpMyFAQ/Controller/AbstractController.php

The vulnerability lies in the original implementation of the `hasValidToken` function. It used a strict inequality check (`!==`) to compare the configured API token with the one provided in the 'x-pmf-token' header. Due to a separate issue in the installation process (fixed in the same patch), the default API token is an empty string. An attacker can send a request with an empty 'x-pmf-token' header. The comparison `'' !== ''` evaluates to `false`, causing the authentication check to be bypassed entirely. The patch fixes this by first checking if the configured token is empty and, if not, using the constant-time `hash_equals` function for comparison.

phpMyFAQ\Setup\Installer::startInstall

src/phpMyFAQ/Setup/Installer.php

This function is part of the installation process. The vulnerability is introduced because, prior to the patch, this process would set the `api.apiClientToken` to an empty string by default. The patch changes this behavior to generate a secure, random 32-byte token during installation, thus ensuring that new installations are not vulnerable by default.

phpMyFAQ\Setup\Update::applyUpdates413

src/phpMyFAQ/Setup/Update.php

This new function was added to the update process to remediate existing installations. It checks if the `api.apiClientToken` is empty, and if it is, generates a new secure token. This ensures that when users update their phpMyFAQ instance, the insecure default configuration is automatically fixed.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.