- BleepingComputer reports a rival group, ShinyHunters, broke into Clop's leak site through CVE-2026-42608, a Grav CMS flaw. Grav had fixed it in 2.x in April but not in the older 1.7 branch.
- Clop's server ran Grav 1.7.43. Grav confirmed the attacker's account was accurate and shipped the 1.7 fix, version 1.7.53.4, only after BleepingComputer passed along the exploit details.
- Ask your team for every CMS instance with its exact version and branch, and check whether a fix exists for that branch, not just for the vendor's latest release.
A fix existed, but not for the branch in use
Clop's ransomware operation is now running its extortion site from a new Tor address, after intruders defaced and knocked out the previous one earlier this month. BleepingComputer reports the entry point was an unauthenticated path traversal bug in Grav CMS, the software behind Clop's leak site, now tracked as CVE-2026-42608. A rival extortion crew, ShinyHunters, says it carried out the break-in.
Why this matters to other organisations has little to do with who the victim was. Grav says it closed this exact hole in its current 2.0 line months ago: the bug was reported privately and patched in release 2.0.0-beta.2, with a public advisory posted April 27. What Grav had not done, by its own account, was carry that patch back into the older 1.7 branch that many of its sites, including Clop's leak site, were still running.
What happened, according to the sources
ShinyHunters told BleepingComputer it took advantage of how Grav's form-upload feature builds temporary file paths. The group said Grav read the value of a POST parameter called __unique_form_id__ and used it directly to construct a folder path, without checking that it was a safe, well-formed identifier first. Feed it a string of directory-traversal characters instead, the group said, and Grav could be steered into creating an upload folder outside its intended tmp/forms location — letting a file land somewhere else inside the Grav installation entirely.
Grav confirmed the account. "Yes, it's a legitimate flaw, and the threat actor's description is accurate," the company told BleepingComputer. It also clarified where the bug actually lives: inside Grav's core code, not the separate Form plugin, meaning that plugin's version number has no bearing on whether a given site is exposed. As Grav put it, "It's the core version that matters."
The gap sat in the older branch
Grav summed up the gap plainly, telling BleepingComputer: "The gap was the 1.7 line." Version 2.0 is the project's current major release, but a substantial number of Grav installations still run on the older 1.7 branch, and the spring patch had never been carried over to it. Only once BleepingComputer passed along the exploitation write-up did Grav's team build and ship that backport, as version 1.7.53.4. Anyone still on a 1.7 build is being told to move to that release; installations already on current 2.x versions have carried the fix since it shipped in the spring.
Clop's own explanation for the breach was similarly plain: its Grav installation had lagged on updates. "We didn't update the Grav plugin — though it happened eventually," the group told BleepingComputer, while rejecting ShinyHunters' claim that anything of operational value was taken — Clop maintains the server held only site content. ShinyHunters, for its part, posted on its own leak site that the intrusion also yielded Clop's source code, its Grav plugin files, server logs, and the private keys tied to Clop's Tor onion address. None of those claims are independently verified in the reporting; they come solely from the attacker.
Why this matters to a budget-holder
This is one incident, and it does not show how often maintenance branches lag behind current releases. What it does show is a specific, checkable condition. A public advisory can describe a fix that exists in a vendor's current major version while the version an organisation actually runs has no fix yet. A dashboard that reports 'advisory published, patch available' may not reflect the branch in production.
WebPulse's framework detection does not cover Grav, so this story draws on no WebPulse scan data. The lesson is not specific to one CMS: it concerns how patch status is measured.
Questions to put to your team
First, ask for an inventory of every content management system instance the organisation runs, including marketing microsites and campaign pages, with the exact core version and release branch of each. Second, ask how advisories are mapped to those branches. The check should be whether a fix exists for the version in use, not whether a fix exists somewhere. Third, for any instance on a branch the vendor treats as older, ask whether a fix has been published for that branch and who owns the follow-up if it has not. Fourth, ask which internet-facing instances accept file uploads or form submissions from unauthenticated visitors, and what secrets, such as keys, credentials and logs, sit on those servers. Even though ShinyHunters' claim to have taken onion service private keys is unverified, it is a reminder worth acting on: a server described as 'only content' can still hold material that matters.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: BleepingComputer.
