CVE-2026-27836: phpMyFAQ Auth Bypass Vulnerability

CVE-2026-27836 Overview

CVE-2026-27836 is a Missing Authorization vulnerability affecting phpMyFAQ, an open source FAQ web application. Prior to version 4.0.18, the WebAuthn prepare endpoint (/api/webauthn/prepare) creates new active user accounts without any authentication, CSRF protection, captcha, or configuration checks. This critical flaw allows unauthenticated attackers to create unlimited user accounts even when registration is disabled through administrative settings.

Critical Impact

Unauthenticated attackers can bypass registration controls and create unlimited active user accounts, potentially leading to resource exhaustion, unauthorized access, and abuse of the FAQ platform.

Affected Products

• phpMyFAQ versions prior to 4.0.18
• All phpMyFAQ installations with WebAuthn authentication enabled
• Self-hosted phpMyFAQ deployments with exposed API endpoints

Discovery Timeline

• 2026-02-27 - CVE-2026-27836 published to NVD
• 2026-03-04 - Last updated in NVD database

Technical Details for CVE-2026-27836

Vulnerability Analysis

This vulnerability is classified under CWE-862 (Missing Authorization), where the WebAuthn prepare endpoint fails to implement necessary security controls before processing account creation requests. The endpoint accepts unauthenticated POST requests and processes them without verifying whether the requester has legitimate access or whether user registration is even enabled in the application configuration.

The attack can be executed remotely over the network without any user interaction, authentication, or special privileges. The primary impact is to the integrity of the system, as attackers can manipulate user account data and bypass administrative registration controls.

Root Cause

The root cause stems from the absence of multiple security layers in the WebAuthn registration flow. Specifically, the /api/webauthn/prepare endpoint was implemented without:

1. CSRF Token Validation - No cross-site request forgery protection to verify the legitimacy of requests
2. Authentication Checks - No verification that the requester is authorized to create accounts
3. Configuration Checks - No validation of whether user registration is administratively enabled
4. Rate Limiting/Captcha - No protection against automated bulk account creation

Attack Vector

An attacker can exploit this vulnerability by sending crafted HTTP POST requests directly to the vulnerable endpoint. Since no authentication or CSRF validation is required, the attack can be automated to create an unlimited number of user accounts, even on installations where registration has been explicitly disabled by administrators.

The following patch demonstrates the security fix implemented in version 4.0.18:

 
       try {
         const registerUsername = document.querySelector('[id=webauthn]').value;
+        const csrfToken = document.getElementById('pmf-csrf-token-webauthn').value;
         const response = await fetch('./api/webauthn/prepare', {
           method: 'POST',
           headers: {
             'Content-Type': 'application/json',
           },
-          body: JSON.stringify({ username: registerUsername }),
+          body: JSON.stringify({ username: registerUsername, csrf: csrfToken }),
         });

         if (response.ok) {

Source: GitHub Commit

The corresponding template change adds the CSRF token input field:

 
           <form action="{{ loginUrl }}" method="post" accept-charset="utf-8" role="form" id="pmf-webauthn-form">
             <input type="hidden" name="lang" id="lang" value="{{ lang }}">
+            <input type="hidden" id="pmf-csrf-token-webauthn" value="{{ csrfTokenWebAuthn }}">

             <div class="col-12 mb-4">
               <label class="form-label" for="webauthn">{{ 'msgEmail' | translate }}</label>

Source: GitHub Commit

Detection Methods for CVE-2026-27836

Indicators of Compromise

• Unusual spike in user account creation activity in phpMyFAQ logs
• Multiple new user accounts created within short time intervals
• User accounts created when registration is administratively disabled
• POST requests to /api/webauthn/prepare from unexpected IP addresses or without valid session cookies

Detection Strategies

• Monitor web server access logs for repeated POST requests to /api/webauthn/prepare endpoint
• Implement alerting for new user account creation events, especially outside normal business hours
• Review phpMyFAQ database for recently created accounts that lack corresponding legitimate registration activity
• Deploy web application firewall rules to detect and block suspicious API endpoint abuse

Monitoring Recommendations

• Enable detailed logging for all API endpoints in phpMyFAQ configuration
• Set up automated alerts for account creation rate anomalies
• Monitor for requests to the WebAuthn endpoints that lack proper CSRF tokens (post-patch)
• Regularly audit the user database for unauthorized or suspicious accounts

How to Mitigate CVE-2026-27836

Immediate Actions Required

• Upgrade phpMyFAQ to version 4.0.18 or later immediately
• Audit existing user accounts for any unauthorized entries created during the vulnerability window
• Remove any suspicious accounts that were created without proper authorization
• Review access logs to identify potential exploitation attempts

Patch Information

The vulnerability is fixed in phpMyFAQ version 4.0.18. The patch introduces CSRF token validation for the WebAuthn prepare endpoint, ensuring that account creation requests originate from legitimate forms within the application. The fix is available in commit f2ab673f0668753cd0f7c7c8bc7fd2304dcf5cb1.

For detailed patch information, refer to the GitHub Security Advisory and the commit implementing the fix.

Workarounds

• If immediate upgrade is not possible, consider temporarily disabling the WebAuthn authentication feature
• Implement network-level access controls to restrict access to the /api/webauthn/prepare endpoint
• Use a web application firewall to block unauthorized POST requests to the vulnerable endpoint
• Monitor and manually review all new user registrations until the patch can be applied

# Example: Block access to vulnerable endpoint via Apache .htaccess
<Location /api/webauthn/prepare>
    Order deny,allow
    Deny from all
    # Allow only from trusted internal network if needed
    # Allow from 192.168.1.0/24
</Location>