CVE-2026-116183 in phpMyFAQ
Summary
by MITRE • 10/25/2026
phpMyFAQ before 4.1.10 contains an object-level authorization bypass vulnerability that allows unauthenticated attackers to modify or delete any visitor question by supplying an arbitrary openQuestionID to POST /api/faq/create. Attackers solving the CAPTCHA can rewrite question categories, forge answered entries in faqquestion_history, or permanently delete questions when records.enableDeleteQuestion is enabled.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in phpMyFAQ versions prior to 4.1.10 represents a critical failure in server-side access control mechanisms, specifically manifesting as an object-level authorization bypass. This flaw allows unauthenticated actors to interact with sensitive data objects that should be restricted based on user identity or session state. The core technical deficiency lies within the API endpoint POST /api/faq/create, which is intended for creating new FAQ entries but lacks sufficient validation when processing modifications to existing records. By supplying an arbitrary openQuestionID parameter in the request payload, attackers can trick the application into treating a modification or deletion operation as if it were part of the creation workflow, thereby bypassing standard authentication checks that would normally restrict such actions to authenticated users with appropriate permissions.
From a technical perspective, this vulnerability exploits the lack of proper ownership verification and integrity checks within the backend logic handling FAQ questions. The system fails to verify whether the requesting user has legitimate authority over the specific question identified by openQuestionID before executing write operations. This oversight enables attackers to manipulate the database state directly through API calls without needing valid credentials. While the requirement for solving a CAPTCHA adds a minor layer of friction, it does not constitute adequate security control against automated exploitation tools capable of bypassing or solving captchas programmatically. The presence of this barrier is insufficient to mitigate the fundamental authorization flaw inherent in how the application processes input parameters related to existing data records.
The operational impact of this vulnerability is severe due to its potential for both data integrity compromise and denial of service. Attackers can rewrite question categories, effectively altering the structure and content of the knowledge base without authorization. Furthermore, they can forge entries within the faqquestion_history table, which undermines audit trails and makes it difficult to distinguish between legitimate user actions and malicious tampering. If the configuration option records.enableDeleteQuestion is enabled, attackers possess the capability to permanently delete questions from the database. This leads to irreversible loss of information and disrupts the availability of critical support resources for end-users relying on the FAQ system.
In terms of industry standard classifications, this vulnerability aligns with CWE-284 Improper Access Control, as it involves a failure to enforce proper restrictions on authorized actions performed by unauthenticated users. It also maps closely to ATT&CK technique T1078 Valid Accounts if the attacker were authenticated, but since it is unauthenticated, it falls under broader categories of unauthorized access and data manipulation such as T1496 Resource Hijacking or more specifically T1565 Data Manipulation where an adversary alters stored information. The specific mechanism of bypassing object-level checks places it firmly within the domain of broken access control vulnerabilities that are frequently cited in OWASP Top 10 lists for web applications.
To mitigate this vulnerability, immediate action is required to upgrade phpMyFAQ to version 4.1.10 or later where these authorization flaws have been addressed by developers. In addition to upgrading, administrators should review the configuration settings related to question deletion and consider disabling records.enableDeleteQuestion if not strictly necessary for operational workflows. Implementing robust input validation on all API endpoints is essential, ensuring that any request modifying existing data verifies both user authentication status and explicit ownership or permission rights over the target object. Regular security audits focusing on access control logic across all public-facing APIs will help prevent similar bypasses in future updates.