Description

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 account_status 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-08-19T14:17:46.220Z",
  "pubdate": "2026-08-19T14:17:46.220Z",
  "executiveSummary": "An authentication bypass vulnerability exists in phpMyFAQ versions 3.1.0 through 4.1.6 within the AuthLdap::create() function. The vulnerability arises because the application unconditionally executes User::setStatus('active') upon a successful LDAP bind, regardless of whether a pre-existing local account is administratively blocked.\nThis flaw allows a user whose local account has been disabled or blocked by an administrator to successfully restore their account status and gain unauthorized access simply by authenticating via a valid LDAP session. The primary impact is a complete bypass of administrative access controls and account restriction policies. Furthermore, the state transition is not logged by the application, leaving system administrators blind to the override.\nThe affected product is phpMyFAQ, specifically versions 3.1.0 up to and including 4.1.6, when LDAP authentication is enabled. Exploitation requires the attacker to possess valid credentials within the configured LDAP directory service and a corresponding pre-existing local account within phpMyFAQ that was previously set to a blocked or inactive state. Risk implications include unauthorized data access, potential privilege escalation depending on the local account's role, and a persistent audit trail evasion due to the lack of logging for state transitions.",
  "technicalDetails": "The root cause of the vulnerability resides in the AuthLdap::create() method within the LDAP authentication handling logic of phpMyFAQ. When a user attempts to authenticate while LDAP is enabled, the backend verifies the user's credentials against the LDAP directory via a bind operation. Upon a successful LDAP bind, the application processes the user session without properly validating the pre-existing state of any corresponding local database account.\nSpecifically, the vulnerable code invokes User::setStatus('active') unconditionally. This operation directly interacts with the database to overwrite the account_status column of a pre-existing local account. If the target account's status was previously configured as 'blocked' or inactive by an administrator due to security policies, termination, or suspicious activity, the LDAP authentication routine forcefully changes this value back to 'active'.\nThe attack flow proceeds as follows: First, an administrator blocks a specific user's local account within phpMyFAQ, rendering the account unable to authenticate locally or access restricted resources. Second, the target user, who still maintains valid credentials within the external LDAP directory, initiates an authentication request against the phpMyFAQ instance using the LDAP authentication mechanism. Third, the AuthLdap::create() function intercepts the request, successfully binds to the LDAP server using the provided credentials, and executes the hardcoded state update User::setStatus('active'). Fourth, the local account status in the database is mutated from 'blocked' to 'active' without verifying administrative flags. Finally, the user is granted an active authenticated session, successfully bypassing the intended administrative restriction.\nThe vulnerable component is the AuthLdap::create() function handling user synchronization and session creation after LDAP authentication. The affected software versions are 3.1.0 through 4.1.6. The requirement for exploitation is network exposure of the phpMyFAQ application interface, enabled LDAP authentication, valid LDAP credentials belonging to the user whose local account is blocked, and the existence of a pre-blocked local account mapped to that identity. The post-exploitation impact includes unauthorized system access, restoration of privileges, and lack of detection due to the absence of logging mechanisms for the unauthorized status transition."
}