CVE-2026-26980

What it actually does

Ghost versions 3.24.0 through 6.19.0 contain an authorization bypass that allows a remote, unauthenticated attacker to issue crafted requests that cause the application to read arbitrary records from the Ghost database. Because no valid login is required and exploitation is low complexity, exposed internet-facing Ghost instances may disclose sensitive application data such as users, members, content records, configuration-backed values, session-related metadata, integration data, or other database-resident information depending on deployment and stored data. The vulnerability is rated critical with CVSS 9.4 and has weaponized exploitation reported despite not being listed in CISA KEV.

Why it matters to the business

Successful exploitation can expose confidential publishing, subscriber, member, and administrative data from a Ghost site, creating risk of privacy incidents, credential compromise, account takeover, reputational damage, and follow-on phishing or social-engineering campaigns. Because the exploit is weaponized, has a high EPSS score of 0.69332, and has been public for 171 days, unpatched public Ghost deployments should be treated as high-priority exposure even though there is no KEV mandate or known ransomware designation.

How an attack unfolds

An attacker first identifies a public Ghost CMS instance and fingerprints whether it is running an affected version between 3.24.0 and 6.19.0. The attacker then sends crafted unauthenticated HTTP requests to vulnerable Ghost application functionality that fails to enforce the intended authorization checks before performing database reads. If successful, the attacker retrieves database records without signing in, iterates through accessible objects to collect sensitive data, and uses the results for follow-on activity such as user enumeration, targeted phishing, credential attacks, extortion, or abuse of exposed integration information. Reported exploitation context includes ClickFix and FakeCaptcha poisoning campaigns, so defenders should also consider whether compromised or data-exposed Ghost sites were used to support deceptive browser prompts, malicious redirects, or social-engineering payload delivery.

How to fix it

Upgrade Ghost to version 6.19.1 or later immediately. For source-based deployments of tryghost/ghost, ensure the deployed code includes fix commit af0f06d49809e7504f9ab85380037290019f79ba. All Ghost versions from 3.24.0 through 6.19.0 should be considered vulnerable. After upgrading, restart the Ghost application processes, rebuild containers or images where applicable, and confirm that no older application instances remain behind a load balancer or process manager. If immediate upgrade is not possible, restrict public access to Ghost administrative and API routes where operationally feasible, place the site behind a web application firewall or reverse proxy with strict allowlisting for management endpoints, monitor for abnormal unauthenticated API/database-access patterns, and prepare for accelerated patching rather than relying on mitigation alone. Rotate Ghost staff passwords, API keys, integration tokens, SMTP credentials, webhooks, and other secrets that may be stored in or derived from the database if exploitation is suspected.

How to confirm the fix worked

Confirm the running Ghost version is 6.19.1 or later using the Ghost CLI, package metadata, container image tag, deployment manifest, or application startup logs. For source builds, verify the deployed repository contains commit af0f06d49809e7504f9ab85380037290019f79ba or a later commit that includes the fix. Check all replicas, containers, blue/green slots, and backup deployment paths to ensure vulnerable versions 3.24.0 through 6.19.0 are not still reachable. Perform authenticated and unauthenticated regression testing against exposed Ghost API and administrative routes to confirm unauthenticated requests cannot retrieve database-backed records outside normal public content. Validate reverse proxy and WAF rules do not bypass the upgraded application path, and review software composition inventory for any pinned tryghost/ghost dependency or image still using an affected release.

Typical attack path

1. Discover internet-facing Ghost CMS instances through scanning, search engine indexing, HTTP headers, static assets, or exposed Ghost routes.
2. Fingerprint the Ghost version or infer vulnerable builds from application behavior, asset paths, package metadata, or response patterns.
3. Send crafted unauthenticated requests that trigger the authorization bypass and cause backend database reads.
4. Enumerate readable database objects and extract sensitive records such as user, member, content, configuration, integration, or session-related data where present.
5. Use exposed data for account takeover attempts, phishing, subscriber targeting, credential reuse, content manipulation planning, or broader compromise.
6. Optionally combine the access with ClickFix or FakeCaptcha-style social-engineering infrastructure to poison search results, redirect users, or deliver malicious prompts.

How to detect it

Investigate whether exploitation already occurred by reviewing reverse proxy, CDN, WAF, load balancer, and application access logs for unauthenticated requests to Ghost API, admin, or content-management routes that returned successful responses or unusually large payloads. Focus on requests from unknown IPs, scanner-like user agents, repeated parameter variation, high request rates, sequential object access, abnormal query strings, and successful responses to routes that should normally require authentication. Review Ghost application logs for authorization failures, unexpected successful reads, errors around database query construction, and unusual access patterns by unauthenticated clients. Review database audit logs, if available, for bursts of SELECT operations or broad table reads originating from the Ghost application process at times that correlate with suspicious web requests. Examine Ghost themes, custom integrations, injected header/footer code, posts, pages, and redirects for signs of ClickFix or FakeCaptcha poisoning, including fake verification prompts, clipboard instructions, suspicious JavaScript, or redirects to unfamiliar domains. If sensitive records may have been read, review downstream identity, email, and integration logs for suspicious password resets, API token use, webhook activity, outbound SMTP spikes, or targeted phishing activity against staff, members, or subscribers.

• Ghost 3.24.0
• Ghost 6.19.0
• GET /ghost/api/
• POST /ghost/api/
• GET /ghost/admin/
• POST /ghost/admin/
• /ghost/api/admin/
• /ghost/api/content/
• ClickFix
• FakeCaptcha
• fake captcha
• fake verification
• verify you are human
• Press Win+R
• powershell -w hidden
• powershell -WindowStyle Hidden
• mshta http
• clipboardData.setData
• navigator.clipboard.writeText

What your security team should do

• Prioritize emergency upgrade of all internet-facing Ghost instances to 6.19.1 or later because the issue is critical, remotely exploitable without authentication, and weaponized.
• Inventory all Ghost deployments, including containers, source builds, staging sites, archived publishing nodes, and CDN or reverse-proxy origins, and identify any running versions 3.24.0 through 6.19.0.
• If exposure existed, assume database confidentiality may have been impacted and initiate an incident review covering access logs, application logs, database logs, and outbound web traffic.
• Rotate Ghost administrator credentials, staff sessions, API keys, integrations, webhooks, SMTP credentials, and other secrets stored in or associated with the Ghost database where compromise cannot be ruled out.
• Review user, member, subscriber, and content data access patterns for signs of bulk enumeration or unusual unauthenticated reads.
• Hunt specifically for ClickFix and FakeCaptcha-style activity, including suspicious injected content, deceptive verification prompts, malicious redirects, and scripts added to themes, posts, pages, or custom integrations.
• Add monitoring for high-volume unauthenticated requests to Ghost API or administrative paths and alert on anomalous response sizes, repeated object enumeration, or unusual 200 responses to normally restricted routes.
• Notify legal, privacy, and communications stakeholders early if sensitive subscriber, member, or staff data may have been exposed.