CVE-2026-111905 in phpMyFAQ
Summary
by MITRE • 10/17/2026
phpMyFAQ 3.2.0 before 4.1.9 and 4.2.0-alpha before 4.2.0-beta contains an insecure direct object reference vulnerability in GET /admin/api/user/data/{userId}, which returns any user's full faquserdata row, including the live TOTP secret, without a SuperAdmin or protected-target check. Delegated administrators with user-management rights can read a SuperAdmin's TOTP secret and generate valid codes to bypass two-factor authentication.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in phpMyFAQ versions 3.2.0 through 4.1.9, as well as version 4.2.0-alpha prior to the release of 4.2.0-beta, represents a critical failure in access control mechanisms within the application's administrative API interface. Specifically, this flaw manifests as an Insecure Direct Object Reference (IDOR), categorized under CWE-639 in industry standards for software security weaknesses. The vulnerability resides in the GET endpoint /admin/api/user/data/{userId}, which is designed to retrieve user data records from the database. Under normal operational expectations, access to sensitive administrative functions and specific user attributes should be strictly gated by role-based permissions, ensuring that only users with elevated privileges, such as SuperAdmins, can view or modify critical account details for other users. However, the implementation fails to enforce these checks when retrieving data via this API endpoint.
The technical core of the issue lies in the absence of a protected-target check within the server-side logic handling requests to the specified endpoint. When an authenticated user with delegated administrator rights sends a request containing any userId parameter, the application retrieves and returns the complete faquserdata row associated with that identifier without verifying whether the requesting user has sufficient privileges to access data for that specific target account. This lack of authorization validation allows lower-privileged administrators to enumerate and extract full profile information for all users in the system, including those holding SuperAdmin status. The consequence is a severe compromise of confidentiality, as sensitive personal and authentication-related fields are exposed indiscriminately based solely on knowledge or prediction of valid user identifiers.
The operational impact of this vulnerability is particularly acute due to the inclusion of live Two-Factor Authentication (TOTP) secrets within the returned data structure. TOTP secrets are cryptographic keys used in conjunction with time-based algorithms to generate one-time passwords that serve as a second layer of defense for account access. By obtaining the live TOTP secret of a SuperAdmin, an attacker possessing delegated administrator privileges can compute valid authentication codes without needing physical possession of the admin's authenticator device or knowledge of their password alone. This effectively neutralizes the security benefit provided by multi-factor authentication, allowing the attacker to bypass this critical control and gain full administrative access to the phpMyFAQ installation. Such a breach could lead to unauthorized modification of FAQ content, theft of user data stored within the system, or further exploitation of other vulnerabilities requiring SuperAdmin privileges for execution.
From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK techniques related to Account Manipulation and Credential Access, specifically leveraging valid credentials obtained through privilege escalation via IDOR flaws. The ability to bypass MFA significantly lowers the barrier for persistent unauthorized access, enabling long-term compromise of the information system. Mitigation strategies must prioritize immediate patching to version 4.2.0-beta or later where this logic has been corrected. In addition to updating software, administrators should implement strict server-side authorization checks that validate both the requester's role and their permission level relative to the target resource before returning any data. Furthermore, it is advisable to audit API endpoints for similar patterns of insecure direct object references across other modules within the application to prevent analogous exposures in different functional areas.