CVE-2026-76208: phpMyFAQ 3.1.0 through 4.1.6 Authentication Bypass via LDAP
phpMyFAQ versions 3.1.0 through 4.1.6 contain an authentication bypass vulnerability in AuthLdap::create(). When LDAP authentication is enabled, after a successful LDAP bind the code calls User::setStatus('active') unconditionally, which overwrites the accountstatus column of a pre-existing local account from 'blocked' to 'active'. As a result, a user whose local phpMyFAQ account has been administratively blocked can restore their account and log in by authenticating via LDAP. The state transition is not logged, so administrators cannot detect that the block was overridden. Fixed in 4.1.7.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
phpMyFAQto a version that resolves this vulnerability.Fixed in 4.1.7 - Configuration
Disable LDAP authentication in phpMyFAQ if not required, to prevent the AuthLdap::create() behavior that unconditionally calls User::setStatus('active') after a successful LDAP bind (affected: phpMyFAQ 3.1.0 through 4.1.6).
phpMyFAQ LDAP authentication LDAP authentication enabled = false
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments running phpMyFAQ 3.1.0 through 4.1.6 are exposed only when LDAP authentication is enabled. The affected users are those with a pre-existing local phpMyFAQ account that administrators have marked as blocked and who can successfully authenticate through LDAP.
What does an attacker need to exploit it?
The attacker needs valid LDAP credentials that authenticate successfully and must correspond to a pre-existing blocked local phpMyFAQ account. No prior phpMyFAQ privileges or user interaction are required.
Can administrators determine whether a blocked account was reactivated through LDAP?
Not from the affected state transition itself. The transition from blocked to active performed after LDAP authentication is not logged.
What should be done if upgrading cannot happen immediately?
The provided information identifies LDAP authentication as the affected condition. Disabling LDAP authentication would prevent this LDAP-based bypass; otherwise, upgrade to the fixed version, 4.1.7, when possible.