TL;DR
- what: ShinyHunters compromised and defaced the Clop ransomware gang's dark web data leak site on Friday, September 19, 2026, using an unauthenticated file upload vulnerability in Grav CMS.
- impact: ShinyHunters claims it took the leak site source code and Grav plugins, system logs from /var/log, and the private cryptographic keys for Clop's Tor onion service, then set a 72 hour deadline and said it intends to extort Clop.
- fix: The source names no patched Grav release or CVE for the upload flaw, so the action for defenders is to inventory every Grav install, upgrade core and plugins to current with bin/gpm, and block PHP execution in writable content directories.
- who: Anyone running a public facing flat file CMS such as Grav outside their patch program, plus Oracle E-Business Suite operators still tracking fallout from the CVE-2025-61882 campaign.
The crew behind one of the most aggressive mass exploitation operations of the last two years spent Friday night watching its own extortion infrastructure get taken apart. On September 19, 2026, ShinyHunters compromised the Clop ransomware operation's dark web data leak site, the page Clop uses to name victims and squeeze them into paying. The way in was not a zero day in a hardened appliance. It was an unauthenticated file upload vulnerability in Grav CMS, the flat file content management system Clop was running its own public site on.
A leak site with a CMS problem
ShinyHunters started small. The first sign of trouble was a single text file dropped onto Clop's site reading "THIS SITE HAS BEEN PWN3D BY SHINYHUNTERES #Skids10p - Maybe don't try to threaten us next time", along with a link back to ShinyHunters' own leak site. Hours later the whole site was gone, replaced with ASCII art of Umbreon, the Pokemon ShinyHunters uses as its logo, above the line "rooting your systems since '19 ;)". BleepingComputer confirmed the defacement. That two stage pattern, prove write access first and come back later for full control, is the classic shape of an unauthenticated upload bug that leads to code execution. It is also the shape you should expect to see in your own web logs.
The grudge started with Oracle E-Business Suite
This was not a random hit. The conflict traces to Clop's October 2025 campaign against Oracle E-Business Suite, which exploited CVE-2025-61882. ShinyHunters claims that exploit was originally theirs and that Clop took it, and says Clop representatives later followed up with violent threats. The defacement message answers that directly. What is on display is a criminal ecosystem doing what it does under pressure, turning on itself, except the property being fought over here is an exploit chain that hit real enterprise ERP deployments and real victim organizations.
The claim versus the confirmation — BleepingComputer verified the defacement of Clop's leak site. It has not independently verified the data theft claims. Read the site compromise as fact and the stolen source code, logs, and onion keys as assertions from an extortion group with an obvious motive to inflate them.
What ShinyHunters says it walked away with
- The leak site source code along with Clop's Grav CMS plugins
- System logs pulled from /var/log, the files most likely to hold operator IP addresses, tooling paths, and access patterns
- The private cryptographic keys for Clop's Tor onion service, the credential that lets whoever holds it stand up a site at Clop's exact onion address
The group gave Clop 72 hours to make contact and said flatly that it is going to extort them. If the onion key claim holds, that is the item that matters. Whoever controls those keys controls the address victims are pointed to, which means a Clop victim negotiating at that onion address can no longer be sure who is on the other end. The logs matter for a different reason: they are exactly what law enforcement wants, and unlike a password, an operator cannot revoke them after the fact.
The RedEye take
The funny part of this story is the smallest part. A gang that built its entire brand on breaking file transfer products and ERP stacks was running its own public infrastructure on a content management system with an unauthenticated upload flaw, and had not fixed it. That is not irony, it is a usable data point about the people on the other side of your incidents. They are operators working under time pressure, and they take the same shortcuts and leave the same forgotten public endpoints your own teams do. Stop modeling ransomware crews as uniformly disciplined, because that assumption inflates their capability and deflates the value of basic hygiene.
The second takeaway is harder. If ShinyHunters is right that Clop lifted the Oracle E-Business Suite chain, then the capability behind CVE-2025-61882 sat in at least two sets of hands before most enterprises had it patched. Exploits move between crews the way tools move between contractors, which makes attribution by exploit a weak signal and makes any defense built on one group's known tooling brittle by design. The third takeaway: the 72 hour countdown is theater. Clop is not going to pay. But if those logs are real, they have a long shelf life, and the people most interested in them do not negotiate over Tor.
What defenders should learn
- Inventory your microsites and marketing CMS installs with the same rigor as production. Clop lost root through a flat file CMS serving a public page, not through a core application. Most enterprises run several of those and cannot name an owner for any of them.
- Treat unauthenticated file upload as a pre-auth code execution class, not a content handling bug. The early stage in this intrusion was a harmless looking text file appearing in a writable web directory, and that is the alert you realistically get before the defacement.
- Rotate service identity keys on a schedule rather than after an incident. Clop's onion private key had no rotation path once it was out the door. Your equivalents are TLS private keys, SSH host keys, code signing keys, and API signing secrets. Pick one today and ask how fast you could actually replace it.
- Assume /var/log is an attacker objective and not only your evidence. Ship logs off host in real time so the surviving copy is the one you control, and so the copy an intruder reads on the box is not a complete map of your operations.
- Do not anchor detections to a single actor's toolkit. The exploit at the center of this feud was contested property between two crews. Behavior based detection survives that kind of hand off. Named actor attribution does not.
The check worth running this week
Grav is a flat file CMS, which means content, uploads, and executable PHP frequently live under the same writable tree. That is what turns an upload primitive into a shell. Find your Grav installs, confirm the core and plugin versions, and look for PHP files that appeared recently in directories that are supposed to hold only content and images.
find /var/www /srv /opt -maxdepth 5 -type f -path '/bin/gpm' 2>/dev/null
bin/gpm version
bin/gpm index -i
find user/pages user/data user/images -type f -name '.php' -newermt '2026-09-01' 2>/dev/null
⚠️ If you find an unexpected PHP file in a content directory — Do not delete it. Move it to a directory outside the web root, preserve timestamps and ownership, and pull the web server access log for every request to that path before and after its creation time. The write is the cheap part of this attack, and the interesting question is what came back for it later.
Originally published on RedEye Threat Intelligence.
Top comments (0)