CVE-2026-76212

phpMyFAQ versions before 4.1.7 mishandle LIKE wildcard escaping in its PostgreSQL search backend when the installation uses the native pgsql PHP extension: Search/Database/Pgsql.php declares '=' as the LIKE ESCAPE character while escapeLikeWildcards() prefixes user input with '|', making the escaping a no-op. As a result, user-supplied % and _ characters remain active LIKE wildcards, and an unauthenticated attacker can submit them via the public FAQ search form to force maximally broad pattern matches and expensive sequential database scans, exhausting resources and causing a denial of service. Quotes remain correctly escaped, so the flaw cannot be leveraged for quote-breaking SQL injection or data exfiltration; the impact is limited to availability. Only deployments running PostgreSQL through the native pgsql extension are affected — the PDO PostgreSQL backend is not vulnerable. No in-the-wild exploitation is reported; a public advisory with a PoC reference exists (GHSA-5hx6-c293-588h), EPSS estimates only a ~0.3% chance of exploitation within 30 days, and the issue is not in CISA KEV.

What to do: Upgrade to phpMyFAQ 4.1.7 or later, which corrects the LIKE ESCAPE character handling in the Pgsql.php backend. If upgrading immediately is not possible, switch the database backend from the native pgsql extension to the unaffected PDO PostgreSQL driver, or mitigate by rate-limiting the public FAQ search endpoint and filtering % and _ from user-supplied search terms. Administrators should verify which PostgreSQL driver their installation uses (native Pgsql.php vs PDO), since PDO-based deployments are not affected.