EUVD-2026-103316
GHSA-xmh2-49v9-xw88
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSend GET to /api/v4.0/open-questions
-
ExploitTrigger inverted onlyPublicQuestions check
-
ImpactDisclose non-public questions and usernames
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V14 - Data Protection Data exposure prevention
MITRE ATT&CK
2 techniques across 2 tactics: Collection, Discovery The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitable only against phpMyFAQ release 4.2.0-alpha (builds before 4.2.0-beta) where the OpenQuestionController contains the inverted api.onlyPublicQuestions logic; the instance must expose the /api/v4.0/open-questions REST endpoint (default in this version) and must actually contain non-public/moderation open questions for any data to be disclosed. No authentication, no user interaction, and no non-default configuration are required (AV:N/AC:L/PR:N/UI:N). The primary limiting factors are the narrow affected-version window (a single pre-release line, fixed in 4.2.0-beta) and the low sensitivity of exposed data (hidden open questions and associated usernames only). |
| Impact | This is a medium-severity information-disclosure issue (vendor/NVD CVSS 4.0 base 6.9) and the signals are largely consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms a network-reachable, low-complexity, unauthenticated flaw requiring no user interaction, which matches the description of a simple unauthenticated GET request to /api/v4.0/open-questions. However, impact is deliberately scoped low: only VC:L (limited confidentiality), with VI:N and VA:N - no integrity or availability impact and no scope change. There is no EPSS score, no CISA KEV listing, and no public exploit code referenced, so there is no public exploit identified at time of analysis; exploitation is plausible given the trivial attack mechanics but not demonstrated in the wild. Tempering real-world priority: the only affected version is a pre-release build (4.2.0-alpha before 4.2.0-beta), which sharply limits the realistic exposed population. Net assessment: a genuine but modest-priority bug - easy to trigger and unauthenticated, but low-sensitivity data (hidden open questions and associated usernames) and a tiny pre-release deployment footprint keep real-world risk well below the raw CVSS number. |
| Exploit ScenarioDerived | An unauthenticated attacker sends a crafted GET request to the /api/v4.0/open-questions endpoint of a phpMyFAQ 4.2.0-alpha instance. Because the api.onlyPublicQuestions check in OpenQuestionController is inverted, the server returns questions marked non-public (moderation/internal) along with the usernames tied to them. No public exploit code is referenced, but the attack requires only a single HTTP request against a default configuration (AV:N/AC:L/PR:N/UI:N). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 17, 2026
Unauthenticated information disclosure in phpMyFAQ 4.2.0-alpha lets remote attackers read hidden open questions and their associated usernames through the /api/v4.0/open-questions REST endpoint. An inverted api.onlyPublicQuestions check inside OpenQuestionController causes the API to return non-public moderation content instead of filtering it, which exposes internal question queues that were never meant to be public. The affected window is narrow - only pre-release 4.2.0-alpha builds before 4.2.0-beta - and 4.2.0-beta corrects the logic; no public exploit code or confirmed active exploitation was identified at time of analysis, and the impact is capped at low-confidentiality read access to moderately sensitive content.
RemediationAI
Vendor-released patch: 4.2.0-beta - upgrade any phpMyFAQ 4.2.0-alpha deployment to 4.2.0-beta or later, which corrects the inverted api.onlyPublicQuestions check in OpenQuestionController, as documented in GHSA-6xm9-p734-8fx6 (https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-6xm9-p734-8fx6). Because alpha pre-releases should not be internet-facing in production, the most reliable interim control is to block or restrict the /api/v4.0/open-questions route at the reverse proxy or web server (for example an nginx location or Apache Require rule returning 403), accepting that this breaks clients that legitimately list or submit open questions; a less disruptive alternative is to limit the entire /api/v4.0/ path to trusted source networks or authenticated administrative sessions, at the cost of disabling the public API for ordinary visitors. Purging or anonymizing any sensitive moderation-queue content and reviewing access logs for unauthenticated GETs to that endpoint will help determine whether internal questions and usernames were already harvested during the exposure window.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
phpMyFAQ is a PHP-based FAQ and knowledge-base application published by Thorsten Rienth, and the affected component is its v4.0 REST API surface (CPE cpe:2.3:a:thorsten:phpmyfaq with a wildcard version, reflecting that only the pre-release 4.2.0-alpha line is affected). The root cause is CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) arising not from injection or memory corruption but from a boolean logic inversion: the api.onlyPublicQuestions flag in OpenQuestionController, which is intended to constrain query results to publicly visible open questions, is evaluated backwards, so requests that should receive the filtered public view receive the unfiltered internal view instead. Consequently a plain GET to /api/v4.0/open-questions - an endpoint exposed by default in this version - returns moderation and internal open-question records together with the usernames attached to them. Because the defect is read-only and requires no credentials, user interaction, or non-default configuration (AV:N/AC:L/PR:N/UI:N), the assessed CVSS 3.1 vector is S:U/C:L/I:N/A:N; there is no path to data modification, denial of service, or scope change described in the available evidence.
Know when Phpmyfaq gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Single unauthenticated remote GET request (AV:N/AC:L/PR:N/UI:N); only limited confidentiality loss of hidden questions and usernames, so C:L with I:N/A:N and no scope change.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
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.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Duplicate-email registration handling in phpMyFAQ 4.0.7 through 4.0.13 (and 4.0-nightly-2025-10-03 and earlier) lets una
Insufficient Session Expiration in GitHub repository thorsten/phpmyfaq prior to 3.2.2. Rated critical severity (CVSS 9.8
Authentication Bypass by Capture-replay in GitHub repository thorsten/phpmyfaq prior to 3.1.12. Rated critical severity
Weak Password Requirements in GitHub repository thorsten/phpmyfaq prior to 3.1.12. Rated critical severity (CVSS 9.8), t
Weak Password Requirements in GitHub repository thorsten/phpmyfaq prior to 3.1.8. Rated critical severity (CVSS 9.8), th
Unauthenticated SQL injection in phpMyFAQ before 4.1.2 allows remote attackers to extract credentials, admin tokens, and
In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) in admin/stat.ratings.php. Rated high severity (CVS
In phpMyFaq before 2.9.9, there is CSRF in admin/ajax.config.php. Rated high severity (CVSS 8.8), this vulnerability is
In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) for modifying a glossary. Rated high severity (CVSS
In phpMyFAQ before 2.9.9, there is Cross-Site Request Forgery (CSRF) in admin/stat.main.php. Rated high severity (CVSS 8
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severi
phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Rated high severi
Exploit-DB