CVE-2026-76212 in phpMyFAQ
Summary
by MITRE • 08/19/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in phpMyFAQ versions prior to 4.1.7 represents a critical input validation failure within the application's search functionality when utilizing the PostgreSQL database backend via the native pgsql PHP extension. The core technical flaw stems from an incorrect configuration of the LIKE operator escape character. Specifically, the Search/Database/Pgsql.php module declares '=' as the escape character for pattern matching operations. However, the function responsible for sanitizing user input, escapeLikeWildcards(), incorrectly prefixes wildcard characters with '|' instead of adhering to the declared escape sequence. This discrepancy creates a logic error where the database engine does not recognize the pipe symbol as an escape mechanism because it is looking for the equals sign. Consequently, any percent signs or underscores submitted by users are treated as active wildcards rather than literal characters, effectively bypassing the intended input sanitization layer.
This misconfiguration leads to severe operational impacts primarily centered around resource exhaustion and denial of service conditions. When a user submits search queries containing wildcard characters such as '%' or '_', these characters trigger broad pattern matches across the database tables. Instead of performing targeted lookups based on specific keywords, the database engine is forced to execute sequential scans over large datasets to find any record that loosely matches the pattern. These expensive operations consume significant CPU and I/O resources, potentially degrading performance for all users or causing the service to become unresponsive entirely. The vulnerability allows an unauthenticated attacker to exploit this behavior through the public FAQ search form without requiring valid credentials, making it a remote vector for attack.
From a security classification perspective, this issue aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command or SQL Query, specifically regarding the injection of wildcard characters that alter query execution plans. It also relates to CWE-201 Information Exposure Through Denial of Service, as the primary impact is the degradation of service availability rather than data confidentiality. In terms of adversary tactics, this vulnerability can be leveraged within the MITRE ATT&CK framework under techniques associated with Resource Hijacking or Impactful actions that disrupt system availability. The attacker effectively uses a low-complexity input to force high-cost database operations, creating a denial-of-service condition through logical exploitation rather than brute-force methods.
It is important to note that this vulnerability is specific to the native pgsql backend and does not affect the PDO PostgreSQL implementation used in other configurations of phpMyFAQ. The PDO backend correctly handles quote escaping and wildcard processing, thereby preventing both the denial of service scenario and any potential SQL injection attacks. Furthermore, because quotes remain properly escaped in the affected code path, this flaw does not enable attackers to break out of string literals or exfiltrate sensitive data through standard SQL injection techniques. The risk is strictly limited to availability disruption via inefficient query execution plans triggered by wildcard characters.
To mitigate this vulnerability, organizations running phpMyFAQ versions earlier than 4.1.7 with the native pgsql extension should upgrade immediately to version 4.1.7 or later where the escape character logic has been corrected. For environments that cannot update immediately due to compatibility constraints, applying a web application firewall rule to block requests containing unescaped wildcard characters in search parameters can provide temporary relief. Additionally, implementing rate limiting on the public FAQ search endpoint can help mitigate the impact of repeated exploitation attempts by restricting the frequency at which expensive queries are executed from single IP addresses or user sessions. Regular monitoring of database query logs for unusually long-running sequential scans can also aid in detecting active exploitation attempts before they cause significant service degradation.