The vulnerability CVE-2026-34973 affects phpMyFAQ, an open source FAQ web application, specifically versions earlier than 4.1.1. The root cause lies in the searchCustomPages() method within the Search.php file, which sanitizes user-supplied search terms using the real_escape_string() function. While this function escapes certain SQL injection vectors, it does not escape the SQL LIKE clause metacharacters '%' (which matches any sequence of characters) and '_' (which matches any single character). Consequently, an attacker can craft search inputs containing these wildcards to manipulate the LIKE clause logic, causing the database to return records beyond the intended scope. This leads to unauthorized information disclosure by surfacing content that should remain hidden. The vulnerability requires no authentication or user interaction, making it remotely exploitable by any attacker with access to the search functionality. The issue is categorized under CWE-943, which concerns improper neutralization of special elements in data query logic. The vulnerability has a CVSS 4.0 base score of 6.9 (medium severity), reflecting its moderate impact on confidentiality without affecting integrity or availability. The vendor addressed this flaw in phpMyFAQ version 4.1.1 by properly handling the escaping of SQL LIKE metacharacters in search inputs. No public exploits have been reported to date, but the vulnerability poses a risk to any deployment running outdated versions of phpMyFAQ.

This vulnerability primarily impacts the confidentiality of data stored or indexed by phpMyFAQ instances. By exploiting the improper escaping of SQL LIKE wildcards, attackers can retrieve FAQ content or other sensitive information that was not intended to be accessible via search queries. This could lead to leakage of internal knowledge bases, proprietary information, or user data depending on how phpMyFAQ is used within an organization. Since the vulnerability does not affect data integrity or availability, the risk is limited to unauthorized information disclosure. However, the fact that exploitation requires no authentication and no user interaction increases the attack surface significantly, especially for publicly accessible phpMyFAQ installations. Organizations relying on phpMyFAQ for internal or external knowledge management should be aware that attackers could leverage this flaw to gain insights into confidential information, potentially aiding further attacks or social engineering. The absence of known exploits reduces immediate risk but does not eliminate it, as automated scanning and exploitation could emerge. Overall, the impact is moderate but meaningful for organizations with sensitive content in phpMyFAQ.

The primary and most effective mitigation is to upgrade phpMyFAQ to version 4.1.1 or later, where this vulnerability has been patched by correctly escaping SQL LIKE metacharacters in search inputs. For organizations unable to upgrade immediately, temporary mitigations include implementing web application firewall (WAF) rules to detect and block search queries containing suspicious SQL LIKE wildcard patterns such as '%' and '_'. Additionally, restricting access to the phpMyFAQ search functionality to trusted networks or authenticated users can reduce exposure. Reviewing and limiting the amount of sensitive information indexed or accessible via phpMyFAQ can also minimize potential data leakage. Developers maintaining custom integrations or forks of phpMyFAQ should audit their code for similar improper escaping issues in SQL LIKE clauses. Regular monitoring of logs for unusual search patterns and applying principle of least privilege to database accounts used by phpMyFAQ can further reduce risk. Finally, organizations should maintain an inventory of phpMyFAQ versions deployed and ensure timely patch management processes.