The breach of Clop’s ransomware leak site by rival extortion group ShinyHunters is an unusual example of cybercriminal infrastructure becoming the victim of the same vulnerability-management failures routinely exploited against legitimate organizations. BleepingComputer reports that ShinyHunters compromised Clop’s Tor leak site through an unauthenticated path traversal vulnerability in the Grav content-management system, defaced the site, and claims to have stolen source code, plugins, logs, and the private keys associated with Clop’s onion service. Clop has since moved to a new Tor address and confirmed that its Grav installation had not been fully updated.

The underlying vulnerability is now tracked as CVE-2026-42608. Grav confirmed that the technical description provided by ShinyHunters was accurate. The flaw exists in Grav core and affects file-upload path handling. Specifically, attacker-controlled values supplied through form-related POST parameters could be incorporated into temporary upload directories without first being validated as safe filesystem path components. By inserting directory traversal sequences into the __unique_form_id__ value, an unauthenticated attacker could cause an uploaded file to be written outside the intended tmp/forms directory.

The attack reportedly targeted Clop’s Grav 1.7.43 deployment. ShinyHunters told BleepingComputer it supplied traversal values such as ../../../shhq through the form identifier, causing Grav to construct a path outside the expected upload directory. Once the attacker can influence where an uploaded file is written, the impact depends on the filesystem permissions and web-server configuration, but in a web application environment this can become a powerful primitive for defacement, code placement, or broader server compromise.

Grav says the issue had already been fixed in the Grav 2.0 branch earlier in 2026, with the advisory published on April 27. The fix introduced a sanitizeId() function that restricts identifiers to a tightly controlled allowlist matching [A-Za-z0-9,_-]{1,64}. The more significant problem was that the correction had not been backported to the widely used 1.7 branch, leaving installations such as Clop’s vulnerable even though the flaw was known and addressed in the newer major release.

After BleepingComputer shared the exploitation details with Grav, the developers backported the fix and released Grav 1.7.53.4. Grav is now urging organizations remaining on the 1.7 branch to upgrade to that release, while current 2.x installations have already contained the fix for months. This distinction matters because administrators may incorrectly assume that a maintained older branch has inherited every security correction present in the latest major version. This incident shows why branch-specific patch status must be verified rather than assumed.

The vulnerability is also located in Grav core rather than the Form plugin. Grav specifically clarified this point because ShinyHunters initially referenced the form-upload mechanism and a plugin version. The plugin may provide the path through which the vulnerable core functionality is reached, but changing or updating the Form plugin alone does not remove the underlying issue. The core version is what determines whether the installation remains vulnerable.

From a defensive perspective, this is a useful lesson in path traversal vulnerabilities. These bugs are often described as file-read issues, but when traversal occurs inside an upload workflow the effect can be more dangerous. The attacker is not simply asking the server to read a file from outside the intended directory. They are influencing where attacker-controlled content is written. That can potentially transform a directory-validation mistake into arbitrary file placement, depending on permissions and reachable paths.

The basic exploitation logic is therefore straightforward: unauthenticated form submission → attacker-controlled path component → traversal outside temporary upload directory → attacker-selected file placement → potential application or server compromise. No stolen account or administrator interaction is required for the initial step.

The incident also highlights a broader security problem around legacy branches. Grav had fixed the vulnerability in 2.0, but many installations remained on 1.7. The fact that the security fix had not been backported created a long-lived exposure window for sites that may otherwise have appeared fully updated within their chosen branch. This is why organizations need to distinguish between “latest patch in my branch” and “branch actually contains all relevant security fixes.” The two are not always the same thing.

There is also an operational lesson in Clop’s response. The group confirmed that it had failed to fully update Grav, but disputed ShinyHunters’ claims about the value of the data stolen from the server. Clop says the affected infrastructure contained only website content and no financial or operational data. ShinyHunters, by contrast, claims it obtained source code, Grav plugins, system logs, and Tor onion-service private keys. BleepingComputer independently verified the defacement and initial file upload but has not independently confirmed the full extent of the claimed data theft.

That distinction should remain clear. The compromise itself is confirmed. The vulnerability used is now confirmed by Grav. The defacement is confirmed. But some of ShinyHunters’ more significant claims about stolen logs, source code, and onion private keys remain claims by a criminal group involved in an active dispute.

