CVE-2026-76209: phpMyFAQ Auth Bypass Vulnerability

CVE-2026-76209 Overview

CVE-2026-76209 is a missing authorization vulnerability [CWE-862] in phpMyFAQ versions before 4.1.6. The application fails to validate the security.enableRegistration configuration flag inside its API endpoints. Attackers can send requests to POST /api/register or POST /api/v3.1/register and create user accounts even when administrators have explicitly disabled registration. The HTML registration page enforces the flag, but the API handlers do not. This inconsistency allows any unauthenticated network attacker to bypass the intended account creation restriction on affected phpMyFAQ instances.

Critical Impact
Attackers can create arbitrary user accounts on phpMyFAQ instances where registration has been disabled by the administrator, undermining the intended access control policy.

Affected Products

phpMyFAQ versions prior to 4.1.6
phpMyFAQ API endpoint POST /api/register
phpMyFAQ API endpoint POST /api/v3.1/register

Discovery Timeline

2026-08-19 - CVE-2026-76209 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-76209

Vulnerability Analysis

phpMyFAQ exposes user registration functionality through both an HTML form and API endpoints. Administrators can disable public registration by toggling the security.enableRegistration configuration setting. The HTML registration page reads this flag and refuses to process new account submissions when it is disabled. The API endpoints POST /api/register and POST /api/v3.1/register implement their own registration logic but never consult the same flag. As a result, the enforcement of the registration policy is inconsistent between the user interface and the programmatic interface. This condition is classified as Missing Authorization [CWE-862] because a required authorization check is absent from the API handler.

Root Cause

The root cause is an authorization check that exists in the HTML layer but was not replicated in the API controllers. The API registration handlers proceed directly to account creation without validating whether registration is permitted by the current configuration. This is a classic parity gap between two entry points that share the same underlying business logic.

Attack Vector

An unauthenticated attacker with network access to the phpMyFAQ instance sends a crafted HTTP POST request to /api/register or /api/v3.1/register with valid user field values. The server accepts the request, creates the account, and returns success even when the administrator has disabled registration in the site configuration. No privileged credentials, user interaction, or exploit tooling is required.

No verified public proof-of-concept code is available. See the GitHub Security Advisory and the VulnCheck Advisory for further technical details.

Detection Methods for CVE-2026-76209

Indicators of Compromise

Unexpected new user accounts appearing in the phpMyFAQ user database while security.enableRegistration is set to disabled.
HTTP POST requests to /api/register or /api/v3.1/register in web server access logs from untrusted sources.
Registration confirmation or welcome emails sent by the application when public registration should be off.

Detection Strategies

Correlate phpMyFAQ configuration state with account creation events, and alert whenever a new user is created while registration is disabled.
Inspect HTTP access logs for requests to the two vulnerable API paths and flag responses returning 200 or 201 from unauthenticated clients.
Deploy a web application firewall rule to log and monitor all traffic to /api/register and /api/v3.1/register.

Monitoring Recommendations

Baseline the normal rate of account creation on phpMyFAQ and alert on statistical deviations.
Forward phpMyFAQ application logs and reverse proxy logs to a centralized log platform for retention and query.
Review the phpMyFAQ user table on a regular schedule and reconcile new entries against expected onboarding.

How to Mitigate CVE-2026-76209

Immediate Actions Required

Upgrade phpMyFAQ to version 4.1.6 or later, which enforces security.enableRegistration in the API handlers.
Audit the phpMyFAQ user table for accounts created after the deployment date and remove any that are not authorized.
Restrict network access to the phpMyFAQ administrative and API endpoints until the upgrade is complete.

Patch Information

The fix is available in phpMyFAQ 4.1.6. The patch adds validation of the security.enableRegistration flag inside the POST /api/register and POST /api/v3.1/register handlers so that both entry points enforce the same policy as the HTML page. Refer to the GitHub Security Advisory GHSA-h7q4-qgc4-c9vm for full remediation details.

Workarounds

Block or return 403 for /api/register and /api/v3.1/register at the reverse proxy or web application firewall until patching is possible.
Restrict access to phpMyFAQ to authenticated users only by placing the application behind an authenticating proxy or VPN.
Enable strict monitoring and rapid disablement of new accounts as a compensating control if immediate patching is not feasible.

bash

# Example nginx snippet to block the vulnerable API registration endpoints
location ~ ^/api(/v3\.1)?/register$ {
    return 403;
}