phpMyFAQ CVE-2026-109573

Exploitation requires the backend database (MySQL or MariaDB) to be running in NO_BACKSLASH_ESCAPES SQL mode - this is the explicit, non-default prerequisite that makes PdoMysql::escape()'s backslash-based quote escaping ineffective, and it is reflected as AT:P/AC:H in the CVSS vector. The specific entry point is the search parameter of the api/autocomplete endpoint, and the payload must use a Unicode right single quotation mark (U+2019) that the application later normalizes to an ASCII single quote, bypassing the escaping that already executed. No authentication and no user interaction are needed (PR:N/UI:N), so deployments meeting the SQL-mode condition are exposed to unauthenticated remote attackers. The primary limiting factor is the SQL mode: instances using the default MySQL/MariaDB configuration (where backslash escaping is honored) are not exploitable via this path.

This is a genuine high-priority issue, not merely a high-CVSS artifact, but with an important caveat embedded in the CVSS 4.0 vector itself. The vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H scores 9.2 because it combines network reach, no authentication (PR:N), no user interaction, and full high impact to confidentiality, integrity, and availability (read credentials, modify records, drop tables) via classic SQL injection (CWE-89). However, the elevated attack complexity (AC:H) and the explicit attack requirement (AT:P) are the decisive risk modulators: exploitation only works when the backend MySQL/MariaDB instance runs in NO_BACKSLASH_ESCAPES SQL mode, which is NOT the default configuration. No EPSS score was provided in the input, so exploitation probability cannot be quantified. The vulnerability is NOT listed in CISA KEV, and no public exploit code is referenced in the provided sources (only a GitHub Security Advisory and a VulnCheck advisory, which are disclosure records, not exploit releases). Signals are therefore consistent rather than conflicting: a real, serious unauthenticated SQLi gated by a non-default database mode, disclosed by a reputable finder (VulnCheck) but without confirmed active exploitation. Treat as high priority to patch for any phpMyFAQ deployment, with triage weighting toward instances whose database runs in NO_BACKSLASH_ESCAPES mode.

An unauthenticated attacker sends an HTTP request to the public api/autocomplete endpoint with a Unicode right single quotation mark (U+2019) in the search parameter; the application normalizes this to an ASCII single quote after the flawed backslash-based escaping in PdoMysql::escape() has already run, so the quote breaks out of the SQL string literal. Because the backend runs in NO_BACKSLASH_ESCAPES mode, the escaping backslashes are treated literally rather than as escapes, allowing the injected quote to terminate the query and append attacker-controlled SQL to read stored credentials and configuration secrets, alter records, or drop tables. No public exploit code is identified in the provided sources, but the disclosure describes the technique in actionable detail.