CVE-2026-111884 is a high severity (CVSS 8.3) flaw in phpMyFAQ. Changing an account e-mail needs no current password, so a hijacked session can lead to full takeover through password reset. The record lists fixes in 4.1.9 and 4.2.0-beta, but the GitHub advisory lists none.
What's affected
Per the record: phpMyFAQ before 4.1.9, and 4.2.0-alpha before 4.2.0-beta. The GitHub advisory I fetched gives affected versions as up to 4.2.0-alpha.2, including 4.1.8, and says patched versions are none.
Source conflict: the record says the fix is in 4.1.9 or 4.2.0-beta, while the GitHub advisory page I fetched lists patched versions as none. Check the phpMyFAQ release notes and the advisory before relying on either.
The affected code is the user control panel update handler. The record says the attacker needs a hijacked session, which makes this an escalation step after another compromise.
Scoring note: the record's 8.3 is a CVSS 3.1 base score. VulnCheck's advisory also lists 8.7 under CVSS 4.0. Both describe the same flaw, and the two versions weigh the factors differently.
How to check if you're exposed
Check your version:
composer show phpmyfaq/phpmyfaq
Then look at recent e-mail address changes on accounts, especially administrators, and at password reset mails sent right after them. A new address that the owner does not recognise is a red flag.
What to do now
- Find your phpMyFAQ version.
- Confirm in the advisories and release notes which release closes this for you.
- Upgrade to 4.1.9 or 4.2.0-beta once confirmed.
- Review recent e-mail and password changes on privileged accounts.
- Shorten session lifetimes and require HTTPS everywhere to lower the odds of session theft.
- Scan your dependencies with the free in-browser scan and look the CVE up in the Gold directory to see where else it appears.
Keep a record of what you checked and what you changed. Note the version found, the date, the action taken and who approved it. If the advisory is later updated, for example with a fixed release, you will know which systems need another pass, and an auditor or a colleague can follow your reasoning.
Why it matters
This is CWE-308, use of single-factor authentication for a sensitive action. Changing the password or turning off two-factor asks for the current password. Changing the e-mail does not, and the e-mail is the root of the password reset flow. The two controls undermine each other.
The advisory says this circumvents an earlier fix that added a password check for password changes. A sound design asks for re-authentication on every change that can transfer control of the account. It is not listed in CISA KEV.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why does the e-mail matter?
Password reset links go to the e-mail on file, so whoever controls it can set a new password.
Does the attacker need a session first?
Yes. The record describes a hijacked session as the starting point.
Sources
Last reviewed: 18 October 2026.
