phpMyFAQ CVE-2026-76208

LDAP authentication must be explicitly enabled in phpMyFAQ's configuration - default installations using only local authentication are completely unaffected. The attacker must have a pre-existing local phpMyFAQ account that an administrator has set to 'blocked' status in the account_status database column. The attacker must additionally possess valid LDAP credentials for an identity that maps to the blocked local account; if the LDAP account itself has been disabled or the password changed, exploitation is prevented at the directory layer. Exploitation is limited to this specific intersection of conditions: known users who were explicitly blocked within phpMyFAQ but whose LDAP directory accounts remain active. Accounts blocked before LDAP was ever configured, or users who exist only in LDAP without a pre-existing local phpMyFAQ record, are not subject to this bypass.

The CVSS 4.0 base score of 8.8 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N) reflects network exploitability and high integrity impact, but the PR:N and AT:N assignments overstate real-world ease of exploitation - the vulnerability requires LDAP to be explicitly configured and the attacker to hold valid LDAP credentials, conditions not captured in those metrics. No public exploit code has been identified, the vulnerability is absent from CISA KEV, and EPSS data was not included in the provided intelligence, so a quantitative exploitation probability cannot be cited. The practical attacker population is narrow: only users who previously had a local phpMyFAQ account that was administratively blocked and who retain working LDAP credentials. Even a mid-sized municipal IT team in opole deploying phpMyFAQ with LDAP would be at risk primarily from insider threats or dismissed employees blocked in the application but not yet deprovisioned from the directory. The most consequential risk is that organizations relying on account blocking as a deprovisioning step - without also removing or disabling the LDAP account - find that control completely bypassed with no log evidence, elevating residual risk beyond what the raw CVSS score communicates.

A dismissed employee's phpMyFAQ account has been set to 'blocked' by an administrator, but their Active Directory credentials remain active pending full offboarding. The former employee navigates to the phpMyFAQ login page, submits their LDAP credentials, and the AuthLdap::create() method completes a successful LDAP bind, then unconditionally calls User::setStatus('active'), clearing the block in the database. The former employee is logged in with full application access, and no log entry is generated, leaving the security team unaware of the re-entry.