phpMyFAQ CVE-2026-111895

Exploitation requires that the phpMyFAQ instance has Microsoft Entra ID (Azure AD) login configured and enabled, and that the attacker controls or can create an identity within that same configured tenant whose mutable preferred_username claim exactly matches an existing local phpMyFAQ account (e.g., a super-admin username). The flaw is in AuthEntraId::create() ignoring the duplicate-login exception and continuing with the pre-existing local account. Limiting factors: instances without Entra ID SSO are not affected; the attacker must already possess valid tenant access (PR:L) and achieve a username match, and the CVSS AC:H/AT:P reflect this non-trivial precondition. Only versions 3.2.0-<4.0.0 and 4.0.2-<4.2.0-beta are vulnerable.

This is a real but conditional priority rather than a drop-everything emergency. The input CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N) scores 7.6 (High) and is internally consistent with the description: network-reachable, but with high attack complexity (AC:H) and a present attack requirement (AT:P) because the attacker must already hold a valid identity in the configured Entra tenant and that identity's preferred_username must match a target local account - hence PR:L (the attacker is an authenticated tenant user), not PR:N. Impact is severe where exploitable: VC:H/VI:H reflect full takeover of a local account up to super-admin, with no direct availability impact (VA:N) and no scope change to other systems (SC/SI/SA:N). Weighed against exploitation signals, the picture is far less alarming: there is no CISA KEV listing and no EPSS score supplied, and no public proof-of-concept is referenced, so this is 'no public exploit identified at time of analysis.' Discovery and reporting are credited to VulnCheck via a coordinated GitHub Security Advisory, indicating responsible disclosure rather than observed in-the-wild abuse. Net: a credible privilege-escalation/account-takeover flaw that matters greatly to the subset of phpMyFAQ operators using Entra ID SSO, but the preconditions (tenant access plus username match) and absence of exploitation evidence keep real-world urgency moderate. No major signal conflict exists; the main caveat is that EPSS/KEV data were simply not provided rather than confirmed absent.

An attacker who can provision or control a user in the organization's configured Microsoft Entra ID tenant sets or obtains a preferred_username value that matches an existing phpMyFAQ local account - for example a super-admin's username. They log in through the Entra ID SSO flow; because phpMyFAQ links accounts by the mutable preferred_username claim and AuthEntraId::create() swallows the duplicate-login exception while proceeding with the existing local account, the attacker is authenticated as that victim account. No public exploit code is referenced, so exploitation would require manual crafting of the tenant identity.