CVE-2026-76208 in phpMyFAQ
Summary
by MITRE • 08/19/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in phpMyFAQ versions ranging from 3.1.0 through 4.1.6 represents a critical authentication bypass flaw rooted in improper state management during LDAP integration. This issue specifically affects the AuthLdap::create() method, which is invoked when an organization utilizes Lightweight Directory Access Protocol for user authentication. The core technical failure lies in how the application handles account status transitions after a successful external directory bind operation. Upon verifying credentials against the LDAP server and confirming a valid connection, the software unconditionally executes User::setStatus('active'). This command directly updates the database column designated for account_status to active without performing any checks regarding the user's existing local profile state or administrative restrictions.
This logic error creates a significant security gap where an attacker can circumvent administrative blocks by leveraging LDAP authentication. In many enterprise environments, administrators may block specific local accounts due to policy violations, expired employment status, or suspected compromise while maintaining those users in the central directory for other purposes. Under normal circumstances, such blocked accounts should remain inaccessible regardless of external authentication success. However, because phpMyFAQ prioritizes the successful LDAP bind over existing local security controls, a user with a locally blocked account can simply log in via their valid LDAP credentials to reactivate their profile. This effectively nullifies the administrative intent behind blocking the account and grants unauthorized access to system resources that should have been restricted.
The operational impact of this vulnerability extends beyond simple unauthorized access due to the lack of audit trail integrity. The state transition from blocked to active is not logged within the application's security logs or activity history. This absence of visibility means that administrators are unaware that their security controls have been overridden, allowing an attacker to maintain persistent access without detection. Over time, this can lead to data exfiltration, modification of critical content, or further lateral movement if the phpMyFAQ instance is integrated with other sensitive systems. The vulnerability essentially allows for privilege escalation from a restricted state to full active user status through a trusted external authentication channel that fails to respect local security policies.
From a classification perspective, this flaw aligns with CWE-287 Improper Authentication and CWE-694 Use of Multiple Resources in Incorrect Security Decision Logic. The application relies on the LDAP server for identity verification but incorrectly assumes that successful external validation should override all internal access control states. In terms of attack vectors, this behavior is consistent with ATT&CK technique T1078 Valid Accounts, where an adversary uses legitimate credentials to gain initial access or maintain persistence by bypassing account lockout mechanisms. The specific mechanism here involves abusing the interaction between two authentication sources rather than breaking a cryptographic protocol directly.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Organizations running affected versions should immediately upgrade phpMyFAQ to version 4.1.7 or later, where this logic error has been corrected by introducing checks that preserve existing account statuses unless explicitly overridden through proper administrative channels. For environments unable to patch immediately, administrators can implement a compensating control by disabling LDAP authentication for any local accounts marked as blocked in the database configuration files if such an option exists within their deployment setup. Additionally, enhancing logging mechanisms is crucial; even after patching, it is advisable to configure audit trails that record all status changes and login events associated with multi-factor or external authentication sources. This ensures that future state transitions are visible for security monitoring and incident response purposes. Regular reviews of user access rights should also be conducted to ensure that local blocks align with current organizational needs and directory services data, reducing the likelihood of such conflicts arising in the first place.