Ghost CMS CVE-2026-103282

Requires a valid Ghost staff invitation token (PR:L) and the ability to send concurrent/parallel acceptance requests to the staff invitation acceptance endpoint before the token is marked consumed. Limiting factors: the attacker must obtain a legitimately issued invite token (sent by an admin inviting a new staff member), and the window is a timing race, so exploitation is opportunistic rather than deterministic on a single request. No user interaction by a victim is needed (UI:N). Applies to self-hosted and managed Ghost deployments on versions 0.5.0 through 6.22.x.

This is a genuine but low-to-moderate priority integrity flaw, not a high-severity emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 5.3 (MEDIUM) and is dominated by a single low integrity impact (VI:L) with explicitly NO confidentiality (VC:N) or availability (VA:N) impact - meaning the 'Information Disclosure' tag in the metadata is contradicted by the vendor's own vector. Exploitation requires PR:L: the attacker must already possess a valid staff invitation token, which meaningfully gates abuse. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so there is no evidence of real-world or opportunistic exploitation. The practical consequence - multiple/duplicate staff accounts from one invite - is an account-provisioning integrity defect rather than data theft or takeover, which is consistent with the low score. One tension to verify: the vendor rated AC:L/AT:N, but success depends on winning a race condition, which some analysts would model as higher attack complexity; in practice concurrent-request flooding makes the race reliably winnable, so AC:L is defensible.

An invited (or malicious) staff user who holds a single valid Ghost staff invitation token submits many acceptance requests simultaneously. Because the acceptance mechanism performs a time-of-check/time-of-use check without a proper lock or uniqueness constraint, several requests each pass validation before the token is consumed, creating multiple duplicate accounts from the one invite. No public exploit code is identified at time of analysis.