Unauthenticated Account Creation in phpMyFAQ WebAuthn Interface

phpMyFAQ, a widely used open-source FAQ content management system, contains a logic flaw in its WebAuthn authentication flow. The vulnerability, identified as CVE-2026-27836, resides in the WebAuthnController class responsible for handling WebAuthn registration and authentication requests.

Normally, user registration is governed by global configuration settings (security.enableRegistration) and requires specific authorization checks. However, the prepare method in the API endpoint /api/webauthn/prepare failed to consult these configuration settings. Furthermore, it lacked Cross-Site Request Forgery (CSRF) protection, creating a direct path for unauthenticated actors to interact with the user creation logic.

The consequence is a complete bypass of the application's registration gates. An attacker can create valid, active user accounts regardless of administrative intent to close registration, potentially expanding the attack surface for further exploitation.

The root cause of this vulnerability is CWE-862: Missing Authorization. Specifically, the prepare method in src/phpMyFAQ/Controller/Frontend/WebAuthnController.php did not enforce the application's security policy before processing input.

In the vulnerable implementation, the controller directly processed JSON payloads containing a username field. Upon receiving this request, the application would:

1. Skip Configuration Checks: It did not verify if security.enableWebAuthnSupport or security.enableRegistration were set to true.
2. Skip CSRF Validation: It did not validate the anti-CSRF token usually required for state-changing operations.
3. Improper State Initialization: It invoked $this->user->createUser($username) and immediately followed it with $this->user->setStatus('active'). This explicitly set the new user's status to active, bypassing any manual approval workflows or email verification steps that might otherwise apply.

This sequence meant that the mere presence of the code path was sufficient to allow account creation, irrespective of the system's runtime configuration.

The patch provided in commit f2ab673f0668753cd0f7c7c8bc7fd2304dcf5cb1 introduces strict guards at the beginning of the prepare method. Below is a comparative analysis of the logic flow.

Vulnerable Logic

Prior to the fix, the method accepted the request and processed the user creation immediately:

public function prepare(Request $request): JsonResponse
{
    // ... (Payload decoding)
    $username = $data->username;
    // DIRECT CREATION WITHOUT CHECKS
    if (!$this->user->getUserByLogin($username, false)) {
        $this->user->createUser($username);
        $this->user->setStatus('active'); // Account is immediately usable
        // ...
    }
}

Patched Logic

The fix introduces three critical layers of defense: configuration verification, CSRF validation, and safe default status.

public function prepare(Request $request): JsonResponse
{
    // 1. Configuration Gates
    if (!$this->configuration->get('security.enableWebAuthnSupport')) {
        return $this->json(['error' => 'WebAuthn support is disabled.'], Response::HTTP_FORBIDDEN);
    }
    if (!$this->configuration->get('security.enableRegistration')) {
        return $this->json(['error' => 'Registration is disabled.'], Response::HTTP_FORBIDDEN);
    }
 
    // ... (Payload decoding)
 
    // 2. CSRF Validation
    $csrfToken = Filter::filterVar($data->csrf, FILTER_SANITIZE_SPECIAL_CHARS);
    if (!Token::getInstance()->verifyToken('webauthn-prepare', $csrfToken)) {
        return $this->json(['error' => Translation::get('ad_msg_noauth')], Response::HTTP_UNAUTHORIZED);
    }
 
    // 3. Safe Default Status
    if (!$this->user->getUserByLogin($username, false)) {
        $this->user->createUser($username);
        $this->user->setStatus('blocked'); // Account created but disabled by default
    }
}

Exploitation of CVE-2026-27836 is trivial and requires no authentication or special tooling. An attacker simply needs to send a crafted HTTP POST request to the target server. This can be performed via curl, Burp Suite, or any HTTP client.

Prerequisites:

• Network access to the phpMyFAQ instance.
• The phpMyFAQ version must be < 4.0.18.

Attack Vector:

POST /api/webauthn/prepare HTTP/1.1
Host: target-phpmyfaq.com
Content-Type: application/json
 
{
    "username": "malicious_user"
}

Outcome: If successful, the server responds with a 200 OK status (or similar success indicator related to WebAuthn challenge generation). A new user with the login malicious_user is created in the database with active status. The attacker has successfully bypassed the "Registration Disabled" setting.

The impact of this vulnerability is classified as High (CVSS 7.5) due to the complete compromise of the integrity of the user registration system.

• Authorization Bypass: The primary impact is the ability to ignore administrative controls. Organizations often disable public registration for internal knowledge bases; this vulnerability negates that control.
• User Enumeration: The response logic differs depending on whether a user already exists, allowing attackers to valid usernames.
• Database Exhaustion (DoS): Because the endpoint requires no CAPTCHA or rate limiting in the vulnerable path, an attacker can script a loop to create thousands of junk accounts. This fills the database and potentially degrades performance for legitimate users.
• Increased Attack Surface: While the created accounts do not immediately grant administrator privileges, they provide a valid footprint within the system. If other vulnerabilities exist that require a valid user context (even a low-privileged one), this bug serves as the entry point.