Vanus and phpMyFAQ: a Hard-Coded Admin Token and Passkeys Anyone Can Register (CVE-2026-111998, CVE-2026-111911)

Two self-hosted open source projects picked up a 9.8 CVE over the weekend: phpMyFAQ, published in NVD on October 17, 2026, and Vanus, published on October 18.

Both lead to unauthenticated takeover, but from opposite directions. Vanus ships the same admin secret in every install — about as old a mistake as it gets. phpMyFAQ added a modern security feature, WebAuthn passkeys, and it's the implementation of that feature that lets attackers in.

Both: CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and CVSS 4.0 9.3, published by VulnCheck (CNA), not by NVD. NVD status: "Received" for Vanus, "Deferred" for phpMyFAQ. Neither is in CISA KEV at the time of writing.

Vanus — CVE-2026-111998: Cluster-Admin for Anyone

Vanus is an event platform (event buses, namespaces, users and roles). According to NVD's description, versions 0.8.0 through 0.9.0 contain a hard-coded admin token. Sending it as a Bearer token to the gateway's gRPC proxy port grants cluster-admin rights with no authentication.

With those rights, an attacker can manage namespaces, event buses, users, tokens and role bindings, and read or publish events. On an event bus, that last part is the one that matters most: reading means seeing your business data go by; publishing means injecting messages that downstream consumers will treat as legitimate.

NVD's references point to the v0.9.0 source (the relevant constant and tenant controller), the project's GitHub issue #647 and the VulnCheck advisory. NVD lists no fixed version: check the issue and the advisory before assuming an upgrade solves it.

phpMyFAQ — CVE-2026-111911: Registering a Passkey on Someone Else's Account

phpMyFAQ is a PHP FAQ and knowledge base application. According to NVD's description, from 4.0.0 and before 4.1.9, the WebAuthn registration endpoints attach a passkey to any account, with no authentication and no challenge validation.

The described attack:

1. the attacker stages the victim's username;
2. they submit a forged none attestation (fmt=none) to register their own passkey on that account;
3. they log in with that passkey, bypassing both the password and TOTP.

That's the irony here: two-factor authentication is bypassed by the very mechanism meant to strengthen it. The none attestation format is legitimate in WebAuthn; the problem described is that registration requires neither an authenticated session nor a valid challenge.

Going by the "before 4.1.9" wording, 4.1.9 is the first version outside the described range. NVD provides no CPE configuration, so confirm the fixed release in the two project GitHub advisories NVD references (GHSA-g6cq-6rqg-6c9p and GHSA-rg9h-f29v-xhxr).

Two CVEs CPE Matching Won't Catch

Neither entry has a CPE configuration. phpMyFAQ is "Deferred": NVD has decided not to enrich it, so it won't get one. Vanus is "Received": nothing suggests one is coming soon.

It's the same blind spot described in our article on LangChat, DataBuff and Simple Admin Core: a tool that matches CVEs to your assets by CPE alone will never surface either of these.

Detection

• Vanus: connections to the gateway's gRPC proxy port from outside your application network; users, tokens or role bindings you didn't create; events published by unknown producers.
• phpMyFAQ: the passkeys registered on each account — any passkey the user didn't add themselves, especially on admin accounts; anonymous requests to the WebAuthn registration endpoints in reverse proxy logs.

Mitigation

1. phpMyFAQ: upgrade to a version outside the affected range following the GitHub advisories, then audit and remove suspicious passkeys — a passkey an attacker registered stays valid after the upgrade.
2. Vanus: keep the gateway's gRPC proxy port off anything but your application network, and follow issue #647 and the VulnCheck advisory for the fix.
3. If exposed: treat what the application holds as compromised — Vanus tokens, phpMyFAQ accounts and content — and rotate secrets.
4. More broadly, don't put the admin surface of a self-hosted application straight on the internet: use a VPN or an authenticated reverse proxy.

Why Continuous Monitoring of Your Self-Hosted Applications Matters

Two critical flaws, published over a weekend, with no CPE: exactly the kind of CVE that slips under the radar. For self-hosted open source, monitoring has to look for the product name in the description, not just the CPE identifier.

With cveo.tech, add Vanus, phpMyFAQ and your other applications to your inventory: monitoring combines CPE matching with product-name search, and alerts you by email or webhook.