CVE-2026-111884: phpMyFAQ Account Takeover via Unverified Email Change

Overview

A high-severity authentication flaw has been disclosed in phpMyFAQ, the widely deployed open-source FAQ and knowledge-base platform. Tracked as CVE-2026-111884 with a CVSS 3.1 score of 8.3 (CVSS 4.0: 8.7), the vulnerability allows an attacker who has hijacked a user's session to change that account's email address — without ever supplying the account's current password.

The flaw sits in the user control panel's UserController::updateData handler and its matching API route, api/user/data/update, which govern self-service profile edits.

Technical Details

How It Works

When an authenticated user submits a request to change their account's email address through the user control panel or the api/user/data/update API endpoint, phpMyFAQ validates only two things: that a valid session cookie is present and that the request carries a correct CSRF token. It does not require the caller to re-enter the account's current password to confirm they still control the credentials.

This breaks the standard assumption that sensitive identity changes — email, password, recovery contact — require proof of continued credential knowledge, not just an active session. Any actor who manages to ride an existing session (via a hijacked cookie, an XSS payload, or a leaked session token) can immediately repoint the account's email address to an address they control.

Why It's Serious

Once the email address is changed, the attacker can trigger the standard password-reset flow against the new, attacker-controlled address. For accounts that don't have two-factor authentication enabled — including, notably, superadmin accounts — this completes a full account takeover with no further obstacles.

Impact Assessment

Who Is At Risk

Any organization running a self-hosted phpMyFAQ instance in the affected version ranges is exposed, particularly deployments where:

• Administrative or superadmin accounts do not have 2FA enabled
• Session cookies could plausibly be exposed via XSS, malware, or network-level interception
• The user control panel or REST API is reachable without additional network restrictions

Attack Chain

1. Session Compromise — Attacker obtains a valid session for a target account (session hijacking, XSS, token leakage)
2. Unverified Email Change — Attacker calls UserController::updateData / api/user/data/update to set the account's email to an address they control, supplying only the session and CSRF token
3. Password Reset Abuse — Attacker initiates the standard password-reset flow, which now delivers the reset link to the attacker's inbox
4. Full Takeover — Attacker sets a new password and gains full control of the account, including superadmin privileges if the compromised account held them

Mitigation

Immediate Actions

• Upgrade to phpMyFAQ 4.1.9 or 4.2.0-beta, both of which require the current password before an email change is accepted
• Enable two-factor authentication on all administrative and superadmin accounts — this blocks the password-reset step even if the email is changed
• Audit recent email-change events in affected instances for any changes that administrators don't recognize

Detection Opportunities

• Review application logs for updateData / api/user/data/update calls not immediately preceded by a password re-entry prompt in the UI flow
• Look for email changes on privileged accounts followed shortly by a password-reset request
• Monitor for session anomalies (IP or user-agent changes mid-session) that could indicate hijacking

Defence-in-Depth

• Enforce MFA fleet-wide, not just on admin accounts, to limit the value of a hijacked session
• Apply short session lifetimes and re-authentication prompts for sensitive profile changes generally
• Restrict the admin control panel to trusted network ranges where feasible

Discovery & Disclosure

The vulnerability was reported by VulnCheck and published around October 17, 2026, alongside related phpMyFAQ 4.2.0-alpha findings, including CVE-2026-111882 (TOTP bypass), CVE-2026-111885 (missing authorization in group deletion), and CVE-2026-111886 (lack of brute-force protection). As of publication, there is no public proof-of-concept exploit, but the low barrier to exploitation — a valid session and CSRF token are the only requirements — means patching should not wait for confirmed in-the-wild activity.

References

• NVD — CVE-2026-111884
• VulDB — CVE-2026-111884 in phpMyFAQ
• Strix — CVE-2026-111884