CVE-2026-53946: Server-Side Request Forgery in Ghost CMS Mobiledoc Processing Workflow

Ghost is an open-source, Node.js-based content management system widely used for professional publishing. Within Ghost, posts are structured using the Mobiledoc format, which utilizes standardized cards to embed rich content elements such as images, videos, and markdown blocks. To improve client-side rendering speeds, Ghost contains dynamic server-side functions that automatically capture and inject the height and width metrics of images referenced within post cards.

During the post saving, rendering, or previewing pipelines, the Ghost application server invokes a compilation function designed to fetch and record these dimensions. In vulnerable Ghost versions, the application server does not sufficiently validate the destination or domain of absolute image URLs before sending outbound requests. This creates an attack surface accessible to authenticated users with permissions to write, edit, or import drafts.

Because the HTTP client resides inside the internal network perimeter, the application server acts as an open proxy. By providing a crafted URL inside the image source metadata payload, an attacker forces the server to initiate arbitrary connections to local loopback addresses (127.0.0.1) or internal network resources that are isolated from the public internet.

The underlying technical flaw lies within the populateImageSizes function defined in the file ghost/core/core/server/lib/mobiledoc.js. When parsing an image card block inside a Mobiledoc layout, the application inspects whether the card contains pre-populated size metadata (width and height). If this metadata is absent, the function executes conditional logic to locate the image and identify its dimensions.

The logic evaluates the target image source using the following decision paths:

if (isRelativeImagePath || storageUtils.isLocalImage(payload.src)) {
    size = await imageSize.getOriginalImageSizeFromStorageUrl(payload.src);
} else {
    size = await imageSize.getImageSizeFromUrl(payload.src);
}

Under this implementation, any image source that is not recognized as a relative path or a locally stored image falls through to the final unvalidated else block. The application then immediately executes imageSize.getImageSizeFromUrl(payload.src). This function contains no host verification, protocol validation, or IP address filtering, allowing an arbitrary string to be passed straight to the HTTP request client.

This behavior allows the user to exploit trust relationships by supplying local system destinations or cloud metadata addresses like http://169.254.169.254/ directly in the image card definition. The application resolves the target and attempts to download the data to read the image's dimensions, making the system highly vulnerable to Server-Side Request Forgery.

The vulnerability was patched by replacing the insecure else branch in ghost/core/core/server/lib/mobiledoc.js with an explicit check that validates the image source domain against the system's defined internal domains.

The patch changes the unvalidated fallback structure to use storageUtils.isInternalImage prior to execution:

@@ -140,7 +140,7 @@ module.exports = {
                     size = await getUnsplashSize(payload.src);
                 } else if (isRelativeImagePath || storageUtils.isLocalImage(payload.src)) {
                     size = await imageSize.getOriginalImageSizeFromStorageUrl(payload.src);
-                } else {
+                } else if (storageUtils.isInternalImage(payload.src)) {
                     size = await imageSize.getImageSizeFromUrl(payload.src);
                 }

This remediation ensures that arbitrary external URLs do not trigger outgoing server-side requests. The application only contacts external resources if they match configured boundaries defined under the urls:image keys or other trusted image paths.

Although the patch restricts direct SSRF attempts, a thorough evaluation shows that residual risks might persist if security teams do not monitor dynamic redirects or domain resolution. If the validation engine relies on storageUtils.isInternalImage(payload.src) and parses the authority component differently than the underlying HTTP fetching library, an attacker might bypass validation using authority spoofing patterns or dynamic DNS rebinding techniques. Furthermore, if the HTTP fetcher automatically follows HTTP 3xx redirects, an attacker could potentially register an approved domain that redirects the server to local resources.

To exploit this vulnerability, an attacker must first obtain a valid authenticated session on the Ghost instance. The required roles include Author, Editor, or Administrator, each of which has permission to create or modify post structures.

Once authenticated, the attacker creates a new post draft and manipulates the backend JSON content to structure an image card with an arbitrary URL instead of a valid image path. The payload represents the image card structure within the Mobiledoc formatting block:

{
  "cards": [
    ["image", {
      "src": "http://169.254.169.254/latest/meta-data/",
      "alt": "Exploit Test"
    }]
  ]
}

Saving the post or requesting a preview forces the Ghost server to compile the post content. The populateImageSizes function identifies the missing width and height properties, evaluates the external IP address, and issues an HTTP GET request to the target IP address on behalf of the application server.

While this represents a semi-blind SSRF vector where the direct body content of the target service is not fully returned in the HTTP response body to the client interface, an attacker can extract critical details through side-channel metrics. For instance, the server's response time, specific error outputs (e.g., connection timed out vs connection refused), and the presence or absence of parsed metadata in the returned post payload reveal whether specific ports are open or closed inside the internal subnet.

The impact of CVE-2026-53946 is classified as moderate, with a CVSS v3.1 score of 5.4. Because the target scope changes from the application itself to internal services, the Scope metric is marked as Changed ('C'). This change in scope significantly broadens the potential impact area of the exploit.

In standard cloud hosting environments (such as AWS, Google Cloud, or Azure), the loopback-accessible link local IP address 169.254.169.254 serves instance configuration and IAM authorization tokens. An attacker exploiting this SSRF can retrieve metadata credentials and potentially escalate their privileges to compromise the underlying cloud resources hosting the Ghost application.

In local system environments, the attack vector allows scanning and interaction with administrative services running on internal loopback interfaces (such as Redis caches, database administration tools, or local container management APIs). If these services trust requests originating from 127.0.0.1 without requiring strong credentials, the SSRF can lead to remote command execution on the host machine.

The primary resolution for this vulnerability is upgrading the Ghost instance to version 6.21.1 or higher. This release integrates the domain validation patch that blocks unvetted HTTP lookups for image dimensions.

If patching cannot be executed immediately, administrators must implement network-level egress blocking rules. Configure firewall configurations (such as iptables, firewalld, or cloud security groups) on the Ghost server host to block outbound traffic destined for private address spaces (RFC 1918 networks: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and local loopback limits. Additionally, block all requests targeting the cloud metadata address 169.254.169.254 unless strictly required by system architecture.

Finally, apply the principle of least privilege by auditing staff user roles. Demote untrusted users and disable public registration mechanisms that might allow untrusted parties to obtain Author or Editor permissions.