ShinyHunters tumba la web de filtraciones de Clop con un fallo de Grav sin parchear
El grupo de extorsión aprovechó una vulnerabilidad de path traversal en Grav CMS 1.7.43 para desfigurar el sitio. Clop ya ha estrenado dirección .onion.
ShinyHunters ha dejado fuera de juego la web de filtraciones de Clop aprovechando un fallo de path traversal que la instalación de Grav CMS de Clop tenía sin actualizar. El grupo subió primero un fichero de texto y después una página entera con su logotipo de Umbreon y un enlace a su propio sitio. Clop ha cambiado de dirección Tor y sostiene que en el servidor comprometido no había nada que valga la pena.
El asalto ocurrió a principios de mes. ShinyHunters afirmó en su propia web que se había llevado código fuente, plugins de Grav, registros del servidor y las claves privadas del servicio onion de Clop, y acompañó la reivindicación con una petición de rescate. Clop niega cualquier vínculo con ellos: "No les conocemos, nunca hemos trabajado con ellos y ahora mismo no estamos en contacto; tampoco les hemos dado información ni se la vamos a dar, ni ahora ni después". Sobre lo robado, la banda rusa es igual de tajante: el servidor solo tenía contenido, dice, así que la lista de botín de ShinyHunters no vale nada. Lo cierto es que Clop desapareció de la web de ShinyHunters poco después, algo que suele ocurrir cuando hay una negociación en marcha. Preguntados por esa retirada, desde ShinyHunters no quisieron dar más explicaciones.
El fallo: CVE-2026-42608
Grav ha confirmado que la descripción técnica que ShinyHunters trasladó es correcta. El servidor corría la versión 1.7.43 y el vector era un fallo de subida de ficheros sin autenticar en el manejo de formularios. El parámetro __unique_form_id__ se incorporaba a una ruta temporal del tipo tmp/forms/<session_id>/<unique_id> sin comprobar antes que fuera un componente de ruta seguro. Metiendo secuencias de traversal como ../../../shhq en ese identificador, Grav creaba el directorio de subida fuera de tmp/forms y el fichero acababa escrito en cualquier punto bajo la instalación.
La vulnerabilidad está registrada como CVE-2026-42608. Se reportó en privado y se corrigió en Grav 2.0 (2.0.0-beta.2) a principios de año, con el aviso publicado el 27 de abril. El arreglo añade una función sanitizeId() que solo acepta identificadores que casan con la lista blanca [A-Za-z0-9,_-]{1,64}, exactamente la mitigación que describía el atacante.
El problema es que ese parche nunca llegó a la rama 1.7. "El hueco era la línea 1.7", reconocen desde el proyecto. Después de recibir los detalles de la explotación, los desarrolladores lo han portado y han publicado la 1.7.53.4. Grav insiste además en un matiz que importa a la hora de inventariar sitios: el fallo está en el núcleo, no en el plugin Form, así que la versión de ese plugin no determina si un sitio es vulnerable. Lo que cuenta es la del núcleo.
Quien tenga Grav 1.7 en producción tiene deberes: actualizar a 1.7.53.4. Las versiones 2.x llevan meses protegidas. Y el resto puede sacar una lectura de higiene: los dos grupos se han estado atacando con el mismo tipo de fallo de manual, un CMS accesible desde fuera y sin actualizar. No hubo nada exótico en el vector, solo una rama antigua que nadie miraba.
