phpMyFAQ coordinated wave: unauthenticated WebAuthn fmt=none passkey mint, mutable-claim IdP linking, readable TOTP secrets, and scope-dropping privilege APIs¶

Scan date: 2026-10-17 22:1xZ UTC · Vendor band: phpMyFAQ before 4.1.9 and 4.2.0-alpha before 4.2.0-beta · Wave: ~28 GHSAs published in one 21:31Z batch (CVE-2026-111880-adjacent range 111882–111911 minus non-phpMyFAQ IDs)

This is phpMyFAQ's largest coordinated dump (previous wave: May 31, account-takeover boundary page). The advisories are unusually descriptive — each one names the function, the missing check, and the exact request shape, which makes the batch a copy-pasteable audit checklist for any PHP FAQ/portal/CMS with delegated-admin models. The crown-jewel legs all sit on the identity lifecycle: passkey enrollment, IdP account linking, 2FA state, and admin-scope APIs.

Advisory table (legs with durable operator value)¶

Why this is worth an operator page¶

Three of the strongest legs are zero-credential account takeover paths, and two of them are grep-able classes that generalize far beyond phpMyFAQ:

1. fmt=none passkey mint on an unauthenticated registration endpoint. WebAuthn's none attestation format is a legitimate choice for enterprise fleets (no privacy leak, the Relying Party trusts its own enrollment flow). That trust assumption becomes a bypass when the enrollment handler itself has no session gate and no challenge binding: anyone can stage a username and attach their own authenticator. The login path then treats passkey possession as proof of identity — password and TOTP both skipped. Genealogy on the Sept 16 IdP page: ZITADEL authenticator enrollment on identify-only sessions (4727) and enrollment-code org-header drift (hcch) — same rule: authenticator enrollment is a credential write and must require a step-up-verified session for the target account.

2. Linking on mutable identity claims. preferred_username is editable by the user in both Entra ID and Keycloak; unverified email is attacker-chosen at registration. When an SSO callback links by claim value and the link path swallows the collision exception instead of aborting, controlling an IdP identity with the victim's name IS controlling the victim's local account. This is the GhostPat/convert-flow lineage (identity transitions are credential-carrying state machines) applied to federation: the link decision is a consent question with no consent step. Audit rule for any SSO-enabled product: (a) which claim binds the link, (b) is it mutable by the external subject, (c) is the verified flag actually read (email_verified — Pingvin/Grav/Vikunja legs), (d) what happens on collision — fail-closed or continue-with-existing?

3. TOTP secret readability by delegated admins. Same class as the Keystone qfjc/90460 delegated-token→/v3/credentials seed read folded Oct 13: a user-management API that serializes the whole row leaks the MFA seed as a side field. Seed read = MFA cloning forever, offline, no victim touch. Pair leg: removeTwofactor unlimited TOTP guessing converts a transient session hijack into a permanent 2FA strip.

Operator rules extracted¶

• Fuzz the enrollment/registration endpoints of every passkey/WebAuthn implementation unauthenticated. Three-request check on an authorized target: stage username → submit a fmt=none attestation object → attempt passkey login. Any leg that 200s without a verified session for that username is the bug. Check the server's accepted attestation-format list: none acceptance is fine only behind an authenticated, step-up-gated enrollment gate; challenge binding means the server stores what it issued, not what the client sends.
• Re-grant paths must re-restrict. Every "update rights/permissions" API that takes a list and writes it wholesale will silently widen scope if the writer normalizes away scope columns (language, category, org). Probe shape: read your own narrow-scope grants with an admin-scoped-GET you legitimately hold, re-POST them verbatim through the update endpoint, re-read. If scope fields vanished or came back unrestricted, every holder of the edit right is one request from global rights. The self-join variant (check-then-write gap between updatePermissions and updateMembers) means you never need another compromised account.
• Absent records fail open more often than present ones. isFaqAccessibleForUser() returning visible-on-missing-translation and the inverted onlyPublicQuestions boolean are the same shape: the filter's negative branch (no row / flag off / key missing) renders content instead of denying it. Battery: request every "restricted list" endpoint with (a) a header/param spelling that finds no record (wrong Accept-Language, nonexistent category), (b) the config flag in its zero/default value, (c) the filter parameter absent entirely. Compare row counts against a control request.
• Child-object routes must re-derive the parent's visibility. attachment.php honoring dlattachment while ignoring the parent FAQ's ACL is the parent-binding family (Payload duplicate-copy leg, Gitea attachment URL-repo leg w7q4). Whenever a permission name mentions the child (dlattachment, view_comment, preview), test it against a child whose parent is restricted/draft/unpublished.
• Verb-gate mismatch inventory: update-checks-delete (phpMyFAQ NEWS legs), delete-checks-edit (Nginx UI family), grant-checks-view. On any RBAC product with distinct add/edit/delete rights per content type, the matrix is small — walk it with an account holding the least-popular right per pair and hit the sibling verb.
• Single-pass denylist sanitizers are invertible. DTD entity expansion running after sanitization, and split-tag reassembly around removed tokens, are both "the filter sees a different document than the renderer does" — same page as the Sept 20 media-pipeline and Oct 6 Coraza silent-drop lessons. Test SVG uploads with: entity-indirection battery, comment/PI-injected tag splitting, CDATA boundary, and foreign-content (<math>/<svg> <style>) reparsing (SmarterMail MathML leg).
• Enumeration oracles live in error codes. The 409-on-duplicate-comment and the 403-vs-401 patterns: diff response codes across a known-good/known-absent pair on every endpoint that echoes identity input.

Validation boundaries¶

• Prove passkey-mint and IdP-linking legs only in your own disposable phpMyFAQ install with synthetic users, a lab Keycloak/Entra tenant, and attacker-owned authenticators. On live authorized engagements, limit to the unauthenticated decision-table probes (expected-code comparison) and never attach credentials to real accounts.
• TOTP-seed legs: enroll a lab user, read back the synthetic seed; never touch real users' seeds or generate codes for real accounts.
• Scope-escalation legs: use a disposable delegated-admin account, snapshot grants before/after, restore state; teardown legs (delete superadmin/group) are lab-only.
• Keep names, emails, seeds, tokens, and internal URLs out of report exports.

Cross-references¶

• Prior phpMyFAQ wave: May 31 account-takeover boundary page (tokenless reset + admin overwrite IDOR — this wave supersedes the model: identity lifecycle is now the attack surface).
• Enrollment-on-unverified-session + enrollment-code scope drift: Sept 16 IdP authority page.
• Mutable/unverified-claim linking lineage: GhostPat (Oct 13 page), Pingvin Share email_verified-unchecked (Sept 16 page), Grav derived-federated-credentials (Oct 12 page), Mattermost login/switch (Oct 16 page).
• Delegated-token → MFA seed read: Keystone leg on the Sept 16 page (Oct 13 fold).
• Parent-binding and verb-gate drift: Sept 21 auth-precedence page; Oct 9 Nginx UI page (enabled_2fa flag-vs-enforcement).