“Both vulnerabilities stem from a mismatch between the security middleware's assumptions and the framework's behavior,” Snyk researchers explain.
How CVE-2026-3965 and CVE-2026-4047 chain to remote code execution
Two authentication-bypass flaws in the Qinglong open-source task scheduler — tracked as CVE-2026-3965 and CVE-2026-4047 — can be combined to achieve remote code execution on vulnerable installations. The flaws affect Qinglong versions 2.20.1 and older.
CVE-2026-3965 arises from a misconfigured rewrite rule that maps ‘/open/*’ requests to ‘/api/*’, which unintentionally exposes protected admin endpoints through an unauthenticated path. CVE-2026-4047 comes from an authentication check that treats paths as case-sensitive (for example, requiring ‘/api/’), while the underlying router matches paths case-insensitively; attackers can use mixed-case paths such as ‘/aPi/...’ to bypass authentication and reach protected endpoints.
Snyk frames the root cause succinctly: the authorization middleware assumed certain URL patterns would always be handled one way, while Express.js — the framework used by Qinglong — treated those patterns differently, allowing the two weaknesses to be chained into a single exploitation path.
Observed exploitation and the '.fullgc' cryptominer
Snyk reports exploitation of the two flaws began on February 7, weeks before the security issues were disclosed publicly at the end of February. Qinglong users first noticed the attack when a rogue hidden process named ‘.fullgc’ began consuming between 85% and 100% of CPU on affected systems. The process name was chosen to mimic “Full GC,” an innocuous but resource-intensive system operation, to reduce the chance of detection.
According to Snyk, attackers exploited the vulnerabilities to modify Qinglong’s config.sh and inject shell commands that downloaded a miner to ‘/ql/data/db/.fullgc’ and executed it in the background. The remote host serving the binaries was located at file.551911.xyz and hosted multiple variants of the miner, including builds for Linux x86_64, ARM64, and macOS.
Confirmed infections occurred across a variety of deployments, including ones running behind Nginx and SSL, indicating that the flaws allowed attackers to reach Qinglong’s protected functionality even in setups with reverse proxies and TLS termination.
Response timeline: maintainers, mitigations, and the effective fix
The Qinglong maintainers responded to the unfolding incident on March 1, acknowledging the vulnerability and urging users to install the latest update. An initial mitigation implemented in pull request #2924 focused on blocking command-injection patterns, but Snyk judged that change insufficient to close the authentication bypass exploited in the wild.
Snyk identifies pull request #2941 as the effective fix: that change corrected the authentication bypass in the middleware, addressing the mismatch between the authorization logic and routing behavior that allowed unauthenticated requests to reach admin endpoints.
What this means for Qinglong maintainers, developers, and end users
- Qinglong maintainers: The maintainers acknowledged the issue publicly and issued updates; the sequence of PRs shows an initial pattern-based mitigation followed by a targeted middleware correction (PR #2941). The record in this incident highlights the importance of aligning middleware assumptions with framework routing semantics.
- Developers and sysadmins running Qinglong installations: Exposed, publicly reachable Qinglong panels running versions 2.20.1 and older were actively exploited beginning February 7. Admins should verify whether their instances were upgraded to include the middleware fix in PR #2941 and must inspect config.sh and the ‘/ql/data/db’ directory for unauthorized changes such as a ‘.fullgc’ binary.
- End users and service owners hosting Qinglong panels: Because attackers were able to deploy miners even behind Nginx and SSL, having a reverse proxy or TLS alone did not block this exploitation chain. Any publicly accessible Qinglong panel should be assumed at risk until the corrected middleware is installed and system integrity is verified.
Qinglong’s popularity — the project has been forked more than 3,200 times and has over 19,000 stars on GitHub — means these vulnerabilities had a wide potential attack surface. The documented timeline shows exploitation began before public disclosure and that an initial fix addressing command-injection patterns did not fully remediate the issue; the corrective middleware change in PR #2941 ultimately closed the authentication bypass.
The concrete open question from the record is simple and consequential: how many publicly exposed Qinglong panels remained unpatched after PR #2941, and how many of those panels had their config.sh or database directories altered before maintainers issued the acknowledgment on March 1?
