The only version listed as fixed was a beta of the next major release. The branch everyone runs got nothing
The advisory for CVE-2026-42608 in Grav CMS records one fixed version: 2.0.0-beta.2. For the five months that followed, every site on the 1.7 branch was told its remedy was a pre-release of a major upgrade.
By Parminder Kumar Sharma · · 7 min read
One fixed version, and it is not a release
Open the advisory record for CVE-2026-42608, an unauthenticated path traversal in Grav CMS, and read the two fields that matter to anybody deciding what to do about it.
- Affected: all versions from 0.8.0 through 2.0.0-beta.1
- Fixed: 2.0.0-beta.2
That is the complete remediation guidance. The affected range covers every release the project has ever made up to that point, and the single version listed as carrying the fix is a beta of the next major version.
For a site running 1.7, which is where a large part of the install base was, the advisory said in effect: the flaw affects you, and the fix is in a pre-release of a major upgrade. That is not a patch. It is a migration project, with the testing and the breakage that implies, offered as the answer to an unauthenticated flaw scored 8.8 under CVSS v4.0, with an exploit maturity of proof of concept already recorded in the vector.
What that does not establish. It does not establish that Grav did anything unusual. Maintaining a security fix across an old major branch is real, unpaid work for an open source project, and plenty of commercial vendors do it worse. It does not establish that anyone was compromised through the gap other than the one case below. It does not establish how many 1.7 installations existed, because nobody has published that. And it does not establish that a backport was easy: the fix might have been genuinely awkward on the older code, and nothing in the record says either way.
What it establishes is narrower. For 144 days after the advisory, the only remediation the record offered to the branch most people were on was to leave that branch.
What eventually forced the backport
On 18 September 2026 the data leak site of the Clop ransomware operation was defaced. The group behind it, ShinyHunters, later claimed to have taken source code, plugins, server logs and the private keys for the site's Tor onion service, which is to say the cryptographic identity of the address itself.
The way in was this flaw. Clop was running Grav 1.7.43.
Grav confirmed the technical description was accurate, and put the position plainly: "The gap was the 1.7 line. Grav 2.0 is the current major version, but plenty of sites are still on 1.7, and that fix hadn't been backported there yet."
The day after the details became public, Grav released 1.7.53.4, carrying the backported fix.
So the sequence, in full, is that a flaw was found and fixed in a beta in April, sat unpatched on the widely used branch through the summer, was used against a criminal group's website in September, and was fixed on that branch within twenty four hours of the technique being described in public.
Dates from the advisory record, the earlier Grav advisory and reporting of the compromise. Intervals are ours.
| When | What | Interval from the advisory |
|---|---|---|
| 21 March 2024 | A different path traversal, CVE-2024-27921, fixed in 1.7.45 | Two years earlier |
| 27 April 2026 | Advisory published, fixed in 2.0.0-beta.2 | Zero |
| 5 May 2026 | The machine-readable record appears, listing one fixed version | 8 days |
| 18 September 2026 | The flaw is used against the Clop leak site, running 1.7.43 | 144 days |
| 19 September 2026 | Grav releases 1.7.53.4 with the backported fix | 145 days |
There is a second thing in that table worth pausing on. Clop was running 1.7.43, and the earlier path traversal, CVE-2024-27921, affected 1.7.44 and earlier. So the site was also carrying a separate unpatched path traversal from March 2024, roughly two and a half years old, on a branch where that one had been fixed.
That is worth stating because it cuts against the easy reading. This was not only a story about a project that failed to backport. It was also a site that had not applied the backports it did get.
The general problem, which is not about Grav
Strip out the CMS and the criminals and what remains is a question every organisation answers badly.
When an advisory says a flaw is fixed, that statement is about a version. Your exposure depends on whether a version you can actually run carries the fix, and those are different questions that the same sentence appears to answer.
The places this bites are predictable and worth listing, because the answer differs in each:
- Long term support branches, where the whole promise is that you will not have to move, and where a backport is a choice somebody makes rather than an automatic consequence of a fix existing
- Distribution packages, where the version number often bears no relation to upstream and a patched package may carry an unpatched-looking version
- Vendored and bundled components, where an application ships its own copy and upstream's fix reaches you only when the application rebuilds
- Appliances and managed services, where you cannot upgrade at all and the fix arrives when the vendor decides
In every one of those, scanning on version strings produces a wrong answer in one direction or the other, and the advisory's fixed version field is the thing that misleads.
What to do about it
Take this with you
In the order worth doing
- If you run Grav on the 1.7 branch, update to 1.7.53.4 or later. It carries the backport and it is the first 1.7 release that does.
- For every advisory you act on this month, check whether the fixed version named is one you can actually deploy. Where it is a major upgrade or a pre-release, that is an exposure with a project plan attached, not a patch, and it should be tracked as such rather than closed.
- Ask the same question of your long term support branches, because the promise not to move is also a promise that somebody else will backport, and that somebody is often a volunteer.
- Where a component is vendored or bundled inside something you buy, record which upstream version is embedded. That is the number the advisory is about, and it is rarely the number on the product.
- Watch for the pattern where a fix exists only in a branch you are not on. The advisory record makes this visible in one field, and almost no tooling surfaces it: it compares your version to the affected range and reports a yes or a no.
- If you maintain something others depend on, say explicitly in the advisory whether older supported branches will receive the fix, and when. The absence of that sentence is what sends people looking for a release that does not exist.
The question this leaves
It would be comfortable to end on the irony, which is that a ransomware group lost the private keys to its own leak site because it had not patched. The irony is real and it is not the useful part.
The useful part is that the fix for this flaw existed, publicly, in a version control system, for five months, and did not reach the branch that most of the exposed sites were running. Nobody hid it. It was in the advisory, in the record, in a field labelled fixed. It simply did not apply to them, and there is no field for that.
What changed it was not a scanner, a deadline or a regulator. It was somebody exploiting it against a target whose compromise made the news, after which the backport took a day.
So the question for your own patching: when an advisory names a fixed version you cannot deploy, where does that item go, and is there anything in your process that distinguishes it from one you have actually fixed?
Sources
- PrimaryThe machine-readable advisory record for CVE-2026-42608, used for the affected range, the single listed fixed version, the CVSS vector and the componentOSVaccessed 2026-09-26
- PrimaryThe project's own advisory for the same flawGravaccessed 2026-09-26
- PrimaryThe earlier path traversal advisory, CVE-2024-27921, fixed in 1.7.45, used to show that the version in question was behind on a second flaw as wellGravaccessed 2026-09-26
- Reported byReporting of the compromise, used for the version Clop was running, the quoted statement from Grav about the 1.7 line and the release of 1.7.53.4BleepingComputeraccessed 2026-09-26
