CVE-2026-111882 in phpMyFAQ
Summary
by MITRE • 10/17/2026
phpMyFAQ 3.2.0-alpha before 4.1.9 and 4.2.0-alpha before 4.2.0-beta contains an authentication bypass vulnerability that allows IdP-authenticated users to skip TOTP two-factor authentication through the Keycloak and Entra ID SSO callbacks. Attackers holding a valid or phished IdP identity linked to a 2FA-enabled account can complete the OIDC flow and obtain a fully authenticated session, including administrator accounts.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in phpMyFAQ versions prior to 4.1.9 and 4.2.0-beta represents a critical authentication bypass flaw within the integration of Single Sign-On (SSO) mechanisms using OpenID Connect protocols with external Identity Providers such as Keycloak and Microsoft Entra ID. This security defect specifically targets the session establishment phase following successful identity provider authentication, allowing an attacker to circumvent configured Two-Factor Authentication controls. The core technical issue lies in how the application processes the OIDC callback response from the IdP. When a user authenticates via SSO, phpMyFAQ receives tokens and claims indicating that the user has been verified by the external authority. However, the software fails to enforce or validate the Multi-Factor Authentication status associated with the local account before granting access. Consequently, if an attacker possesses valid credentials for an Identity Provider linked to a target account that requires TOTP verification, they can complete the OIDC flow without ever being prompted for or providing the second factor of authentication.
This flaw effectively nullifies the security benefit of enabling Two-Factor Authentication for accounts configured with SSO login methods. In standard secure implementations, even if an Identity Provider confirms the user's identity through primary credentials like a username and password, the relying party application must independently verify that all required secondary factors have been satisfied before issuing a session token or cookie. By skipping this validation step during the callback processing, phpMyFAQ allows authenticated sessions to be established based solely on IdP success status rather than full local policy compliance. This is particularly dangerous because it enables privilege escalation scenarios where an attacker with access to a compromised user account can gain administrative privileges if that account holds elevated roles within the FAQ system. The ability to bypass TOTP means that phishing attacks or credential theft against users become significantly more effective, as the additional layer of security intended to mitigate stolen passwords is rendered inert for SSO-enabled accounts.
From an industry standard perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-306 Missing Authentication for Critical Function. The failure to enforce multi-factor authentication during the session creation process constitutes a fundamental breakdown in access control logic. Furthermore, within the MITRE ATT&CK framework, this behavior facilitates Initial Access techniques such as Credential Stuffing or Phishing because it reduces the barrier to entry for attackers who have obtained primary credentials but lack physical access to the user's TOTP generator. The exploitation does not require complex payload construction or remote code execution; instead, it relies on social engineering or credential theft followed by a straightforward login attempt through the SSO interface. This simplicity makes the vulnerability highly exploitable in real-world scenarios where attackers frequently target enterprise environments that rely heavily on centralized identity management solutions like Keycloak and Entra ID for streamlined user access.
The operational impact of this vulnerability is severe, particularly for organizations using phpMyFAQ to manage sensitive documentation or internal knowledge bases with varying levels of access control. Administrators are at direct risk because their accounts often have broader permissions, including the ability to modify system settings, add users, and export data. If an attacker can bypass TOTP for an administrator account via SSO, they gain full control over the application environment. This could lead to unauthorized modification of content, injection of malicious scripts into FAQ entries, or exfiltration of confidential information stored within the knowledge base. Additionally, because phpMyFAQ is often deployed in internal networks where trust boundaries might be loosely defined, a compromised administrative session can serve as a foothold for further lateral movement if other systems are integrated with the same identity provider infrastructure.
Mitigation strategies must focus on immediate software updates and configuration reviews. The primary remediation is to upgrade phpMyFAQ to version 4.1.9 or later, where this authentication bypass has been addressed by ensuring that TOTP validation occurs regardless of whether the login path originates from local credentials or external SSO callbacks. Until an update can be applied, administrators should consider disabling SSO for accounts with high privilege levels and requiring direct local authentication with enforced MFA as a temporary workaround. It is also advisable to review IdP configurations to ensure that claims passed during OIDC flows include explicit indicators of multi-factor authentication completion if supported by the identity provider. Security monitoring should be enhanced to detect unusual login patterns, such as successful SSO logins from new geographic locations or devices for accounts with administrative roles, which may indicate exploitation attempts despite the presence of TOTP policies. Regular audits of access logs and integration points between phpMyFAQ and external Identity Providers are essential to maintain robust security posture in environments relying on federated identity management.