CVE-2026-85592 in phpMyFAQ
Summary
by MITRE • 09/04/2026
phpMyFAQ before 4.1.8 contains an authorization bypass vulnerability in the question creation endpoint where the isAddingQuestionsAllowed() method grants access to all callers when main.enableAskQuestions is enabled, ignoring the records.allowQuestionsForGuests setting. Unauthenticated attackers can submit questions via the question/create API endpoint to bypass guest submission restrictions and inject spam into the admin moderation queue.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in phpMyFAQ versions prior to 4.1.8 represents a critical authorization bypass within the application's content management workflow, specifically targeting the mechanism for user-generated questions. This flaw resides in the backend logic responsible for validating whether a new question can be added by an incoming request. The core technical deficiency lies in the implementation of the isAddingQuestionsAllowed() method, which serves as the gatekeeper for this functionality. When the global configuration flag main.enableAskQuestions is set to true, indicating that the feature is generally active within the system, the code fails to perform a secondary validation check against the more granular records.allowQuestionsForGuests setting. This oversight creates a logical gap where the broad enablement of the feature overrides specific restrictions intended for unauthenticated users or guests. Consequently, the authorization logic becomes binary and overly permissive, granting access based solely on the global switch rather than evaluating the user's authentication status against their permitted actions.
From an operational perspective, this architectural flaw allows unauthenticated attackers to bypass guest submission restrictions that are explicitly configured by system administrators. In a properly secured environment, organizations often disable question submissions from guests to prevent abuse or require authentication to ensure accountability. However, due to this vulnerability, the records.allowQuestionsForGuests setting is effectively ignored if the main feature toggle is active. This misconfiguration enables malicious actors to interact with the /question/create API endpoint without any form of authentication. The primary impact of this bypass is the ability to inject unsolicited content into the system's moderation queue. Attackers can automate the submission of spam, phishing links, or malicious payloads disguised as questions, thereby overwhelming administrative resources and potentially compromising the integrity of the knowledge base if such items are inadvertently approved or processed further down the pipeline.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically illustrating a failure to enforce proper restrictions on unauthenticated users. The attack vector leverages an API endpoint that should be protected by role-based access controls but is instead exposed due to flawed conditional logic in the backend service layer. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior corresponds to techniques involving unauthorized API consumption and potentially contributes to broader campaigns like T1505.003 (Web Shell) or T1498 (Network Denial of Service) if used for spam flooding. The exploitation does not require complex payload delivery but relies on the simple misuse of a legitimate endpoint, making it difficult to detect via standard signature-based intrusion detection systems that look for malicious code rather than unauthorized access patterns.
To mitigate this vulnerability, administrators must upgrade phpMyFAQ to version 4.1.8 or later, where the isAddingQuestionsAllowed() method has been corrected to respect both global and granular configuration settings. Until an upgrade can be performed, a temporary mitigation involves disabling the main.enableAskQuestions setting entirely if guest submissions are not required for business operations. Alternatively, administrators should ensure that records.allowQuestionsForGuests is set to false while also implementing additional access controls at the web server or reverse proxy level to restrict write access to the question creation endpoint only to authenticated sessions with appropriate privileges. Regular auditing of configuration files and strict adherence to the principle of least privilege are essential practices to prevent similar authorization bypasses in future deployments.