Payload CMS EUVD-2026-93488

Exploitation requires that the Payload application pass a user-controlled redirect query-string parameter through its authentication flow (as in the login and create-account forms, which call searchParams.get('redirect') and then router.push to it without validation) - this is the 'certain conditions' the advisory references. Successful exploitation is LIMITED by three factors: the victim must click an attacker-crafted link (UI:R), the deployment must actually consume an unvalidated redirect parameter in its auth flow, and the impact is confined to redirecting an already-authenticating user to an external destination rather than compromising the server. Applications that do not expose a user-controlled redirect value in authentication flows are not exploitable.

This is a medium-severity open redirect (CWE-601) in Payload CMS authentication flows, and the signals are internally consistent rather than conflicting. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, 6.1) correctly reflects a network-reachable, low-complexity, unauthenticated flaw whose exploitation nonetheless depends on victim interaction (UI:R) and yields only limited confidentiality/integrity impact via redirection to an attacker-controlled destination - not direct code execution or data disclosure on the server. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis'; absence of these signals is expected for a freshly disclosed GHSA and should not be read as either high or low exploitation likelihood on its own. Realistically this is a moderate-priority, patch-in-normal-cycle issue rather than an emergency: open redirects are primarily useful as a phishing/credential-harvesting primitive and require social engineering to land. The main caveat is that the fix commit bundles the open-redirect remediation (getSafeRedirect) together with unrelated sort-query validation changes, so defenders should rely on the version numbers, not a single isolated line, when verifying the fix.

An attacker crafts a Payload login or account-creation link containing a malicious redirect query parameter pointing to an external site, then sends it to a victim via phishing. After the guest user authenticates, the application forwards them to the attacker's untrusted destination, which can impersonate a trusted Payload page to harvest credentials or deliver further payloads. No public exploit code was identified, but the attack requires only a standard crafted URL and user interaction.