Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-55445

CVE-2026-55445: Qinglong Auth Bypass Vulnerability

CVE-2026-55445 is an authentication bypass flaw in Qinglong task management platform that allows attackers to reset admin credentials. This post covers the technical details, affected versions, impact, and mitigation.

Published:

CVE-2026-55445 Overview

CVE-2026-55445 is an authentication bypass vulnerability in Qinglong, a timed task management platform supporting Python3, JavaScript, Shell, and TypeScript. The flaw exists in the init guard middleware in back/loaders/express.ts in versions prior to 2.20.1. The middleware whitelists /api/user/init but does not whitelist /open/user/init, while the path rewrite /open/*/api/$1 executes after JWT authentication and the init guard. An unauthenticated attacker can send a PUT /open/user/init request to reset administrator credentials on an already-initialized instance. The issue is fixed in Qinglong 2.20.1 [CWE-287].

Critical Impact

Unauthenticated remote attackers can reset administrator credentials on any exposed Qinglong instance, leading to full takeover of the task management platform.

Affected Products

  • Qinglong versions prior to 2.20.1
  • Qinglong deployments exposing the /open/* API surface
  • Any initialized Qinglong instance reachable over the network

Discovery Timeline

  • 2026-07-15 - CVE-2026-55445 published to NVD
  • 2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-55445

Vulnerability Analysis

Qinglong exposes two parallel API surfaces: an internal /api/* path used by the web UI and an /open/* path intended for programmatic access with JWT authentication. The Express loader configures a URL rewrite rule that maps /open/* requests to /api/$1 after the JWT middleware and the init guard have already inspected the request. The init guard middleware, which permits unauthenticated access to specific initialization endpoints, only checks whether the requested path matches /api/user/init or /api/user/notification/init. Because the rewrite has not yet fired when the guard evaluates the path, a request to /open/user/init falls through the guard as if it were an unrelated endpoint, and the JWT check is bypassed for whitelisted init flows.

Root Cause

The root cause is inconsistent path normalization between the authentication guard and the rewrite layer. The middleware chain treats /open/user/init and /api/user/init as semantically distinct at authentication time but as equivalent at routing time. This mismatch allows the /open/user/init endpoint to reach the initialization handler without JWT verification, even after the platform has already been initialized.

Attack Vector

An unauthenticated attacker sends a PUT request to /open/user/init on a reachable Qinglong instance. The request bypasses JWT authentication because of the rewrite ordering, and it bypasses the init guard because the guard does not include the /open/* variant in its whitelist. The initialization handler then accepts attacker-supplied administrator credentials and overwrites the existing admin account. The attacker subsequently logs in with the new credentials and gains full control over scheduled tasks, which can execute arbitrary shell, Python, JavaScript, or TypeScript code on the host.

typescript
// Patch from back/loaders/express.ts — commit 6bec52dca158481258315ba0fc2f11206df7b719
app.use(async (req, res, next) => {
    const pathLower = req.path.toLowerCase();
-   if (!['/api/user/init', '/api/user/notification/init'].includes(pathLower)) {
+   if (
+     ![
+       '/api/user/init',
+       '/api/user/notification/init',
+       '/open/user/init',
+       '/open/user/notification/init',
+     ].includes(req.path)
+   ) {
      return next();
    }
    const authInfo =

Source: GitHub Commit 6bec52d

Detection Methods for CVE-2026-55445

Indicators of Compromise

  • HTTP PUT requests to /open/user/init or /open/user/notification/init in web server or reverse-proxy logs.
  • Unexpected administrator credential changes on Qinglong instances that were already initialized.
  • New or modified cron jobs, scripts, or environment variables created shortly after suspicious /open/user/* traffic.
  • Successful admin logins from unfamiliar source IP addresses following an init request.

Detection Strategies

  • Alert on any request path matching /open/user/init regardless of HTTP method, since legitimate traffic to this endpoint on initialized instances is not expected.
  • Correlate init endpoint requests with subsequent authentication events under the admin account to surface credential resets.
  • Review Qinglong audit logs for administrator profile updates that lack a preceding authenticated session.

Monitoring Recommendations

  • Ingest reverse-proxy and Qinglong application logs into a centralized logging platform and retain them for post-incident analysis.
  • Monitor task queue changes and newly registered scripts to identify follow-on abuse after account compromise.
  • Track outbound network connections from Qinglong hosts to identify command-and-control activity initiated through injected tasks.

How to Mitigate CVE-2026-55445

Immediate Actions Required

  • Upgrade Qinglong to version 2.20.1 or later, which corrects the init guard whitelist.
  • Restrict network exposure of Qinglong management interfaces to trusted networks or VPN access only.
  • Rotate administrator credentials and API tokens on any instance that may have been reachable from untrusted networks.
  • Audit scheduled tasks, environment variables, and dependency scripts for unauthorized modifications.

Patch Information

The fix is available in Qinglong 2.20.1. The patch, tracked in GitHub Pull Request #2941 and commit 6bec52d, adds /open/user/init and /open/user/notification/init to the init guard whitelist so that the initialization handler rejects requests on already-initialized instances regardless of the URL prefix. Full disclosure details are available in GitHub Security Advisory GHSA-v667-gc2r-2xm7.

Workarounds

  • Block requests to /open/user/init and /open/user/notification/init at a reverse proxy or web application firewall until the upgrade is applied.
  • Require network-layer authentication such as mutual TLS or an authenticating proxy in front of Qinglong.
  • Bind the Qinglong service to localhost and expose it only through a hardened gateway during the patch window.
bash
# Nginx snippet to block the vulnerable endpoints pre-patch
location ~* ^/open/user/(init|notification/init)$ {
    return 403;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.