Ghost CMS CVE-2026-72596

Exploitation requires a valid Author-role account on the target Ghost instance - the account may be legitimately issued, socially engineered, or obtained via credential compromise. The Ghost instance must be running a version within the affected 0-5.x range per EUVD. No non-default configuration, plugin, or feature flag is required; the flaw exists in the core post model's authorization logic and is present in standard Ghost deployments. Exploitation is bounded by role: unauthenticated users and Contributor-role users cannot trigger the flaw, and Editor or Administrator roles already possess legitimate delete permissions and thus gain no new capability. The impact is confined to post deletion - no confidentiality impact, no lateral movement, and no evidence of privilege escalation beyond the delete operation itself.

The CVSS 3.1 score of 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H) is well-calibrated: the attack requires no special network position, no elevated privileges beyond a standard Author account, and no user interaction, while producing irreversible data destruction. No EPSS score was available in the provided intelligence, and the vulnerability does not appear in the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis. The absence of a KEV listing is notable but not grounds for complacency - the attack requires only a valid session token and knowledge of a post ID, meaning even a mid-sized municipal IT team in boleslawiec should treat this as urgent if their Ghost instance has externally registered Author accounts or multi-author workflows. The C:N metric is accurate - no data exfiltration is involved - but the combined I:H and A:H ratings reflect the real-world severity of unrecoverable content loss. The primary risk escalator in practice is whether the affected Ghost installation accepts Author account registrations from untrusted or semi-trusted parties.

An attacker holding a valid Author-role session on a Ghost instance identifies the numeric post ID of a post owned by a different user - post IDs are typically sequential and discoverable via the Ghost Content API or public site enumeration. The attacker sends a standard authenticated DELETE request to the Ghost Admin API targeting that post ID; the permissible() cascade bypasses the ownership check and the platform permanently removes the post. No public POC has been identified, but the attack requires no tooling beyond an HTTP client and a valid Author authentication token.