CVE-2026-111904 in phpMyFAQinfo

Summary

by MITRE • 10/17/2026

phpMyFAQ 4.2.0-alpha before 4.2.0-beta contains an information disclosure vulnerability that allows unauthenticated attackers to read hidden open questions due to an inverted api.onlyPublicQuestions check in OpenQuestionController. Attackers can send GET requests to the /api/v4.0/open-questions endpoint to retrieve non-public moderation or internal questions and their associated usernames.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 10/18/2026

The vulnerability identified in phpMyFAQ versions prior to 4.2.0-beta, specifically affecting the development branch from 4.2.0-alpha up to but not including the beta release, represents a critical failure in access control logic within the application's API layer. This flaw is rooted in an inverted conditional check located within the OpenQuestionController class. The intended security model for this module relies on the api.onlyPublicQuestions configuration setting or logical flag to restrict data exposure exclusively to questions marked as public. However, due to a programming error where this boolean logic was inverted, the system effectively grants access when the condition indicates that only public questions should be shown, thereby allowing unauthenticated users to bypass restrictions designed to hide sensitive content from general view.

From a technical perspective, the exploitation vector involves sending standard HTTP GET requests to the /api/v4.0/open-questions endpoint without providing any authentication credentials or valid session tokens. Because the underlying code logic fails to correctly evaluate the visibility status of the questions being queried, the API returns data that should have been filtered out by the security controls. This includes not only moderation-related internal notes but also usernames associated with these hidden queries. The inversion of the check means that instead of filtering out non-public items, the system inadvertently exposes them, creating a direct path for information leakage through standard web traffic without requiring any form of user interaction or privilege escalation beyond basic network connectivity to the target server.

The operational impact of this vulnerability is significant as it leads to unauthorized information disclosure, potentially compromising both privacy and internal moderation processes. The exposure of usernames associated with hidden questions can facilitate targeted social engineering attacks against support staff or community moderators. Furthermore, revealing internal moderation notes provides attackers with insight into how the organization handles sensitive issues, which could be leveraged for further reconnaissance or to identify weaknesses in their security posture. This aligns directly with CWE-200, which categorizes this type of flaw as an Information Exposure vulnerability where sensitive information is accessible to unauthorized actors. It also maps to ATT&CK technique T1537, specifically the sub-technique of Communication Through Domain Subdomains or API endpoints if applicable, but more accurately fits within general data exfiltration patterns via insecure APIs.

Mitigation strategies for this issue require immediate patching to version 4.2.0-beta or later where the logic error in OpenQuestionController has been corrected. Until an update is applied, administrators should consider implementing network-level controls such as Web Application Firewall rules that restrict access to the /api/v4.0/open-questions endpoint based on IP reputation or require additional authentication headers if feasible within their infrastructure constraints. Additionally, a thorough audit of other API endpoints for similar inverted boolean logic errors in access control checks is recommended to prevent analogous vulnerabilities from existing elsewhere in the application codebase. Regular security testing and static analysis tools configured to detect improper authorization checks can help identify such logical flaws before they are deployed into production environments.

Responsible

VulnCheck

Reservation

10/17/2026

Disclosure

10/17/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!