Grav 1.7 lacked fix for CVE-2026-42608 when Clop's leak site was breached

A fix existed, but not for the branch in use

The Clop ransomware group has moved its data leak site to a new Tor address after the previous server was compromised and defaced through an unpatched flaw in Grav CMS, BleepingComputer reported. The flaw is an unauthenticated path traversal vulnerability, tracked as CVE-2026-42608. The extortion group ShinyHunters carried out the intrusion earlier this month.

The incident matters to organisations for a reason that has little to do with the victim. According to Grav, the vulnerability was privately reported and fixed in Grav 2.0 (2.0.0-beta.2) earlier this year, with an advisory published on April 27. The fix had not been backported to the older Grav 1.7 branch. The compromised server ran Grav 1.7.43.

What happened, according to the sources

ShinyHunters told BleepingComputer it exploited a flaw in Grav's form upload handling. It said the vulnerable code used a value from the __unique_form_id__ POST parameter to build a temporary upload path without first validating it. By supplying directory traversal sequences, the group said, it could make Grav create an upload path outside the intended tmp/forms directory, and the uploaded file could then be written elsewhere under the Grav installation.

Grav told BleepingComputer: "Yes, it's a legitimate flaw, and the threat actor's description is accurate." The vulnerability sits in Grav core rather than the Form plugin, so the Form plugin version does not determine exposure. As Grav put it, "It's the core version that matters."

The gap was the maintenance branch

Clop, asked how the breach occurred, said its Grav installation had not been fully updated. It said: "We didn't update the Grav plugin — though it happened eventually." It disputes ShinyHunters' claim that valuable operational or financial data was taken, saying the server held only content. ShinyHunters claimed on its own leak site that it stole source code, Grav plugins, server logs and the private keys for Clop's Tor onion service. Those claims come from the threat actors and are not independently verified in the reporting.

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 the 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. ShinyHunters' claim to have taken onion service private keys is a reminder that a server described as 'only content' can still hold material that matters.