If the onion private keys were genuinely stolen, the impact would be particularly serious because possession of those keys could potentially allow another party to host a Tor service using the same onion identity. ShinyHunters has claimed exactly that, although BleepingComputer has not independently verified possession of the keys.

The reported theft of logs would also be significant if confirmed. Ransomware and extortion groups depend heavily on operational security to conceal infrastructure, operators, partners, and negotiation activity. Web-server, authentication, and system logs could potentially expose IP addresses, connection patterns, infrastructure relationships, or other metadata. For a criminal group, those records can be considerably more sensitive than the public content displayed on the leak site.

The breach has also escalated an existing dispute between ShinyHunters and Clop. ShinyHunters says the attack was retaliation for threats and disputes dating back to Clop’s 2025 Oracle E-Business Suite campaign. The group subsequently attempted to extort Clop itself, threatening to publish allegedly stolen data if payment was not made. Reuters independently reported the unusually public feud between the two cybercriminal groups, but many details about its origins remain allegations made by the participants themselves.

That makes this incident unusual from a threat-intelligence perspective. Cybercriminal ecosystems are often described as cooperative markets where access brokers, ransomware operators, malware developers, affiliates, and money launderers work together. In reality, those relationships are transactional and fragile. The same actors who collaborate today may steal exploits, infrastructure, victims, or data from one another tomorrow.

For defenders, however, the criminal drama is secondary. The more useful takeaway is that CVE-2026-42608 is a real, exploitable Grav core vulnerability and that systems running the 1.7 branch should be upgraded to 1.7.53.4 or later. Organizations using Grav 2.x should verify that they are on a current release, even though the flaw was fixed in that branch earlier.

Administrators should also review whether their Grav sites accept file uploads through forms, because reachable upload functionality provides the clearest attack surface. Web-server and application logs should be searched for suspicious form submissions containing traversal strings such as ../ or encoded equivalents within parameters associated with upload identifiers.

The __unique_form_id__ parameter deserves particular attention because it was specifically identified in the demonstrated exploit. Requests where this value contains path separators, traversal sequences, unexpected dots, or characters outside Grav’s new allowlist should be treated as suspicious.

Filesystem review is equally important. Administrators should look for recently created files outside Grav’s intended temporary upload directories, particularly in web-accessible locations. Unexpected PHP, HTML, JavaScript, configuration, or executable files appearing around the time of suspicious form submissions may indicate exploitation.

Because the flaw allows attacker-controlled path construction, detection should not rely exclusively on one known filename or upload location. An attacker can choose different paths depending on the permissions and layout of the target environment. The stronger signal is a form upload followed by file creation outside the expected upload tree.

Organizations should also verify whether their web-server account has more filesystem privileges than necessary. Path traversal becomes substantially more damaging when the application process can write broadly across the site or host. Restricting write access to only the directories genuinely needed by the application can limit the impact of future path-handling vulnerabilities.

The incident also reinforces the importance of content-management system inventories. Grav is smaller than WordPress, Drupal, or Joomla, which can make it easier for security teams to overlook. But a less common CMS is not automatically a less valuable target. An exposed administration or upload path still provides attackers with exactly the same opportunity if the underlying code is vulnerable.

The wider lesson is particularly ironic but technically useful: attackers are not immune to the same patching failures they exploit in everyone else. Clop has spent years taking advantage of vulnerable enterprise software, yet its own public infrastructure reportedly remained on a Grav branch missing a known security correction.

The attack chain is almost embarrassingly ordinary:

known vulnerability → legacy branch without backported fix → unauthenticated path traversal → arbitrary upload location → site compromise

No extraordinary zero-day was required.

The broader cybersecurity lesson is therefore not really about one criminal group embarrassing another. It is about security maintenance across software branches.

A vulnerability can be fixed upstream and still remain exploitable for months if that fix never reaches the branch actually deployed in production.

Organizations should therefore ask not only:

“Are we running the latest version available to us?”

but:

“Does the version we are running actually contain the security fix?”

Clop appears to have learned that distinction from ShinyHunters, which is perhaps not the preferred way to conduct vulnerability management.

The Clop ransomware gang has moved its data leak site to a new Tor address after confirming its previous server was compromised and defaced through an unpatched Grav CMS flaw that BleepingComputer has learned is an unauthenticated path traversal vulnerability. [...]

Source: ShinyHunters hacked Clop leak site using Grav CMS path traversal flaw via Bleeping Computer — published 25 Sep 2026.