Summary
A timing side-channel in the login endpoint allows unauthenticated attackers to determine whether a username exists by measuring response time differences. Requests for valid usernames take noticeably longer because the server performs bcrypt password verification, while requests for nonexistent usernames return much faster. This enables reliable remote username enumeration and increases the risk of targeted credential attacks.
Details
The issue affects the login endpoint:
POST /api/auth/token
The root cause is that authentication processing takes different code paths depending on whether the supplied username exists. When the username is found, the server performs bcrypt.CompareHashAndPassword, which adds substantial latency. When the username does not exist, the server returns immediately without performing an equivalent bcrypt operation.
Vulnerable flow:
user, err := db.Where("username = ?", username).First(&user)
if err != nil {
return ErrUnauthorized
}
err = bcrypt.CompareHashAndPassword(user.PasswordHash, []byte(password))
This creates a measurable timing discrepancy between:
- existing username + wrong password requests, which incur bcrypt cost
- nonexistent username + any password requests, which avoid bcrypt entirely
Because no constant-time equalization is performed, the endpoint leaks account existence through timing behavior.
The measurements provided show a large and consistent gap between the two cases across repeated trials, making the difference distinguishable without requiring especially high request volume. In the supplied test results:
- existing user requests averaged about
0.0616s - nonexistent user requests averaged about
0.0027s
That gap is large enough to support reliable username enumeration under typical testing conditions.
PoC
The issue can be reproduced by sending repeated authentication attempts to the login endpoint using the same invalid password while alternating between a known valid username and a nonexistent username, then comparing average response times. Valid usernames consistently take longer because bcrypt verification is performed.
Impact
- Type: Timing side-channel / username enumeration
- Who is impacted: Any deployment exposing the affected login endpoint
- Security impact: Unauthenticated attackers can confirm valid usernames one at a time, improving the effectiveness of credential stuffing, password spraying, phishing, and other targeted account attacks
- Attack preconditions: None beyond network access to the login endpoint
- Confidentiality impact: Low to moderate, depending on the sensitivity of account existence in the target environment
CVE-2026-40263 has a CVSS score of 3.7 (Low). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.19.2-0.20260411145025-cf4c6f6acf70); upgrading removes the vulnerable code path.
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.
Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-40263? CVE-2026-40263 is a low-severity security vulnerability in github.com/enchant97/note-mark/backend (go), affecting versions < 0.19.2-0.20260411145025-cf4c6f6acf70. It is fixed in 0.19.2-0.20260411145025-cf4c6f6acf70.
- How severe is CVE-2026-40263? CVE-2026-40263 has a CVSS score of 3.7 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/enchant97/note-mark/backend are affected by CVE-2026-40263? github.com/enchant97/note-mark/backend (go) versions < 0.19.2-0.20260411145025-cf4c6f6acf70 is affected.
- Is there a fix for CVE-2026-40263? Yes. CVE-2026-40263 is fixed in 0.19.2-0.20260411145025-cf4c6f6acf70. Upgrade to this version or later.
- Is CVE-2026-40263 exploitable, and should I be worried? Whether CVE-2026-40263 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-40263 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-40263? Upgrade
github.com/enchant97/note-mark/backendto 0.19.2-0.20260411145025-cf4c6f6acf70 or later.