Ransomware

ShinyHunters hijacked Clop's leak site through Grav CMS

By Yaali. September 28, 2026, 6 min read, Ransomware, Threat intel.

ShinyHunters took over Clop's Tor leak site through CVE-2026-42608, an unpatched Grav CMS flaw. How the bug works and how to check your own Grav sites.

On the night of Friday, September 18, the extortion group ShinyHunters broke into the Tor-hosted leak site of Clop (also written Cl0p), the ransomware gang behind the MOVEit and Oracle E-Business Suite (EBS) data theft campaigns. By the next day the site where Clop names victims who refuse to pay carried ShinyHunters branding and an eight-figure extortion demand aimed at Clop itself. ShinyHunters says it also took Clop's source code, server logs and the private keys for its onion address. None of those theft claims has been verified.

The way in was an ordinary web bug. Clop's site ran Grav, a PHP content management system (CMS) that stores pages and settings as files instead of in a database, on version 1.7.43. That version is exposed to CVE-2026-42608, a flaw in Grav's form handling that needs no login and was fixed in April, but only in the 2.0 line. Grav has since confirmed ShinyHunters' technical description. Any Grav 1.7 site your organisation runs, including forgotten campaign pages, has the same exposure until upgraded.

How it works

Grav forms use a component called FormFlash to keep a visitor's half-finished form data and uploaded files between requests. FormFlash saves that data in a temporary folder whose name is built from identifiers sent in the POST request: the session ID, carried in the __form-flash-id field, and the form's unique ID.

Before the fix, Grav did not check those identifiers. Grav's advisory (GHSA-hmcx-ch82-3fv2) shows a single request to a public contact form with __form-flash-id=../../user/config/proof_dir. The ../ sequences walk up out of the temporary folder, so Grav creates a new directory under user/config/ and writes an index.yaml file with attacker-supplied data inside it. BleepingComputer's reporting on the Clop intrusion describes the same traversal through the __unique_form_id__ field. The fix covers both: it limits the session ID, unique ID and form ID to letters, digits, commas, underscores and hyphens, at most 64 characters.

"Unauthenticated" is the part that matters most. The attacker needs no account and no access to the admin panel, only a page with a form on it, and most Grav sites have one. CVE-2026-42608 scores 9.1 on CVSS 3.1 and 8.8 on CVSS 4.0.

A file write outside the intended folder is usually one step from running code. In a PHP application, an attacker who can place a script where the web server executes it, or change a configuration file the application trusts, can typically get a web shell: a small script that runs whatever command it receives over HTTP. Nobody has published the exact step from file write to full control of Clop's server, so for this case that part remains unconfirmed. Grav's advisory itself lists configuration injection, corruption of other users' session data, and filling the disk.

Grav fixed the bug in 2.0.0-beta.2 on April 24 and published the advisory on April 27, but did not backport it to the 1.7 branch Clop was running. The 1.7.53.4 backport came only after the Clop breach.

What attackers are doing

ShinyHunters first dropped a taunting text file on the site on September 18. On September 19 it defaced the whole site with its Umbreon mascot and a seizure banner; outlets quote it as "Domain seized by ShinyHunters" and "This site has been pwn3d by ShinyHunters". The first demand was 2.333% of ShinyHunters' own claimed net worth, which it put at an eight-figure amount, due in about three days (reports say 66 or 72 hours) and rising every 24 hours without a reply. By September 20 it wanted all the money Clop made from its Oracle EBS campaign, with interest, and by September 21 it had added a demand for a public apology.

The feud is about that campaign. Clop began exploiting CVE-2025-61882, an unauthenticated remote code execution flaw in Oracle EBS, in August 2025 and began mass extortion emails on September 29, 2025. ShinyHunters says the exploit was its own work, and that a Clop member threatened its members with violence.

ShinyHunters' threat is to publish which companies paid Clop during the EBS campaign, how much they paid and the Bitcoin addresses that received the money. That would hurt Clop, whose victims pay partly for silence, and expose organisations that assumed their payment would stay private. If ShinyHunters really holds Clop's onion private keys, it could also run a site at Clop's old address and pressure the same victims with the same data.

On September 21 Clop regained enough control to post a plain text note: "Shiny Hunters we trying to reach you Your email does not work. Come online old platform no email." Clop has since moved to a new onion address and told BleepingComputer the compromised server held "nothing but content". As of September 28, no report says Clop paid, and ShinyHunters has not published the payment records or any proof that it has them.

What to do

Any team running Grav should work through these steps now. The same checks apply, with different paths, to any public-facing CMS that accepts uploads.

1. Find every Grav install. Check the GRAV_VERSION constant in system/defines.php on each site. Anything below 1.7.53.4 on the 1.7 branch, or below 2.0.0-beta.2 on 2.0, is vulnerable.
2. Upgrade. Back up the user/ folder, then run bin/gpm selfupgrade for the core and bin/gpm update for plugins from the site root, as the account that owns the files.
3. If you cannot upgrade today, block POST requests at the web application firewall or reverse proxy when __form-flash-id or __unique_form_id__ contains .., %2e%2e or a slash. Where a site's forms are not essential, disable the form plugin until the upgrade is done.
4. Check whether you were already hit. Look under user/ for folders and index.yaml files that nobody on your team created, and for any .php file under user/pages, user/data or user/images, where only content should live. In access logs, look for POSTs to form pages followed by GETs to new script paths; the traversal itself sits in the request body, so only WAF or proxy logs will show it.
5. Keep scripts from running where they should not. Grav's shipped .htaccess and webserver-configs/nginx.conf deny direct requests to .php, .yaml and similar files under user/. Confirm your live server config still has those rules; a hand-written nginx config may not.
6. Clean up properly if you find anything. Rebuild the site from a known-good copy instead of deleting the shell in place. Then rotate what the web process could read: admin passwords in user/accounts/, SMTP credentials in the email plugin config, and any API keys stored in user/config/.

For upload features in any web application, the same controls apply: an allowlist of extensions checked against the file content, stored file names the server generates itself, uploads kept outside the web root, and no script execution in the upload directory.

Why hiding the server did not help

Clop hosted its site on Tor to hide the server's location, but anyone who can load a page can send the request that exploits it. The same holds for portals behind a VPN and subdomains nobody links to. The onion service's private keys also reportedly sat on the same server as the CMS, so a web bug may have handed over the site's identity along with its content. Keep signing keys, API tokens and database credentials on another host or in a secrets store the web user cannot query.

Our web penetration testing covers this class of bug: unauthenticated form and upload endpoints, traversal in parameters the application trusts, and what an attacker can reach from a single file write. Our attack surface management work finds the forgotten CMS installs before someone else does. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would run the work.

Sources: BleepingComputer, Grav CMS flaw, BleepingComputer, leak site hack, Grav advisory GHSA-hmcx-ch82-3fv2, OSV, CVE-2026-42608, OpenCVE, CVE-2026-42608, The Record, Malwarebytes, SOCRadar, Hackread, The Register, PrivacyNeedle, Help Net Security, CVE-2025-61882.