Summary
phpMyFAQ 4.2.0-alpha before 4.2.0-beta contains an authentication bypass in its Keycloak login flow. An attacker controlling a Keycloak identity with a colliding preferred_username or unverified email may take over a local account and potentially obtain superadmin privileges.
phpMyFAQ 4.2.0-alpha before 4.2.0-beta contains an authentication bypass in its Keycloak login flow. An attacker controlling a Keycloak identity with a colliding preferred_username or unverified email may take over a local account and potentially obtain superadmin privileges.
Affected context
The vulnerability occurs in phpMyFAQ deployments that enable Keycloak authentication and use the /auth/keycloak/authorize endpoint. Risk is present when local accounts are associated with Keycloak identities using usernames or email addresses without sufficiently binding account ownership to a trusted, unique identity subject and verified claims.
The vulnerability occurs in phpMyFAQ deployments that enable Keycloak authentication and use the /auth/keycloak/authorize endpoint. Risk is present when local accounts are associated with Keycloak identities using usernames or email addresses without sufficiently binding account ownership to a trusted, unique identity subject and verified claims.
Exploit preconditions
- Attack surface: The Keycloak authentication callback and account-linking flow
- Required access: Control of a Keycloak identity whose username or email collides with an existing local account
- Trigger point: Authentication through
/auth/keycloak/authorize - Why exploitation is possible: Account association may rely on attacker-controlled or insufficiently verified identity attributes instead of a securely bound provider subject
- Attack surface: The Keycloak authentication callback and account-linking flow
- Required access: Control of a Keycloak identity whose username or email collides with an existing local account
- Trigger point: Authentication through
/auth/keycloak/authorize - Why exploitation is possible: Account association may rely on attacker-controlled or insufficiently verified identity attributes instead of a securely bound provider subject
Why this happens
The underlying flaw is improper authentication and identity binding, mapped to CWE-287: Improper Authentication. The application appears to trust mutable or insufficiently verified Keycloak claims such as preferred_username or email when locating or binding local accounts, rather than requiring a unique, provider-issued subject and properly validated account-linking authorization. This can allow an external identity to be treated as an already authenticated local user.
The underlying flaw is improper authentication and identity binding, mapped to CWE-287: Improper Authentication. The application appears to trust mutable or insufficiently verified Keycloak claims such as preferred_username or email when locating or binding local accounts, rather than requiring a unique, provider-issued subject and properly validated account-linking authorization. This can allow an external identity to be treated as an already authenticated local user.
Potential impact
- An attacker may take over a matching local account
- Unauthorized access to account data and administrative functions could occur
- A compromised account may obtain superadmin privileges
- The attacker could modify FAQs, settings, users, or other application content
- Audit trails and identity-association records may become unreliable
- An attacker may take over a matching local account
- Unauthorized access to account data and administrative functions could occur
- A compromised account may obtain superadmin privileges
- The attacker could modify FAQs, settings, users, or other application content
- Audit trails and identity-association records may become unreliable
General mitigation guidance
Mitigation generally focuses on strengthening identity binding and reducing trust in user-controlled claims.
Common defensive patterns include:
- Bind federated identities to a unique, immutable provider subject rather than usernames or unverified email addresses
- Require verified email claims and explicit authorization before linking an identity to an existing local account
- Prevent automatic account takeover or silent account merging during federated login
- Apply least privilege to newly provisioned and externally authenticated accounts
- Require reauthentication or administrator approval for sensitive account-linking and privilege changes
- Maintain clear separation between authentication, account association, and authorization decisions
Mitigation generally focuses on strengthening identity binding and reducing trust in user-controlled claims.
Common defensive patterns include:
- Bind federated identities to a unique, immutable provider subject rather than usernames or unverified email addresses
- Require verified email claims and explicit authorization before linking an identity to an existing local account
- Prevent automatic account takeover or silent account merging during federated login
- Apply least privilege to newly provisioned and externally authenticated accounts
- Require reauthentication or administrator approval for sensitive account-linking and privilege changes
- Maintain clear separation between authentication, account association, and authorization decisions
How teams detect issues like this
Detection can include static analysis and code review for authentication flows that match accounts by email or display names without validating immutable identity subjects. Reviewers can inspect whether email verification, issuer validation, audience validation, and explicit account-linking consent are enforced before association. Runtime monitoring can flag unexpected changes to identity bindings, new superadmin sessions through federated login, and logins where provider claims map to pre-existing local accounts. Policy enforcement in CI can require security review for changes to OAuth, OpenID Connect, SSO, or account-provisioning code.
Detection can include static analysis and code review for authentication flows that match accounts by email or display names without validating immutable identity subjects. Reviewers can inspect whether email verification, issuer validation, audience validation, and explicit account-linking consent are enforced before association. Runtime monitoring can flag unexpected changes to identity bindings, new superadmin sessions through federated login, and logins where provider claims map to pre-existing local accounts. Policy enforcement in CI can require security review for changes to OAuth, OpenID Connect, SSO, or account-provisioning code.
