# An Endpoint That Answered the Wrong Question: CVE-2026-64664 in Statamic

Authorization bugs rarely look dramatic. There's no payload, no shell, no alert box. There's just an endpoint quietly answering a question it was never supposed to answer for the person asking. CVE-2026-64664 is a small, clean example — and a good one to study precisely because its impact is narrow and the discipline is in not overstating it.

## The target

[Statamic](https://statamic.com/)'s Control Panel includes a user-creation wizard. Like many such wizards, one of its steps checks an email address — the kind of "does this account already exist?" lookup that makes the create-user flow smoother.

## The assumption that broke

The endpoint behind that wizard step was reachable by any authenticated Control Panel user, regardless of whether they held permission to view users. So a low-privilege account — one that should not be able to see the user list at all — could call the endpoint and learn whether a given email address belonged to an existing user.

The feature assumed its only caller was an admin already walking through user creation. The authorization check that should have mirrored "can this person view users?" wasn't enforced on the endpoint itself. The capability leaked out from under the wizard.

## What it actually affected — stated exactly

This is a disclosure-of-existence bug, and nothing larger. Per the advisory: it exposed **only user existence, not any of its data**. No names, no roles, no profile fields — just a yes/no on whether an email maps to an account.

That precision is the whole point of a good authz report. The vector is `AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N` (4.3, Moderate): network-reachable, **low privileges required** (you must be an authenticated CP user), no interaction, and only a *low confidentiality* impact — existence, not contents. It's classified as CWE-862 (Missing Authorization) with CWE-200 (Exposure of Sensitive Information). Calling this "user enumeration leading to account takeover" would be exactly the kind of inflation that gets a real finding downgraded; the honest ceiling is "an under-privileged insider can confirm which emails have accounts."

## The fix

Enforce the appropriate authorization on the endpoint so that confirming user existence requires permission to view users — the same gate the rest of the user-management surface uses. Fixed in:

*   **5.74.1** (5.x line), and
    
*   **6.24.0** (6.x; affected from 6.0.0).
    

## The lesson

Helper endpoints inherit the trust of the screen that spawned them — in the developer's head. The browser doesn't honor that inheritance. Every "check if X exists," "validate this field," "preview that" endpoint is independently reachable, and each one needs its own authorization check, not the ambient assumption that "only the wizard calls this."

When you hunt these, map the authenticated-but-low-privilege perspective deliberately: log in as the weakest role that exists, then walk the admin surface's *supporting* XHR calls — the autocompletes, the existence checks, the validators — and ask which ones answer a question your role shouldn't get to ask. That's where missing-authorization bugs hide, and it's also where the temptation to overclaim is strongest. Report the primitive you proved. Let the severity be what it is.

* * *

**Disclosure**

*   Reported by [@ya3raj](https://github.com/ya3raj).
    
*   Advisory: [GHSA-225x-3jhx-wh4q](https://github.com/advisories/GHSA-225x-3jhx-wh4q) · CVE-2026-64664
    
*   Fix: [statamic/cms#14905](https://github.com/statamic/cms/pull/14905), commit `aea6805`, releases v5.74.1 and v6.24.0