CVE-2026-76212: phpMyFAQ before 4.1.7 LIKE Wildcard Injection via PostgreSQL
phpMyFAQ before 4.1.7, when configured to use PostgreSQL via the native pgsql PHP extension, declares an incorrect LIKE ESCAPE character ('=') in the Search/Database/Pgsql.php backend while escapeLikeWildcards() escapes user input with the '|' prefix. As a result, wildcard escaping is a no-op and user-supplied % and characters remain active LIKE wildcards. An unauthenticated attacker can submit such characters in the public FAQ search form to force maximally broad pattern matches and expensive sequential scans, resulting in a denial of service. The PDO PostgreSQL backend is not affected, and quotes remain escaped so this does not enable quote-breaking SQL injection or data exfiltration.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
phpMyFAQto a version that resolves this vulnerability.Fixed in 4.1.7 - Configuration
In Search/Database/Pgsql.php, correct the declared LIKE ESCAPE character (currently incorrectly set to '=') so it matches the escapeLikeWildcards() behavior that prefixes escaped LIKE wildcards with the '|' character.
phpMyFAQ (Search/Database/Pgsql.php) LIKE ESCAPE character = '|' prefix for escaped wildcards (instead of '=' declared escape)
Event History
Frequently Asked Questions
Which deployments are affected?
Only phpMyFAQ deployments before 4.1.7 that use PostgreSQL through the native pgsql PHP extension are affected. Deployments using the PDO PostgreSQL backend are not affected.
Does exploitation require an account or special interaction?
No. An unauthenticated attacker can submit % or _ wildcard characters through the public FAQ search form; no user interaction is required.
What is the practical impact of this issue?
Active LIKE wildcards can force broad matches and expensive sequential scans, causing denial of service. The issue does not permit quote-breaking SQL injection or data exfiltration because quotes remain escaped.
What can be done before upgrading?
The provided information identifies the public FAQ search form as the attack path. Restricting or disabling public access to that search capability can reduce exposure until phpMyFAQ is upgraded to 4.1.7 or later.