Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-19T14:17:46.807Z",
  "pubdate": "2026-08-19T14:17:46.807Z",
  "executiveSummary": "This vulnerability is an improper wildcard neutralization flaw affecting phpMyFAQ before version 4.1.7 when explicitly configured to utilize the native pgsql PHP extension for PostgreSQL database interactions.\nThe security deficiency resides in the Search/Database/Pgsql.php backend, where an incorrect SQL LIKE ESCAPE character ('=') is declared while the escapeLikeWildcards() function prepends the '|' character to user-supplied input.\nConsequently, the wildcard escaping mechanism becomes a complete no-op, allowing unauthenticated threat actors to supply literal SQL wildcard characters such as '%' and '_' directly into the public-facing FAQ search form.\nThe primary security impact is a localized Denial of Service (DoS). By injecting unescaped wildcard characters, an attacker forces the PostgreSQL database engine to execute maximally broad pattern matches that trigger expensive sequential table scans.\nThis excessive resource consumption degrades application availability and can exhaust database server resources.\nThe vulnerability requires no authentication or special privileges to exploit, operating over public network exposure.\nIt is important to note that the PDO PostgreSQL backend is completely unaffected by this flaw, and string quoting mechanisms remain functional, preventing quote-breaking SQL injection or unauthorized data exfiltration.",
  "technicalDetails": "The vulnerability stems from a mismatch between the escape character declaration and the escaping logic implemented within the PostgreSQL database backend of phpMyFAQ.\nSpecifically, the vulnerable component is located in the file Search/Database/Pgsql.php, which handles search queries when the native pgsql PHP extension is engaged.\nDuring database query construction, the backend specifies an incorrect LIKE ESCAPE character, defining it as '='. However, the accompanying escapeLikeWildcards() method sanitizes user input by prepending the '|' character as the escape prefix.\nBecause the declared database escape character does not match the actual escape character utilized by the sanitization routine, the database engine fails to interpret '|' as a valid escape sequence for SQL LIKE pattern matching operators.\nAs a result of this parsing discrepancy, the wildcard escaping mechanism effectively becomes a no-op.\nUser-supplied input containing percent signs (%) and underscores (_) bypasses neutralization and reaches the database query layer as active SQL LIKE wildcards.\nAn unauthenticated, remote attacker exploits this behavior by submitting specially crafted search queries containing dense or broad wildcard patterns via the public FAQ search form.\nWhen the native pgsql driver executes the resulting query, PostgreSQL interprets the unescaped wildcards as broad matching directives rather than literal string characters.\nThis forces the database optimizer to abandon efficient index scans in favor of expensive, resource-intensive sequential scans across entire database tables.\nRepeated submission of these payloads by an unauthenticated adversary consumes excessive CPU and I/O resources on the database server, culminating in a Denial of Service condition for legitimate users.\nThe affected versions include all phpMyFAQ installations prior to version 4.1.7 utilizing the native pgsql PHP extension.\nNo pre-existing authentication, specific user privileges, or complex post-exploitation payloads are required, as the attack vector relies solely on manipulating input processed by the public search interface."
}