CVE-2026-76209 in phpMyFAQ
Summary
by MITRE • 08/19/2026
phpMyFAQ versions before v4.1.6 fail to validate the security.enableRegistration setting in API endpoints, allowing attackers to create user accounts when registration is disabled. Attackers can bypass the registration restriction by submitting requests to POST /api/register or POST /api/v3.1/register endpoints, which do not check the configuration flag enforced by the HTML registration page.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in phpMyFAQ versions prior to v4.1.6 represents a critical access control failure rooted in inconsistent security policy enforcement between different interface layers of the application. Specifically, the system fails to validate the enableRegistration setting within its API endpoints, creating a significant discrepancy where administrative configurations intended to restrict user self-registration are effectively ignored by programmatic interfaces. This flaw allows attackers who have network connectivity to the affected server to bypass registration restrictions and create new user accounts even when such functionality has been explicitly disabled via configuration settings. The core technical issue lies in the architectural design of the API handlers, which do not reference or check the global security flag that governs account creation permissions on the web interface.
From a technical perspective, this vulnerability is classified as an improper access control flaw where the application logic for handling registration requests diverges from the configured security policy. The HTML-based registration page correctly checks the enableRegistration configuration variable before processing new user data, thereby enforcing the administrator's intent to prevent unauthorized account creation. However, the API endpoints POST /api/register and POST /api/v3.1/register operate independently of this check. These endpoints accept HTTP POST requests containing user credentials without verifying whether the system-wide registration feature is active or disabled. This lack of centralized validation means that any actor with knowledge of these endpoint URLs can successfully register new accounts, effectively circumventing a security control designed to limit access and maintain an auditable list of authorized users.
The operational impact of this vulnerability extends beyond simple account proliferation. In many deployments, phpMyFAQ is used in environments where user registration is disabled for security reasons, such as when authentication is handled by external identity providers or when the knowledge base is intended for internal use only with pre-provisioned accounts. By allowing unauthorized account creation, an attacker can gain a foothold within the application's permission system. Depending on the default roles assigned to newly registered users and the specific configuration of the phpMyFAQ instance, these low-privilege accounts may be leveraged as stepping stones for further attacks. Attackers could potentially exploit other vulnerabilities associated with user-level permissions, such as editing articles they should not have access to, or using their authenticated session tokens to perform actions that require login status. In worst-case scenarios where default privileges are overly permissive, this could lead to privilege escalation or data integrity issues within the knowledge base.
This vulnerability aligns closely with CWE-284, which describes Improper Access Control, specifically highlighting failures in enforcing security policies across different components of an application. It also relates to CWE-601, URL Redirection to Untrusted Site, if the registration process involves redirects that could be manipulated, though the primary issue is access control bypass. In terms of offensive cybersecurity frameworks, this behavior corresponds to MITRE ATT&CK technique T1136, which covers Account Creation. Attackers utilize this tactic to establish persistence or expand their foothold within a compromised environment by creating legitimate-looking accounts that blend in with normal user activity. The fact that the API endpoints are exposed and functional without proper checks makes them an attractive target for automated scanning tools and malicious actors seeking low-effort entry points into web applications.
Mitigation strategies must focus on ensuring consistent security policy enforcement across all interfaces of the application. Administrators should immediately upgrade to phpMyFAQ version 4.1.6 or later, where this validation logic has been corrected to check the enableRegistration setting for both HTML and API endpoints. Until an upgrade is feasible, organizations can implement network-level controls such as firewall rules or Web Application Firewall (WAF) policies to block access to the vulnerable POST /api/register and POST /api/v3.1/register endpoints if they are not required for legitimate business operations. Additionally, reviewing user roles and permissions within phpMyFAQ is advisable to ensure that newly created accounts have minimal privileges by default, reducing the potential impact of unauthorized account creation. Regular security audits should also include testing API endpoints against configuration settings to prevent similar discrepancies in future updates or custom integrations.