Safeguard
Vulnerability Analysis•

CVE-2026-111911: phpMyFAQ WebAuthn Passkey Authentication Bypass

CVE-2026-111911 lets attackers add a passkey to any phpMyFAQ account and bypass passwords and TOTP. Update to phpMyFAQ 4.1.9 and audit registered passkeys.

Safeguard Security Team
4 min read

CVE-2026-111911 is an authentication bypass (CWE-287) in phpMyFAQ 4.0.0 before 4.1.9, scored 9.8 critical. The WebAuthn registration endpoints attach a passkey to any account without authentication. That bypasses passwords and TOTP. Update to phpMyFAQ 4.1.9 and review every registered passkey on your accounts.

What's affected

phpMyFAQ 4.0.0 through 4.1.8, per the CVE record and the GitHub advisory. The fixed version is 4.1.9, and the Composer package is phpmyfaq/phpmyfaq.

The advisory says it verified the flaw against 4.1.8 and against the development branch at the time. It dates the WebAuthn feature to September 2024 and says earlier releases with the same code are likely affected but were not individually verified.

One condition limits exposure. The advisory says the attack needs the setting security.enableWebAuthnSupport to be on, which is not the default and needs an administrator to switch it on. If your instance never enabled WebAuthn, the attack path in the advisory does not apply, though the upgrade is still the right move.

The attacker also needs to know a target username. The advisory notes that usernames often appear in public FAQ content, and that admin is a common choice.

How to check if you're exposed

Check the installed version. With Composer:

composer show phpmyfaq/phpmyfaq

If you installed from a release archive, read the version on the admin dashboard or in the project version file and compare it with 4.1.9.

Then check the WebAuthn setting in the admin configuration under security, and see whether passkey login is on. If it is off, note that in your records, but still plan the upgrade.

Finally, review the registered passkeys. The advisory says an injected passkey survives password changes, so changing a password does not remove it. Look at the credential list per account, especially for administrators, and remove any key that the owner does not recognize. Check the web server logs for POST requests to the WebAuthn prepare and register paths from unfamiliar clients.

You can also run the free in-browser dependency scan or browse the Gold directory to see where a package or product shows up in your stack.

What to do now

  1. Upgrade phpMyFAQ to 4.1.9 or later.
  2. If you cannot upgrade immediately, turn off WebAuthn support in the configuration, since the advisory lists it as a precondition.
  3. Review the registered passkeys on every account, starting with administrators, and remove any that the owners did not register.
  4. Check access logs for requests to the WebAuthn register and login paths that do not match your users, and review admin activity logs for the same period.
  5. If you find a rogue passkey, reset the account, rotate any secrets held in the admin panel and check content and settings for changes.
  6. After the upgrade, confirm that registering a passkey needs a logged in session.

Why it matters

Adding a login credential to an account is a sensitive action. A system must check that the person asking owns the account, and that the request answers a challenge the server issued. The advisory says phpMyFAQ did neither on these endpoints, so an outsider could stage a victim username into their own session and register a key that the server then trusted. The weakness is CWE-287, improper authentication.

Two details raise the stakes. The advisory says the attacker's passkey stays bound to the account until someone removes it, and that the passkey login path never consults the two factor setting. So TOTP does not help, and a password reset does not clean up the damage. For an admin account, that means a silent, lasting takeover.

The record does not flag this CVE as exploited in the wild and it is not a CISA Known Exploited Vulnerability. The simple preconditions make it a good candidate for fast patching, and the advisory suggests the lasting fix: require a logged in session that owns the target account before registration.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Am I affected if I never turned on WebAuthn?

The advisory lists WebAuthn support as a non-default precondition for the attack it verified. Upgrade anyway, since it is a critical fix, and confirm the setting in your configuration.

Does changing the admin password help?

Not by itself. The advisory says an injected passkey survives password changes, so remove unrecognized passkeys as well.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.