ShinyHunters says a Grav upload path let it deface Clop's leak site
BleepingComputer confirmed the attacker's text file and the defaced page on Clop's existing onion address. The full server access, the stolen source code and the Tor private key are still ShinyHunters' own account of it.
The Engineer · Build desk
What happened
- ShinyHunters said it exploited an unauthenticated file upload vulnerability in the Grav CMS running Clop's Tor leak site, and used an upload path in the public web application to get in remotely.
- Visitors to the leak site found its content replaced by the ShinyHunters logo and message, and could directly retrieve the unauthorized text file the attackers say they uploaded.
- The crew claimed full access to the server plus theft of source code, Grav plugins, logs under /var/log and the Tor onion service private key, none of which has been independently verified.
- ShinyHunters demanded that Clop contact it within 72 hours, indicating an intent to extort the ransomware gang with the material it says it took.
Why it matters
- What's now possible capability If the stolen onion service private key is valid, ShinyHunters can answer for the same .onion address from hardware it controls, so a visitor hitting that address could be reaching either operator's server.
- What it limits constraint Anyone tracking Clop from the outside is now working without host attribution: the confirmation stops at what the address served, so monitoring built on the address cannot say which machine produced the page.
- Who has to decide decision Until a version is named, the work for Grav operators is to inventory unauthenticated upload endpoints and disable the reachable ones.
- Who's exposed exposure Whether a compromised site can ever prove its keys and logs were read is decided by audit settings chosen long before the incident. Most installs cannot answer the question afterwards.
Next story · Security · Oct 8
Silent Ransom Group sent recruited 'agents' into US law firm offices, leaked chats showConfirmed2 publishers
An unauthenticated upload endpoint is a write primitive before it is anything else. What BleepingComputer verified in its 19 September report fits that and stops there: the attacker's text file could be fetched directly from Clop's existing onion address [2][10]. A fetchable file shows the upload path saved attacker-chosen content into a location the web server would hand out [13].
Everything past that needs another step. According to the writeup, reaching full server access requires code execution or file overwriting through the upload feature, or a separate vulnerability or misconfiguration, and the exact path has not been published [7]. Clop's threat model apparently covered its victims' web applications and not its own [1].
Two artifacts were confirmed by BleepingComputer, the retrievable file and the defaced page, against four that rest on ShinyHunters' statements: server access, source code and Grav plugins, logs under /var/log, and the onion service private key [16]. BleepingComputer also did not establish whether the defaced page came from the original server or from a different server using stolen private keys [3]. I would treat the key theft as unproven and plan as though it happened.
For anyone running Grav in public, the remediation in the writeup is a list of properties the upload path should have had: authentication and authorization checks, extension, MIME type and content validation, a controlled storage destination, and an upload area that cannot execute and sits outside public content [8]. That last property is the one that decides this case. A file written outside the served tree is not retrievable over the site [14]. The writeup also tells operators to identify the vulnerable core or plugin, the vulnerable endpoint and version, disable the path and apply official patches, and it says public information does not specify the targeted and fixed versions [9].
So the practical work is endpoint inventory. Which upload routes in your Grav install answer without a session, and where do they write.
The indicators listed are the ordinary ones: unexpected uploaded files, changes to public content, abnormal requests to Grav CMS, and changes to file ownership or modification times [11]. Whether reads of the private key or the logs left any trace depends on audit settings and on the path the attacker took [12].
What to watch
- Whether Clop's leak site moves to a new onion address. A move would suggest its operators no longer trust the old service key.
- Whether a specific Grav core or plugin version and an official fix get named for the upload path ShinyHunters says it used.
- Whether ShinyHunters publishes the source code and /var/log material after the 72-hour deadline it set.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence45
- Adoption
- Not scored
- Hype gap+30
- Incentives75
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
ShinyHunters stated that they exploited an unauthenticated file upload vulnerability in Grav CMS running on Clop's Tor leak site.
- [2]
The attackers stated they placed a small text file containing a message and a link to their own leak site, and BleepingComputer confirmed that this file could be directly retrieved from Clop's existing onion address.
- [3]
Hours later a page displaying the ShinyHunters logo and message went live on Clop's existing onion address; BleepingComputer confirmed this defacement but did not verify whether it was served from the original server or a separate server using stolen private keys.
- [4]
The attackers demanded that Clop contact them within 72 hours, indicating an intent to extort them using the allegedly stolen information.
- [5]
If ShinyHunters' claims are correct and the private key is valid, the attackers could operate the same onion address on a separate server.
- [6]
Visitors see the content of Clop's leak site replaced by the ShinyHunters logo and message and can directly access the unauthorized text file.
- [7]
Progressing to full access, as claimed by the attackers, requires code execution or file overwriting via the upload feature, or another vulnerability or misconfiguration; the exact path has not been published.
- [8]
The recommended upload process validates authentication, authorization, extensions, MIME types, content, and storage destinations, and isolates the upload area so that it cannot be executed and is separated from public content.
- [9]
Remediation guidance is to identify the vulnerable Grav CMS core or plugin, vulnerable endpoints and versions, disable the relevant path and apply available official patches; public information does not specify the targeted and fixed versions.
- [10]
The BleepingComputer report on the incident was published on 19 September 2026.
- [11]
Indicators for administrators include unexpected uploaded files, changes to public content, abnormal requests to Grav CMS, and changes to file ownership or modification times.
- [12]
Whether traces of private key or log reading remain depends on audit settings and the attack path.
- [13]
The confirmed retrievable file shows only that the upload path wrote attacker-chosen content into a location served over the onion site; it does not show code execution.
- [14]
An upload area separated from public content, the control named in the writeup, would have kept the attacker's text file from being retrievable over the site.
- [15]
ShinyHunters claimed to have gained full access to the server and stolen source code, Grav CMS plugins, logs under /var/log, and the Tor onion service private key; these claims have not been independently verified.
- [16]
Two outcomes in this incident were confirmed by BleepingComputer, the retrievable text file and the defaced page, while four rest on ShinyHunters' statements: full server access, source code and Grav plugins, logs under /var/log, and the onion service private key.
Sources
2 independent publishers whose own reporting we read for this story.
- dev.toShinyHunters Hacks Clop Leak Site: Claims an Unauthenticated File Upload Led to Tor Private Key Theft
2 articles · September 20, 2026
- runtimewire.comShinyHunters hijacks Cl0p's leak site and demands an eight-figure payment
1 article · September 21, 2026
Topics and entities
Topics
- Cyber Extortion
- File Upload Vulnerabilities
- Ransomware leak sites
Entities
- BleepingComputer
- ShinyHunters
- Tor onion services
- Clop
- Recorded Future News