ShinyHunters breaches Clop’s leak site through a Grav CMS path traversal flaw
On September 25, 2026, BleepingComputer confirmed that the ShinyHunters gang compromised the Clop ransomware leak site by exploiting CVE-2026-42608, an unauthenticated path traversal in Grav fixed in April but never backported to the 1.7 branch. If you still run Grav 1.7, upgrade to 1.7.53.4 without delay.
April 2026. Grav privately fixes an unauthenticated path traversal in Grav 2.0, tracked as CVE-2026-42608. Early September 2026. The ShinyHunters gang exploits that same flaw to deface the Clop ransomware leak site. September 24, 2026. Grav finally backports the fix to the 1.7 branch with version 1.7.53.4. Why it matters: even ransomware operators run an outdated CMS — and the gap between the fix and its backport left a five-month window open.
One ransomware gang defaces another
The affair has the look of a settlement between criminal groups. Clop’s leak site, hosted on Tor, was breached earlier in September by ShinyHunters, a known extortion gang. ShinyHunters first uploaded a small text file, then replaced the site with a full-page defacement bearing its Umbreon Pokémon logo and a link to its own leak site.
The gang claims to have stolen the source code, Grav plugins, server logs, and the private keys of Clop’s onion service, and attached a ransom demand, threatening to publish the files if Clop did not pay. Clop has since announced a new onion address, while denying any contact with ShinyHunters: “We do not know them, we have never worked with them, and we are not in contact with them.” On substance, the Russian gang disputes the value of the haul: “the server contained nothing but content,” it claims, with no financial activity or exploitable data.
The defacement itself was a statement. ShinyHunters replaced Clop’s leak site with its own branding — the Umbreon Pokémon logo and a link to its own extortion portal — turning the tool Clop uses to pressure victims into a billboard for a rival. It is a reminder that a leak site is infrastructure like any other, and its own security posture is part of the gang’s credibility.
The flaw: a form identifier allowed to escape its folder
The vector is a brutally ordinary path traversal, located in Grav’s core rather than the Form plugin, as Grav clarified. When a file is uploaded, the CMS builds a temporary directory from values supplied by POST parameters, without validating them as safe filesystem path components.
The parameter at fault is unique_form_id. Its value is inserted into a path shaped like tmp/forms/<session_id>/<unique_id>. ShinyHunters demonstrated that by supplying traversal sequences — ../../../shhq — for that identifier, one can force Grav to create the upload directory outside tmp/forms, then write the uploaded file elsewhere under the CMS installation. BleepingComputer passed the technical details to Grav, which confirmed the description word for word: “Yes, it’s a legitimate flaw, and the threat actor’s description is accurate.”
The fix amounts to a single function: sanitizeId(), which now only accepts identifiers matching the allowlist [A-Za-z0-9,_-]{1,64}. Any character outside that set — including the dots and slashes that compose a traversal — is rejected before it enters the path.
An April fix, backported in September
The timeline is the lesson of the affair. Grav fixed the flaw earlier in the year in Grav 2.0 (version 2.0.0-beta.2), with an advisory published on April 27. But the fix was not backported to the 1.7 branch, still widely deployed. Clop’s site ran Grav 1.7.43 — a vulnerable version, even though the 2.x branch had been protected for months.
“The gap was the 1.7 line,” Grav told BleepingComputer. “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.” Only after BleepingComputer shared the exploitation details did Grav backport the fix and publish Grav 1.7.53.4 on September 24. The exposure window, between the April advisory and the backport, therefore approaches five months.
The number that matters is not the severity of the flaw — an unauthenticated path traversal, exploitable without an account — but the speed of the backport. Most production Grav sites are not on the latest major version; for them, the April fix simply did not exist.
The irony was lost on no one. Clop, the gang that built its name on the 2023 MOVEit exploitation and the extortion of thousands of organizations, fell victim to the very method it applies to others. The group has since removed ShinyHunters from its own leak site — a move that, according to BleepingComputer, usually happens when negotiations are underway, even though ShinyHunters declined to comment. The operational lesson is brutal: nobody, not even ransomware operators, is safe from an unbackported patch.
What the affair says about update debt
The paradox is instructive: Clop, which lives by extorting poorly patched organizations, was itself compromised by the same negligence it exploits in others — a Grav installation not fully up to date. Clop admitted it plainly: “We didn’t update the Grav plugin — though it happened eventually — but the server contained nothing but content.”
The lesson goes beyond the criminal case. Grav’s 1.7 branch is typical of software whose maintenance effectively stops when the next major version ships, while a large base keeps using it. When a security fix is not backported, publishing the advisory becomes a roadmap for attackers: it describes the flaw and points at the vulnerable population, without offering them a remedy. That is exactly what happened here.
The traversal, step by step
To understand why the flaw is so easy to exploit, follow the file’s path. When a Grav form receives an upload, the CMS builds a temporary directory of the shape tmp/forms/<session_id>/<unique_id>. The unique_id value comes from the unique_form_id parameter, sent by the client. As long as that value is a clean identifier, the file lands in tmp/forms, where it belongs.
The bug: Grav 1.7 never checked that the value was a safe path component. By sending ../../../shhq as the identifier, the attacker climbs three levels up the tree and forces the directory to be created outside tmp/forms. The uploaded file is then written at that arbitrary location, under the installation root. From there, dropping a webshell or overwriting a configuration file becomes a matter of a few requests.
Grav’s fix is exemplary in its simplicity: the sanitizeId() function now accepts only identifiers shaped like [A-Za-z0-9,_-]{1,64}. No dot, no slash, no traversal sequence. It is exactly the kind of fix you would want backported immediately — and precisely what was missing for five months.
Verdict
If you run a site on Grav 1.7, upgrade to 1.7.53.4 immediately: the flaw is unauthenticated, publicly documented since April, and already exploited in the wild. If you are on Grav 2.x, you have been protected for months — but check your version anyway, since the fix only reached the 2.0 line in 2.0.0-beta.2. If you maintain software with multiple branches, take the structural lesson: a fix published without a backport to the branches still in deployment is a fix half-delivered, and the advisory that accompanies it becomes an attack manual.