phpMyFAQ CVE-2026-76214

The target deployment must have WebAuthn/passkey authentication enabled and actively used by at least one account (versions <= 4.1.5). The attacker must first capture a complete, successful WebAuthn assertion for the victim - this is the concrete, limiting prerequisite reflected in AC:H and AT:P, and normally requires a privileged network vantage point (MITM, malicious proxy, or access to traffic/logs) since the assertion transits TLS. Once a valid assertion is captured, no further conditions apply: no hardware key, no user interaction, and no authentication of the attacker are needed to replay it indefinitely. Deployments that do not use WebAuthn logins are not exploitable via this flaw.

The impact ceiling is high - full account takeover with high confidentiality and integrity impact (VC:H/VI:H) and no privileges or user interaction required (PR:N/UI:N) - but the practical barrier is real: the CVSS 4.0 vector carries AC:H and AT:P, reflecting that the attacker must first obtain a genuine successful WebAuthn assertion for the target, which normally travels over TLS. That capture prerequisite, not a trivial network request, is what gates this bug; once an assertion is obtained (via interception, a compromised proxy/reverse proxy, logged traffic, or a malicious network position), replay is unlimited and trivial. There is no KEV listing and no POC has surfaced, and EPSS data was not provided, so this reads as a serious-but-not-yet-mass-exploited issue. Given that patching is a simple upgrade, any operator using WebAuthn logins - even a mid-sized municipal IT team in rybnik should treat this as urgent - should upgrade promptly rather than wait for exploitation signals. Note the input 'Denial Of Service' tag appears mislabeled; this is an authentication bypass, not a DoS.

An attacker positioned to observe or record a victim's traffic (for example via a malicious or misconfigured reverse proxy, captured logs, or a network foothold) collects one successful WebAuthn login assertion for an administrator. Because phpMyFAQ never persists and consumes the challenge, the attacker resubmits that same assertion to the login endpoint and is authenticated as the victim, repeatedly, without the hardware key or any user interaction. No public POC is currently identified, but the mechanism is fully described in the vendor advisory.