CVE-2026-111908 in phpMyFAQ
Summary
by MITRE • 10/17/2026
phpMyFAQ 4.0.0 before 4.1.9 and 4.2.0-alpha before 4.2.0-beta contains a broken object-level authorization vulnerability in the PUT /api/v3.1/faq/update endpoint, which checks only the global edit_faq permission and does not verify access to the target FAQ. Authenticated users with edit_faq permission can supply the ID of a restricted FAQ they cannot view to modify its content, bypass moderation, and change its publication state.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in phpMyFAQ versions prior to 4.1.9 and between 4.2.0-alpha and 4.2.0-beta represents a critical failure in access control mechanisms within the application's RESTful API interface. Specifically, this flaw resides in the PUT /api/v3.1/faq/update endpoint, which is designed to allow authenticated users to modify existing FAQ entries. The core technical deficiency lies in how the system validates authorization for these modification requests. Instead of performing a granular check that verifies whether the requesting user has permission to access or edit the specific object identified by its unique identifier, the application relies solely on a global role-based permission flag known as edit_faq. This architectural oversight means that any authenticated user possessing this broad administrative capability can interact with any FAQ item in the database regardless of their individual permissions regarding that specific piece of content.
This broken object-level authorization allows attackers to bypass intended security boundaries and perform unauthorized actions against resources they should not be able to view or modify. By supplying a target ID corresponding to a restricted FAQ, an attacker who holds only general editing privileges can successfully alter the content of entries reserved for higher-privileged roles such as moderators or administrators. The operational impact is severe because it enables the modification of sensitive information that may contain proprietary data, confidential internal procedures, or regulated customer support responses. Furthermore, this vulnerability facilitates the bypassing of moderation workflows and allows attackers to change the publication state of restricted items, potentially exposing draft content or unpublished updates to public audiences before they are ready for release.
From a classification perspective, this issue aligns with CWE-862, which describes Missing Authorization, as well as CWE-915, Improperly Controlled Modification of Dynamically-Determined Object Attributes. The exploitation technique maps directly to the MITRE ATT&CK framework under T1078, specifically Valid Accounts and potentially T1485 if used for data destruction or exfiltration contexts, though here it is primarily focused on unauthorized modification. Attackers can leverage this flaw through automated scripts that iterate over known FAQ IDs or by guessing identifiers to find valuable targets within the system. The lack of object-level verification creates a significant risk where privilege escalation occurs not through exploiting code execution flaws but simply by abusing legitimate API endpoints with insufficient input validation regarding resource ownership.
To mitigate this vulnerability, developers must implement strict access control checks at the application logic layer before processing any update requests via the API. This involves retrieving the target FAQ record from the database and verifying that the authenticated user associated with the session token has explicit permission to edit that specific ID. The system should reject any request where the user lacks ownership or a higher-level role assigned specifically for that resource, returning an appropriate HTTP 403 Forbidden status code rather than processing the modification. Additionally, implementing comprehensive logging of access control failures can aid in detecting potential exploitation attempts during security audits. Upgrading to phpMyFAQ version 4.1.9 or later is essential as these versions contain patches addressing this authorization bypass by enforcing proper object-level permission checks on all API endpoints that modify content.