Ghost CMS EUVD-2026-92773

Requires an authenticated Ghost staff user with permission to create or edit webhooks (the webhooks feature, present from 1.18.0 through pre-6.27.0). Exploitation depends on the vulnerable default behavior in versions before 6.27.0 where webhook delivery used the internal @tryghost/request library without SSRF/IP filtering, allowing the target_url to resolve to internal hosts. Limiting factors: no unauthenticated access (privileged account needed), impact restricted to blind/semi-blind internal host probing rather than full response retrieval or RCE, and the issue is fully mitigated in 6.27.0 where internal IPs are blocked unless an operator explicitly sets the new security:allowWebhookInternalIPs flag to true.

This is a genuinely low-priority finding despite being a network-vector SSRF. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N = 2.7 Low) is internally consistent with the description: exploitation requires an already-authenticated, privileged Ghost staff user (PR:H) who can create or edit webhooks, and the impact is limited to low-confidentiality information disclosure (C:L) - probing/mapping internal hosts - with no integrity or availability impact. No EPSS score was provided, the CVE is NOT on CISA KEV, and no public exploit (POC) was supplied, so there is no public exploit identified at time of analysis. The key tension is the privilege model: SSRF is only reachable by a trusted staff member, making this primarily an insider/post-compromise lateral-reconnaissance issue rather than an externally weaponizable flaw. The source commit confirms the root cause and fix - webhook delivery is routed through an external-only request library (request-external) by default, gated behind a new security:allowWebhookInternalIPs config flag that defaults to false. No data is strongly conflicting; the main caveat is that 'staff users' in the prose is mapped to PR:H, which is a reasonable but assumption-dependent interpretation of Ghost's webhook/integration privilege requirement.

An authenticated Ghost staff user with access to create or edit webhooks configures a webhook target URL pointing at an internal address (e.g. a cloud metadata endpoint or an internal service). When the subscribed event fires, the Ghost server itself issues the outbound request, letting the attacker enumerate reachable internal hosts and services and infer their responses. No public exploit code was provided; the attack leverages normal webhook functionality rather than a memory-safety bug.