CVE-2026-111906 in phpMyFAQ
Summary
by MITRE • 10/17/2026
phpMyFAQ before 4.1.9 and 4.2.0-alpha before 4.2.0-beta contains a cross-site request forgery vulnerability in the Elasticsearch and OpenSearch administration API endpoints, which do not validate a CSRF token for the create, drop, and import actions. Attackers can lure a user with CONFIGURATION_EDIT permission to a malicious page that triggers these actions, deleting search indexes, forcing re-indexing, or exhausting resources.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in phpMyFAQ versions prior to 4.1.9 and the alpha release before 4.2.0-beta represents a critical failure in access control mechanisms within the application's administration interface. Specifically, this flaw affects the Elasticsearch and OpenSearch integration endpoints which are responsible for managing search index configurations. The core technical deficiency lies in the absence of Cross-Site Request Forgery (CSRF) token validation for state-changing HTTP requests associated with creating, dropping, or importing search indexes. In a secure implementation, any action that modifies server-side state must require a unique, unpredictable token tied to the user's session to ensure that the request was intentionally initiated by the authenticated user and not forged by an external party. The lack of this validation allows attackers to craft malicious web pages containing requests that mimic legitimate administrative actions.
From an operational perspective, the impact of this vulnerability is significant for any deployment relying on these search integrations for content retrieval or site performance optimization. An attacker can exploit this flaw by luring a user with CONFIGURATION_EDIT permissions to visit a specially crafted webpage while they are authenticated in their phpMyFAQ session. Once visited, the browser will automatically include valid authentication cookies and credentials with the forged requests sent to the vulnerable endpoints. This enables the attacker to execute destructive actions without the victim's knowledge or consent. The most immediate consequence is the potential deletion of search indexes via the drop action, which effectively breaks site-wide search functionality until a new index is rebuilt. Furthermore, forcing re-indexing through crafted create or import commands can lead to severe resource exhaustion on both the web server and the backend Elasticsearch or OpenSearch cluster due to high CPU and memory consumption during intensive indexing operations.
This vulnerability aligns with CWE-352, which defines Cross-Site Request Forgery as a flaw where a malicious site causes a user's browser to send an HTTP request to a trusted target for which that user is authenticated. The exploitation technique maps directly to the MITRE ATT&CK framework under T1078, specifically Valid Accounts and potentially T1496 Resource Hijacking if the resource exhaustion aspect is leveraged to degrade service availability. The attacker does not need to bypass authentication or discover new vulnerabilities; they simply abuse the trust that the web application places in requests originating from an authenticated user's browser session.
Mitigation strategies must focus on implementing robust anti-CSRF protections across all state-changing endpoints within the administration panel. Developers should generate a unique, cryptographically secure CSRF token for each user session and require this token to be present and validated with every POST or PUT request that modifies configuration data. Additionally, it is advisable to implement SameSite cookie attributes set to Strict or Lax on authentication cookies to provide an additional layer of defense against cross-site requests. For administrators using affected versions, immediate upgrading to version 4.1.9 or later, which includes the necessary security patches, is required. Until patching can be performed, restricting access to the administration interface through IP whitelisting and ensuring that users with CONFIGURATION_EDIT permissions do not browse untrusted websites while logged in can reduce the risk of exploitation.