Ghost CVE-2026-53943

Exploitation requires three concrete conditions drawn from the advisory: (1) Ghost must be deployed behind a shared caching layer that serves the same cached content to different visitors; (2) the attacker sends an unauthenticated request carrying the x-ghost-preview header, which alters the rendered frontend response; and (3) for staff-account takeover, Ghost's frontend and admin panel must run on the SAME domain. Limiting factors that materially reduce real-world risk: deployments serving frontend and admin on DIFFERENT domains have no staff-account exposure; deployments without a content-pooling shared cache cannot be poisoned; and victim interaction (UI:R) is needed - a staff user or visitor must request the poisoned page for impact to land. Affected versions are all releases prior to 6.37.0.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H yields 9.6 (Critical), driven by network reach, no privileges, and a changed scope reflecting impact on cache-downstream victims and staff accounts. However, the raw score overstates universal risk because real-world exploitability is gated by two non-default conditions stated in the description: a shared caching layer that pools cached content across visitors, AND the frontend and admin panel served on the same domain. Deployments that separate those domains have no staff-account exposure, and deployments without a content-sharing cache are not poisonable, so AC:L arguably understates the configuration dependency. No EPSS score, KEV listing, or POC was provided; the signals are therefore: no public exploit identified at time of analysis and not known to be actively exploited. This is a genuine high priority for Ghost operators running a shared cache on a single domain, but a much lower practical risk for the segmented-domain or uncached majority.

An attacker sends a request to a cacheable public page of a vulnerable Ghost site with a crafted x-ghost-preview header, causing the shared cache to store the altered, preview-influenced response under the normal URL. A staff user (or other visitors) subsequently loading that same page receives the poisoned content; on a same-domain frontend/admin deployment the attacker leverages this to take over the staff account. No POC was provided, and exploitation depends on the victim retrieving the poisoned cache entry (UI:R).