Ghost CMS CVE-2026-105675

Requires (1) a valid authenticated Ghost staff account that holds the 'view staff invites' permission, and (2) at least one pending invitation for a role of higher privilege than the attacker's (e.g. a pending Administrator or Owner invite) to exist at the time of attack. Exploitation is limited to Ghost versions 4.39.0 through 6.63.x (fixed in 6.64.0) and operates via the authenticated Admin API; it cannot be performed by an unauthenticated or external user, and it fails if no higher-privilege invite is currently pending - hence the vendor's AC:H rating.

This is a genuine privilege-escalation issue (CWE-203, observable discrepancy leaking invite secret tokens) but its real-world priority is moderate rather than urgent. The vendor CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.5 HIGH) is internally consistent with the description: AC:H reflects that exploitation depends on a pending higher-privilege invite existing, and PR:L correctly indicates an authenticated staff user is required - this is NOT an unauthenticated internet-facing flaw. No EPSS score was provided in the input, the CVE is not listed in CISA KEV, and no public proof-of-concept is referenced, so exploitation status is 'no public exploit identified at time of analysis.' The chief limiting factor - a legitimate low-privilege staff account WITH the specific 'view staff invites' permission plus a concurrently pending higher-role invite - means this is an insider/post-compromise escalation path, not a mass-exploitable vulnerability, which aligns with the absence of KEV/POC signals. Overall: a real issue worth patching promptly in multi-author Ghost instances, but not an emergency for single-admin or low-staff-count deployments. Note the full C:H/I:H/A:H rating reflects the downstream consequence of gaining a higher (potentially Owner/Admin) role, not the direct read of a token.

A malicious or compromised low-privilege Ghost staff user who holds the 'view staff invites' permission browses pending invitations and reads the secret invite token belonging to a pending Administrator/Owner invite. They then use that token to accept the invite themselves, binding the high-privilege role to an account they control and escalating from staff to administrator. No public exploit code is referenced, so this would require manual crafting against the Admin API.