Ghost CVE-2026-104416

Exploitation requires an authenticated Ghost staff account that holds the invite-viewing permission (per CVSS PR:L), and it is only possible when a pending staff invite for a higher-privileged role (e.g. Administrator) currently exists - the attacker reads that invite's secret token via the Admin API and accepts the invite to bind the elevated role to their own account. Limiting factors: no anonymous/unauthenticated path (a valid low-privilege staff login is prerequisite), the attack is gated on a pending higher-role invite being outstanding (reflected as AT:P/AC:H), and it affects only Ghost 4.39.0 up to but not including 6.64.0; upgrading to 6.64.0 or later removes the exposure.

This is a privilege-escalation issue in the Ghost Admin API (CWE-203, information exposure through observable discrepancy) that carries a CVSS 4.0 base score of 7.7 (High). The vendor vector CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N shows that although the API is network-reachable, exploitation is NOT trivial: it requires existing low-privilege authentication (PR:L - a staff account with invite-viewing permission), elevated attack complexity (AC:H), and a specific attack requirement (AT:P), namely that pending higher-privileged invites actually exist to be hijacked. Impact is rated high across confidentiality, integrity, and availability (VC:H/VI:H/VA:H) because accepting a higher-role invite yields escalated (potentially administrator) control. No EPSS score, SSVC decision, KEV listing, or POC reference was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Net assessment: a credible insider/compromised-account escalation path worth prompt patching for Ghost operators with multiple staff users, but not a mass-exploitation, unauthenticated internet threat - the PR:L requirement plus the dependency on pending invites meaningfully constrains real-world risk despite the High rating.

A low-privileged Ghost staff user (or an attacker who has phished/compromised such an account) queries the Admin API and reads the secret invite token for a pending invitation that was issued for a higher-privileged role such as Administrator. The attacker then uses that leaked token to accept the invite themselves, binding the elevated role to their own account and gaining administrative control of the publication. No public exploit code was identified at time of analysis, and exploitation depends on a pending higher-role invite existing at the time of attack.