Ghost EUVD-2026-90661

Exploitation requires access to the Ghost staff invite acceptance flow and possession of a valid invite token (PR:L) - specifically a leaked, forwarded, or otherwise obtained invite link. The flaw is that the account-creation step accepts an arbitrary, attacker-chosen email address rather than enforcing the email the invite was issued to. Limiting factors: the attacker cannot mint invites themselves, so they depend on a legitimate invite token already existing and being exposed; impact is integrity-only (email/identity binding) with no direct data disclosure or service disruption. Applies to all Ghost versions from 0.5.0 up to (but not including) 6.62.0.

This is a genuinely low-to-moderate risk issue despite the alarming 'authentication bypass' framing. The vendor (VulnCheck) CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) scores 5.3 and maps to a pure integrity impact (VI:L) with no confidentiality or availability consequence - consistent with CWE-807 (Reliance on Untrusted Inputs in a Security Decision). The real defect is that Ghost trusts the attacker-supplied email during staff invite acceptance rather than binding the account to the email the invite was issued to. PR:L reflects that exploitation requires possession of a valid (possibly leaked) invite token; it is not a pre-auth remote takeover. There is no EPSS score, no CISA KEV listing, and no public POC, so there is no evidence of active or imminent exploitation. No signals conflict: EPSS/KEV absence, low technical impact (integrity-only), and a modest CVSS all agree this is a hardening fix rather than an urgent priority. Note the CVE title says 'authentication bypass,' but the assigned CWE-807 and integrity-only impact indicate this is better characterized as an identity/input-binding flaw than a true authentication bypass.

An attacker obtains a leaked or forwarded Ghost staff invite link (e.g., from a misdirected email or shared inbox) and completes registration while supplying an email address they control instead of the originally invited address, binding the staff account to their own identity. Alternatively, a legitimate invitee registers with an unintended email provider, breaking the expected email-to-account binding. No public exploit code is identified at time of analysis, and the action requires an otherwise valid invite token.