ShinyHunters says a Grav upload path let it deface Clop's leak site

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][12]. A fetchable file shows the upload path saved attacker-chosen content into a location the web server would hand out ^[1].

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 ^[6]. 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 ^[2]. 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 ^[3]. 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 ^[10]. Whether reads of the private key or the logs left any trace depends on audit settings and on the path the attacker took ^[11].