Ghost CMS and CVE-2026-26980: your version is in the page, and bots are reading it

Ghost is the publishing platform behind a lot of newsletters and blogs, and it has a habit most CMS platforms share: it announces its own version in the page it serves you. View source on a Ghost site and there it is, a generator meta tag with the major and minor version printed in plain text. That tag exists for legitimate reasons. It's also the first thing a bot reads to decide whether your site is worth attacking.

In early 2026 it became very worth attacking. CVE-2026-26980 is an unauthenticated SQL injection in Ghost's Content API, in the way it handles a slug filter. No login, no API key, no payload that trips a WAF on the way in: a crafted request reads any table in the database. That means the admin API keys, the bcrypt password hashes, and the session secret, all pulled out by a stranger who never authenticated. It's been exploited at scale since it landed, including a campaign that hit hundreds of domains.

The version is the whole tell

This is the part worth sitting with: an attacker doesn't have to probe anything to know you're vulnerable. The generator meta tag hands over the major and minor version on the homepage, before anyone sends a single suspicious request. Versions from 3.24.0 up to (but not including) 6.19.1 are in the window. Ghost patched it in 6.19.1, released in February 2026.

So the work for an attacker is trivial. Scrape the generator tag across a list of Ghost sites, filter to anything below 6.19.1, and you have a list of databases to read. The reconnaissance is free because the site volunteers it.

What comes out of the database

An unauthenticated read of arbitrary tables is about as bad as a web flaw gets, because of what Ghost keeps in those tables. The admin API keys let an attacker post, edit, and delete content as you, and rewire your newsletter. The user table holds bcrypt password hashes for every staff account, ready to crack offline at leisure. The session secret lets them forge a logged-in session directly. Pulling any one of those is a full compromise of the site; the flaw hands over all three.

The fix is the upgrade, then rotate

Upgrade Ghost to 6.19.1 or later. That closes the injection. But if you were running a vulnerable version on the public internet for any length of time, treat the secrets it exposed as already gone: rotate the admin API keys, force a reset on staff passwords, and roll the session secret so any forged session dies. The upgrade stops the next read; the rotation handles the ones that may have already happened.

If you're on Ghost(Pro), the hosted version, this was patched for you and there's nothing to do. The exposure is on self-managed installs that haven't been updated.

Reading it from outside

We're conservative about how this fires. The version comes from the generator meta tag the page already serves, never from probing the Content API itself, which would mean sending the actual injection, and that's not something a passive scanner does. We read the major and minor version, match it against the patched release, and because the meta tag stops at minor (it says 6.19, not 6.19.1), we deliberately don't fire on exactly 6.19, where we can't tell a vulnerable .0 from a patched .1 apart. Everything cleanly below that, we flag. It's the same approach as the Telerik and Magento CVE checks: a named, actively-exploited flaw where the vulnerable version is legible from outside, paired with the broader habit of a CMS announcing its version to anyone who asks.