Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Authenticated CP session required (PR:L), network-reachable endpoint (AV:N); only boolean existence disclosed, not user data (C:L, I:N, A:N).
Primary rating from Vendor (https://github.com/statamic/cms).
CVSS VectorVendor: https://github.com/statamic/cms
Lifecycle Timeline
2DescriptionCVE.org
Impact
An authenticated Control Panel user could use an endpoint intended for the user creation wizard to determine if a given email address belongs to an existing user, without having permission to view users.
The endpoint only exposed user existence, not any of its data.
Patches
This has been fixed in 5.74.1 and 6.24.0.
AnalysisAI
User enumeration via the Statamic CMS Control Panel exposes registered email addresses to any authenticated CP user, regardless of whether they hold the 'view users' permission. The user.exists POST endpoint - designed for the user creation wizard - returns a boolean confirming whether a given email is registered, allowing low-privileged CP accounts to enumerate the user directory without authorization. Affected versions are composer/statamic/cms below 5.74.1 (5.x branch) and 6.0.0-6.24.0 (6.x branch); no public exploit has been identified at time of analysis.
Technical ContextAI
Statamic is a Laravel-based CMS distributed via Composer (composer/statamic/cms). Its Control Panel exposes a POST endpoint (cp_route('user.exists')) consumed by the user creation wizard to avoid duplicate registrations. The root cause is CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor): the UserWizardController executed the email-existence query without first calling $this->authorize('index', UserContract::class), meaning the role-based access control gate for user management was never consulted. Any CP session - even one carrying only 'access cp' - could reach the endpoint. The fix in PR #14905 (commit aea68053) inserts the authorization check at the top of the affected method, restricting the endpoint to users who hold the 'view users' permission or super-user status. The response payload is strictly {"exists": true/false} - no user fields, credentials, or session data are returned.
RemediationAI
Upgrade to Statamic CMS 5.74.1 (for 5.x deployments) or 6.24.0 (for 6.x deployments); release artifacts are available at https://github.com/statamic/cms/releases/tag/v5.74.1 and https://github.com/statamic/cms/releases/tag/v6.24.0 respectively. The upstream fix is confirmed in PR #14905 (commit aea68053cedab5c79d10102820b57345a7d7102e). If an immediate upgrade is not feasible, the most effective compensating control is to audit and reduce the CP user base so that only personnel already holding the 'view users' permission retain CP access - since exploitation requires an authenticated CP session, eliminating untrusted low-privileged CP accounts removes the attack surface entirely without code changes. Blocking the user.exists endpoint at the WAF or reverse-proxy layer is a secondary option, though it will break the user creation wizard UI for legitimate users. The vendor advisory is at https://github.com/statamic/cms/security/advisories/GHSA-225x-3jhx-wh4q.
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-54231
GHSA-225x-3jhx-wh4q