External risk intelligence

phpMyFAQ SQL Injection via Autocomplete Search

CVE advisorySeverity: CRITICAL (CVSS 9.2)

CVE-2026-109573

phpMyFAQ is a web application designed to be public-facing to serve help content and FAQs to users. The vulnerability exists in an API endpoint used for autocomplete functionality, which is a standard feature exposed to internet users in typical deployments of this software.

SQL Injection

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a critical SQL injection vulnerability found in phpMyFAQ software. Attackers can exploit this flaw to access sensitive credentials, alter records, or delete data by submitting specially crafted input through a search parameter. The primary concern is to determine if this technology is in use and confirm any potential exposure.

SQL injection in helpdesk search.
Allows access to credentials and data.
Confirm relevance and exposure.

Attack Path

How an attacker could exploit the issue

An unauthenticated attacker can target a web application's search feature to inject malicious SQL code. This occurs when the application's search parameter, specifically within the `api/autocomplete` endpoint, is processed without proper sanitization, allowing the attacker to send specially crafted input that manipulates database queries. When the backend database is configured in a specific mode (NO_BACKSLASH_ESCAPES), the injected input can lead to unauthorized access to sensitive data, modification of records, or even deletion of database tables.

No authentication required.
Input in search parameter.
Read, modify, or delete data.

Live Threat

Current exploitation, exposure, and threat context

When MySQL or MariaDB is configured with `NO_BACKSLASH_ESCAPES`, an unauthenticated attacker could send a specially crafted Unicode character in the search parameter of the `api/autocomplete` endpoint. This could allow the attacker to read sensitive system credentials and configuration secrets, alter or delete database records, or even drop entire tables.

Database credentials and configuration secrets.
Via search parameter in `api/autocomplete`.
Read, modify, or delete database records.

Operational Fix

Recommended remediation, mitigation, and detection steps

This SQL injection vulnerability in phpMyFAQ affects the search functionality, potentially exposing sensitive data. Application owners are responsible for identifying deployments of phpMyFAQ and assessing the risk based on reachability and business criticality. The first step involves confirming the presence of the affected software, determining its exposure, and then planning remediation or mitigation strategies.

Application owners should take ownership.
Verify unpatched phpMyFAQ instances.
Plan remediation based on risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is phpMyFAQ?

phpMyFAQ is a popular open-source software platform used to build and manage frequently asked question systems. It provides a searchable interface that organizations use to host help content, documentation, and support articles for their users or customers.

How does this SQL injection vulnerability work in CVE-2026-109573?

The flaw is a weakness in how the software handles specific input, classified as CWE-89 (SQL Injection). The PdoMysql::escape() function incorrectly handles certain Unicode characters when the database is in a specific mode. This allows an attacker to break out of the intended query structure, letting them execute unauthorized commands directly against the database.

Does this issue happen every time someone uses the search feature?

No. The vulnerability only triggers when the backend MySQL or MariaDB database is specifically configured with the NO_BACKSLASH_ESCAPES mode enabled. If the database is using standard escaping settings, the specific Unicode character manipulation that leads to this flaw is not effective.

Why is this CVE considered relevant for my organization?

According to Halo Surface Signal, phpMyFAQ is designed to be public-facing to serve content, meaning it is often directly accessible from the internet. Because the vulnerability exists in an API endpoint used for autocomplete, an unauthenticated attacker could potentially reach this flaw without needing any prior system access or credentials.

What steps should I take if I am running phpMyFAQ?

First, verify if you are running a version earlier than 4.1.9. If you are, check your database configuration to see if NO_BACKSLASH_ESCAPES is active. Prioritize updating your software to version 4.1.9 or later, as this is the standard way to resolve the underlying code defect responsible for the vulnerability.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.