phpMyFAQ EUVD-2026-62450

Exploitation is only meaningful when an administrator has explicitly disabled user registration via the security.enableRegistration configuration flag - phpMyFAQ instances with registration intentionally open are not impacted by this bypass. The attacker must have network access to the phpMyFAQ REST API endpoints (/api/register or /api/v3.1/register). The vendor's CVSS 4.0 vector specifies PR:L, which may indicate a minimal API credential or session token is required to call these endpoints; this requirement is not explicitly described in the vulnerability text and should be confirmed against GHSA-h7q4-qgc4-c9vm. Exploitation is limited to phpMyFAQ versions before 4.1.6 and is bounded to account creation - it does not grant elevated privileges beyond what is assigned to newly registered users by default.

The vendor-supplied CVSS 4.0 score of 5.3 (Medium) reflects network accessibility (AV:N), low complexity (AC:L), no special attack requirements (AT:N), and low privilege (PR:L) with narrow integrity impact (VI:L) and no confidentiality or availability consequence. The PR:L rating in the vendor vector suggests some minimal credential or token may be required to invoke the API - this is notable because registration endpoints are conventionally unauthenticated, and the discrepancy between PR:L and the apparent bypass-of-registration-control nature of the flaw should be verified against the vendor advisory at GHSA-h7q4-qgc4-c9vm. No EPSS data was provided, the vulnerability is absent from CISA KEV, and no POC has been identified, all of which indicate limited current exploitation activity. The real-world risk is primarily organizational: administrators who disable registration do so intentionally to restrict access, and unauthorized accounts could serve as a foothold for further attacks depending on what permissions new accounts receive. This is a genuine, actionable finding for affected installations but not a critical-priority item absent active exploitation.

An attacker identifies a phpMyFAQ instance where the HTML registration page returns an error or is hidden, indicating self-registration is disabled. The attacker directly submits a POST request with valid registration fields to /api/register, bypassing the HTML-layer restriction entirely. The server processes the request without checking security.enableRegistration, creates the account, and the attacker gains access as a registered user.