phpMyFAQ CVE-2026-111887

Exploitation requires that the phpMyFAQ guest-comment feature (the comment create endpoint) be reachable and enabled, which is the typical configuration for a public-facing FAQ allowing visitor comments. The attacker submits candidate user and mail values and relies on the application returning a distinct HTTP 409 status to distinguish registered from non-registered identifiers. No authentication is required (PR:N). Limiting factors: the instance must be internet-reachable with guest commenting available, exploitation yields only confirmation of existing name/email pairs (no credential or data compromise), and its practical value depends on the number of registered users and the attacker already possessing candidate values to test.

This is a genuine but low-to-moderate priority issue, not a critical one. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms remote, unauthenticated, low-complexity exploitation with no user interaction, which explains the 6.9 (Medium) score - but the only impact is confidentiality at Low (VC:L), with no integrity or availability effect, consistent with an account-enumeration/information-disclosure weakness (CWE-204). No EPSS score was provided, the CVE is NOT in CISA KEV, and no public exploit code is referenced, so there is no public exploit identified at time of analysis. The signals are internally consistent - no conflict between the network vector and the description, which clearly describes a remote HTTP-based oracle. The realistic risk is that this flaw is a reconnaissance enabler (harvesting valid display-name/email pairs for targeted phishing) rather than a direct compromise vector, so it should be patched in routine cycles and prioritized where the FAQ instance is public-facing and holds many registered users. No SSVC decision data was supplied in the input.

An unauthenticated attacker scripts requests to the phpMyFAQ guest-comment create endpoint, submitting candidate username and email values and observing whether the server returns a distinct HTTP 409 response that confirms a registered display name or email. By iterating over wordlists or breach data, the attacker builds a validated list of real name-to-email mappings, then uses it to craft convincing targeted phishing against those users. No public proof-of-concept is referenced in the provided data.