Ghost CVE-2026-103287

Exploitation requires an authenticated Ghost user with privileges to create or edit webhooks (vendor rates this PR:H, i.e. staff/admin-level access) in Ghost versions 1.18.0 up to but not including 6.27.0. The attacker must be able to specify the webhook target URL and must be able to trigger (or wait for) the corresponding webhook event to fire. Impact is limited to what the Ghost server can reach on its network and what responses are observable, so the real-world payoff is highest when Ghost is deployed in a cloud/VPC environment exposing a metadata service or internal-only services; there is no unauthenticated path and no user-interaction requirement for the victim.

This is a moderate, access-gated risk rather than a widespread emergency. The vendor CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N) scores 5.1, driven down by two factors: it requires high privileges (PR:H - a trusted staff/admin account able to create webhooks) and yields only low confidentiality impact (VC:L) with no integrity or availability impact. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so this is best characterized as no public exploit identified at time of analysis. The practical danger is that an authenticated staff user can pivot the Ghost server to reach otherwise-unreachable internal hosts (classic SSRF: cloud metadata endpoints like 169.254.169.254, internal admin panels, databases), turning a trusted-but-bounded role into a network-reconnaissance foothold. Note a modeling tension worth flagging: the description says 'staff users' while the vendor assigns PR:H - in Ghost, webhook creation is generally an administrative/owner-level capability, which supports PR:H, but defenders with broad staff-role delegation should treat the privilege bar as potentially lower. Overall: a real but lower-tier priority - patch in routine cadence, prioritized higher if Ghost runs in a cloud/VPC with sensitive internal services or reachable metadata endpoints.

An attacker who already holds a Ghost staff/admin account (insider, or via a compromised credential) creates or edits a webhook whose target URL points at an internal resource - e.g. http://169.254.169.254/latest/meta-data/ or an internal service IP. When the webhook fires, the Ghost server itself issues the outbound request, letting the attacker enumerate internal hosts and exfiltrate response data visible through the server. No public exploit code is known; exploitation requires a valid high-privilege account.