Summary
Qinglong has an incomplete fix for CVE-2026-3965: Improper Authentication
The init guard middleware in Qinglong only checks /api/user/init paths but not /open/user/init, which is whitelisted from JWT authentication and rewritten to /api/user/init after the guard has already passed, allowing unauthenticated admin credential reset on initialized instances.
Affected Package
- Ecosystem: npm
- Package: whyour/qinglong
- Affected versions: < 6bec52dca158
- Patched versions: >= 6bec52dca158
Severity
Medium
CWE
CWE-287, Improper Authentication
Details
The Qinglong panel has an initialization endpoint (/api/user/init) that allows setting admin credentials. Once the system is initialized, an init guard middleware is supposed to block further calls. The middleware in back/loaders/express.ts only checks:
!['/api/user/init', '/api/user/notification/init'].includes(pathLower)
However, the application also has a URL rewrite rule: rewrite('/open/*', '/api/$1'). The /open/* paths are whitelisted from JWT authentication.
The middleware ordering creates the bypass: first, JWT auth sees /open/* paths match the whitelist regex and skips authentication. Second, the init guard only checks for /api/user/init -- /open/user/init passes through as "not an init path". Third, the URL rewrite transforms /open/user/init to /api/user/init after the guard has already passed.
This means an unauthenticated attacker can send PUT /open/user/init with new credentials to reset the admin account on any Qinglong panel instance, gaining full administrative access.
PoC
/**
* CVE-2026-3965 - Qinglong Panel /open/user/init Auth Bypass
*
* The init guard middleware only checks /api/user/init paths.
* But /open/user/init is whitelisted from JWT auth and rewritten
* to /api/user/init via express-urlrewrite AFTER the guard.
*/
"use strict";
// Simulate the init guard middleware exactly as in the source
function initGuardMiddleware(reqPath, authInfo) {
const pathLower = reqPath.toLowerCase();
// Exact check from the vulnerable source
if (!['/api/user/init', '/api/user/notification/init'].includes(pathLower)) {
return { action: "next" }; // passes through
}
let isInitialized = true;
if (
Object.keys(authInfo).length === 2 &&
authInfo.username === 'admin' &&
authInfo.password === 'admin'
) {
isInitialized = false;
}
if (isInitialized) {
return { action: "block", code: 450, message: "Error" };
} else {
return { action: "next" };
}
}
const authInfo = { username: "realAdmin", password: "str0ngP@ss!" };
console.log("System state: initialized (non-default credentials)");
// Test 1: Direct /api/user/init is blocked
const test1 = initGuardMiddleware("/api/user/init", authInfo);
console.log("\n[Test 1] PUT /api/user/init:");
console.log(" Guard result:", test1.action);
console.log(" Blocked:", test1.action === "block");
// Test 2: /open/user/init BYPASSES init guard
const test2 = initGuardMiddleware("/open/user/init", authInfo);
console.log("\n[Test 2] PUT /open/user/init:");
console.log(" Guard result:", test2.action);
console.log(" Bypassed guard:", test2.action === "next");
if (test2.action === "next") {
const rewrittenPath = "/open/user/init".replace(/^\/open\//, "/api/");
console.log(" After rewrite:", rewrittenPath);
console.log(" Reaches init handler: true");
}
if (test1.action === "block" && test2.action === "next") {
console.log("\nVULNERABILITY CONFIRMED: /open/user/init bypasses the init guard");
console.log("An attacker can reset admin credentials on an initialized instance.");
process.exit(0);
} else {
console.log("\nVULNERABILITY NOT CONFIRMED");
process.exit(1);
}
Steps to reproduce:
git clone https://github.com/whyour/qinglong /tmp/qinglong_testcd /tmp/qinglong_test && git checkout 6bec52dc~1node poc.js
Expected output:
VULNERABILITY CONFIRMED
/open/user/init bypasses the init guard; the guard only checks /api/user/init but /open/ path is whitelisted and rewritten after.
Suggested Remediation
Add /open/user/init and /open/user/notification/init to the init guard check list. Alternatively, move the URL rewrite middleware to run before the init guard. Consider implementing the init guard at the handler level rather than as path-based middleware.
References
- Incomplete fix commit: https://github.com/whyour/qinglong/commit/6bec52dca158481258315ba0fc2f11206df7b719
- Original CVE: CVE-2026-3965
Impact
An unauthenticated attacker can send PUT /open/user/init with new credentials to reset the admin account on any Qinglong panel instance. This provides full administrative access, enabling the attacker to execute arbitrary cron jobs and scripts on the server.
The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-55445? CVE-2026-55445 is a critical-severity improper authentication vulnerability in @whyour/qinglong (npm), affecting versions < 2.20.1. It is fixed in 2.20.1. The application does not adequately verify the identity of a user, device, or process before granting access.
- Which versions of @whyour/qinglong are affected by CVE-2026-55445? @whyour/qinglong (npm) versions < 2.20.1 is affected.
- Is there a fix for CVE-2026-55445? Yes. CVE-2026-55445 is fixed in 2.20.1. Upgrade to this version or later.
- Is CVE-2026-55445 exploitable, and should I be worried? Whether CVE-2026-55445 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-55445 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-55445? Upgrade
@whyour/qinglongto 2.20.1 or later.