CVE-2026-75918: phpMyFAQ Auth Bypass Vulnerability

CVE-2026-75918 Overview

CVE-2026-75918 is an information disclosure vulnerability in phpMyFAQ versions before 4.1.7. The application writes password reset tokens to a tracking file that is served from a publicly accessible directory when user tracking is enabled. Unauthenticated attackers can request the file at content/core/data/trackingDDMMYYYY, extract reset tokens, and replay them against the password reset endpoint to hijack arbitrary user accounts, including administrative ones. The flaw is classified under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.

Critical Impact
Unauthenticated attackers can take over any phpMyFAQ account, including administrators, by harvesting password reset tokens from a world-readable tracking file.

Affected Products

phpMyFAQ versions prior to 4.1.7
Deployments with user tracking enabled
Web-facing installations where content/core/data/ is served by the HTTP daemon

Discovery Timeline

2026-08-19 - CVE-2026-75918 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-75918

Vulnerability Analysis

phpMyFAQ ships an optional user-tracking feature that records request metadata into a dated log file under content/core/data/trackingDDMMYYYY. The tracking logic captures request parameters, and when the password reset workflow fires, the generated reset token traverses the same request pipeline. The token is written verbatim into the tracking file alongside session and request context.

Because the tracking file resides inside a directory that is reachable over HTTP, any unauthenticated client can request it directly. An attacker triggers a password reset for a target account, waits for the request to be logged, and then downloads the tracking file to read the token. Replaying the token against the password reset confirmation API completes the account takeover without ever interacting with the victim's mailbox.

Root Cause

The root cause is twofold. First, sensitive authentication material is logged as part of routine request tracing, violating the principle that secrets should never be persisted in plaintext logs. Second, the logging destination lives inside the document root and lacks web server access controls, so the confidentiality boundary of the file is effectively public.

Attack Vector

The attack is remote and unauthenticated. The adversary submits a password reset request for victim@example.com through the standard forgot-password form. Immediately afterward, the attacker issues an HTTP GET to /content/core/data/tracking<DDMMYYYY> and parses the response for the token query parameter associated with the victim. The attacker then calls the reset confirmation endpoint with the stolen token and a new password, gaining full control of the account.

No verified public exploit is currently indexed, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. See the GitHub Security Advisory GHSA-j5w2-cwwj-xj7x and the VulnCheck advisory for further technical detail.

Detection Methods for CVE-2026-75918

Indicators of Compromise

HTTP GET requests to /content/core/data/tracking followed by an eight-digit date string, especially from external IP addresses.
Password reset requests immediately followed by successful password change events for the same account from a different IP or user agent.
Presence of readable trackingDDMMYYYY files containing token= query parameters or reset URLs.

Detection Strategies

Alert on any web access log entry matching the path pattern content/core/data/tracking* from non-administrative sources.
Correlate /admin/password-reset or /api/v3.0/user/password/reset API calls with recent reads of the tracking file within a short time window.
Baseline legitimate administrative access to the content/core/data/ directory and flag deviations.

Monitoring Recommendations

Forward phpMyFAQ web server access logs to a centralized logging pipeline for retention and query.
Monitor account takeover indicators such as password changes, email address changes, and privilege modifications closely following unauthenticated file reads.
Track failed and successful reset token submissions to identify replay behavior against multiple accounts.

How to Mitigate CVE-2026-75918

Immediate Actions Required

Upgrade phpMyFAQ to version 4.1.7 or later as the primary remediation.
Disable user tracking in the phpMyFAQ administration panel until the upgrade is complete.
Delete or move existing content/core/data/trackingDDMMYYYY files from the document root and audit them for exposed tokens.
Force password resets and invalidate active sessions for all accounts if the tracking files may have been accessed externally.

Patch Information

The phpMyFAQ project addressed the issue in version 4.1.7. Details are published in the GitHub Security Advisory GHSA-j5w2-cwwj-xj7x. Administrators should verify their deployed version with git describe or by inspecting the version constant, and apply the upgrade through the standard phpMyFAQ update process.

Workarounds

Block HTTP access to the content/core/data/ directory at the web server or reverse proxy layer.
Turn off the user tracking feature in the phpMyFAQ configuration until patching is possible.
Restrict access to phpMyFAQ administrative and reset endpoints by source IP where operationally feasible.

bash

# Apache: deny public access to the tracking directory
<Directory "/var/www/phpmyfaq/content/core/data">
    Require all denied
</Directory>

# nginx: block access to tracking files
location ~ ^/content/core/data/tracking[0-9]{8}$ {
    deny all;
    return 404;
}