phpMyFAQ EUVD-2026-86289

Requires an authenticated administrator account with access to the phpMyFAQ stop-word management feature (the code path invoking StopWords::add()) on any version prior to 4.1.6. The flaw is isolated to the add()/INSERT path - the update() path is not vulnerable because it correctly escapes input. Limiting factors: administrative privilege is mandatory (PR:H), so exposure is confined to trusted operators or compromised admin sessions; there is no unauthenticated or low-privilege path, and no user interaction by a victim is needed. Default configurations are affected once an admin can reach the stop-word UI.

This is a real but moderate-priority issue whose severity is bounded by its authentication requirement. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N, vendor score 8.5) confirms network reachability with no user interaction, but PR:H means only an authenticated administrator who can reach the stop-word management feature can exploit it - the description and the vector agree on this, so there is no source conflict on the access model. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so exploitation is 'no public exploit identified at time of analysis' - this is not a mass-exploitation candidate. The high vendor score is driven by the CIA impact (arbitrary SQL: DROP TABLE, data exfiltration, row modification), not by ease of access. A key nuance: because the attacker must already be an application administrator, much of the injected capability overlaps with privileges the account already holds, which is why the real-world urgency is lower than an 8.5 unauthenticated SQLi would imply. The vendor rated VA:N (no availability impact), which conflicts with the description's explicit mention of dropping tables - that omission is worth verifying, as DROP TABLE is a clear availability impact. Priority: patch during normal maintenance; not an emergency unless admin accounts are shared, weakly protected, or exposed to lower-trust operators.

An authenticated phpMyFAQ administrator (or an attacker who has phished/compromised an admin session) navigates to the stop-word management feature and submits a crafted 'word' value such as "test', 'en'); DROP TABLE faqstopwords; --" that breaks out of the SQL string literal in the unescaped sprintf-built INSERT. The injected SQL executes with the application's database privileges, allowing table drops, data exfiltration, or modification of other rows. No public exploit code was provided, but the vendor's own regression test embeds a working DROP TABLE payload, illustrating exact exploitation.