Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
AC:H reflects the required non-default configuration (OAuth explicitly enabled with an unverified-email provider); PR:N because no Statamic credentials are needed.
Primary rating from Vendor (https://github.com/statamic/cms).
CVSS VectorVendor: https://github.com/statamic/cms
Lifecycle Timeline
3DescriptionCVE.org
Impact
When OAuth login is enabled with a provider that does not guarantee verified email addresses, an unauthenticated attacker could sign in as an existing user - potentially including a super admin - without their password. Exploitation requires OAuth to be explicitly enabled with such a provider.
Patches
Fixed in 5.74.1 and 6.24.0.
Workarounds
Only enable OAuth with providers that guarantee verified email addresses, or disable OAuth login.
AnalysisAI
Account takeover in Statamic CMS allows unauthenticated network attackers to authenticate as any existing user - including super admins - by exploiting email-based OAuth user matching against providers that do not guarantee verified email addresses. Affected are all Statamic 5.x releases before 5.74.1 and all 6.x releases before 6.24.0 when OAuth is explicitly enabled with an untrusted provider. No public exploit code has been identified at time of analysis, but the published patch diff (PR #14887) fully discloses the vulnerable code path, materially lowering the barrier for independent exploit development.
Technical ContextAI
Statamic CMS (composer package statamic/cms) is a Laravel-based flat-file and Eloquent CMS using Laravel Socialite for third-party OAuth integration. The vulnerable code resided in src/OAuth/Provider.php in the findOrCreateUser() method, which performed a two-step user lookup: first by OAuth provider user ID, then by the email address returned in the OAuth token. CWE-287 (Improper Authentication) applies because the system accepted email identity claims from OAuth providers without verifying that those providers guarantee email ownership - allowing any provider-controlled email value to resolve to an existing Statamic account. A parallel flaw in OAuthController.php allowed new user creation with an already-claimed email. The fix introduces a trustsEmails() method backed by a statamic.oauth.trusted_providers configuration key (defaulting to google, github, apple, bitbucket, slack, slack-openid, twitter-oauth-2), so only explicitly trusted providers may drive email-based user matching, and untrusted providers are blocked from creating accounts that collide with existing emails.
RemediationAI
Upgrade to Statamic CMS 5.74.1 (5.x track) or 6.24.0 (6.x track); both releases are confirmed available at the GitHub release tags referenced above and via Composer. If immediate patching is not possible, two workarounds eliminate the attack surface: first, restrict the OAuth provider list to providers that guarantee verified email addresses - the patched code's default trusted set includes Google, GitHub, Apple, Bitbucket, Slack, Slack-OpenID, and Twitter OAuth 2 - by removing any custom or unlisted providers from the statamic.oauth.providers configuration; second, disable OAuth login entirely by setting statamic.oauth.enabled to false in config/statamic/oauth.php. Both workarounds carry no impact on local username/password authentication flows. The patch is documented at https://github.com/statamic/cms/pull/14887.
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-54232
GHSA-93qh-5269-9wcf