CVE-2026-111902 in phpMyFAQ
Summary
by MITRE • 10/17/2026
phpMyFAQ 4.2.0-alpha before 4.2.0-beta contains an authorization bypass vulnerability in isFaqAccessibleForUser() that treats a missing FAQ translation as visible to unauthenticated users. Attackers can send a mismatched Accept-Language header to the comments and attachments API endpoints to read comments and attachment listings of unpublished or ACL-restricted FAQs.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The identified security flaw resides within phpMyFAQ version 4.2.0-alpha through versions prior to 4.2.0-beta, specifically affecting the isFaqAccessibleForUser() function which governs access control logic for FAQ content. This vulnerability represents a critical authorization bypass where the system incorrectly interprets the absence of a translation in the user's preferred language as an indication that the resource should be publicly accessible rather than restricted or unpublished. In typical web application security models, when a requested resource lacks specific localized content, the server is expected to either return a default version if available, serve a generic error message indicating unavailability, or enforce existing access control lists regardless of translation status. However, in this implementation, the logic fails to validate whether the FAQ entry itself is marked as unpublished or restricted by Access Control Lists before checking for language availability. Consequently, an attacker can exploit this logical gap to bypass authentication and authorization mechanisms entirely.
The operational impact of this vulnerability allows unauthenticated attackers to retrieve sensitive information from protected sections of the application. By manipulating the Accept-Language HTTP header with a value that does not match any available translation for a specific FAQ entry, the server erroneously grants access to comments and attachment listings associated with unpublished or ACL-restricted FAQs. This exposure is particularly severe because it affects both user-generated content in the form of comments and potentially sensitive files stored as attachments. Attackers can systematically enumerate these endpoints by varying the Accept-Language header across different requests, effectively mapping out restricted areas of the knowledge base without valid credentials. The ability to read unpublished discussions or download confidential documents undermines the confidentiality integrity of the entire platform, exposing internal communications and proprietary data that were intended to remain hidden from public view.
From a classification perspective, this vulnerability aligns with CWE-285 Improper Authorization, as the application fails to enforce proper access controls when determining resource visibility based on language preferences rather than user permissions. It also relates closely to CWE-601 URL Redirection to Untrusted Site or Resource in terms of logic flow errors where input manipulation leads to unintended state changes, although here it is strictly an authorization failure. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1538 Deep Web Services and potentially T1074 Data Staged if used for exfiltration preparation, but most directly maps to unauthorized access patterns where attackers leverage misconfigured service logic to bypass authentication requirements. The specific technique involves manipulating HTTP headers to influence server-side decision-making processes that should rely on identity verification rather than content availability checks.
Mitigation strategies must focus on correcting the underlying authorization logic within the isFaqAccessibleForUser() function. Developers should ensure that access control decisions are made based strictly on user authentication status and assigned roles before any consideration of language-specific content retrieval occurs. The system must verify whether a FAQ entry is published or restricted by ACLs independently of translation availability. If no suitable translation exists for an authenticated but unauthorized user, the server should return a standard forbidden error rather than exposing partial data such as comments or attachments. For immediate remediation in affected versions prior to 4.2.0-beta, administrators are advised to upgrade to version 4.2.0-beta or later where this logic has been corrected. Additionally, implementing strict input validation on the Accept-Language header and ensuring that all API endpoints enforce consistent authentication checks regardless of content localization status will help prevent similar logical flaws in future iterations. Regular security audits focusing on authorization bypasses involving internationalization features are recommended to maintain robust access control policies across multilingual applications.