phpMyFAQ EUVD-2026-62446

Exploitation requires an authenticated session with an account that holds glossary 'add' or 'edit' permissions in phpMyFAQ. These permissions are not granted to default end-users; they must be explicitly assigned by an administrator. The vulnerable code path is specifically the glossary create and update HTTP endpoints - other endpoints are not confirmed affected. Exploitation is not possible without valid credentials at the PR:L level. The truncation condition that enables the bypass depends on the attacker supplying input of sufficient length to be truncated at a backslash boundary, which is a crafted but low-complexity precondition. Exploitation is limited to: authenticated users only; users with explicit glossary permissions; phpMyFAQ versions strictly before 4.1.7.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) scores 8.6, reflecting low attack complexity and high data impact despite requiring low-privilege authentication. The PR:L metric is the primary limiting factor - exploitation requires an authenticated account with glossary add or edit permissions, which constrains the attacker pool to trusted or compromised internal users. No EPSS data was provided, and the vulnerability is not listed in the CISA KEV catalog, suggesting no confirmed widespread exploitation at time of analysis. No public proof-of-concept exploit has been identified. The high confidentiality and integrity impact metrics are well-founded: arbitrary SQL injection against a FAQ system's database could expose user credentials, internal content, and configuration data. Real-world risk is moderate to high for deployments with untrusted glossary editors or exposed admin portals, but lower for tightly controlled single-tenant deployments.

An attacker with a low-privileged account that has glossary add or edit permissions sends a crafted POST request to the glossary create or update endpoint, embedding a value designed to be truncated such that a backslash appears at the end of the escaped string. The dangling backslash escapes the closing SQL quote, allowing the attacker to append arbitrary SQL clauses - for example, a UNION SELECT to extract password hashes, API keys, or other sensitive rows from the database. No public exploit code has been identified, but the technique (truncation-breaking escaping) is well-documented and reproducible by an attacker familiar with SQL injection methodology.