CVE-2026-40263: 
vulnerability analysis and mitigation

CVE-2026-40263 is a timing side-channel vulnerability in the login endpoint of Note Mark, an open-source note-taking application, that allows unauthenticated attackers to enumerate valid usernames by measuring response time differences. The vulnerability affects Note Mark versions prior to v0.19.2 (Go module github.com/enchant97/note-mark/backend). It was published by the maintainer on April 11, 2026, added to the GitHub Advisory Database on April 13, 2026, and published by NVD on April 17, 2026. It carries a CVSS v3.1 base score of 3.7 (Low) (Github Advisory, Note Mark Advisory).

The root cause is an Observable Timing Discrepancy (CWE-208) in the POST /api/auth/token login endpoint. When a supplied username exists in the database, the server performs a computationally expensive bcrypt.CompareHashAndPassword operation; when the username does not exist, the server returns immediately without performing any equivalent bcrypt operation, creating a measurable latency gap. Test data from the advisory shows existing-user requests averaged ~0.0616s versus ~0.0027s for nonexistent users — a roughly 23x difference that is reliably distinguishable without high request volume. The vulnerable code path is: user, err := db.Where("username = ?", username).First(&user); if err != nil { return ErrUnauthorized }; err = bcrypt.CompareHashAndPassword(user.PasswordHash, []byte(password)) (Github Advisory, Note Mark Advisory).

Successful exploitation allows unauthenticated remote attackers to reliably confirm whether specific usernames exist in a Note Mark deployment, with low confidentiality impact and no integrity or availability impact. This information can be leveraged to improve the effectiveness of follow-on attacks such as credential stuffing, password spraying, and targeted phishing campaigns. The attack requires no privileges and no user interaction, and any deployment exposing the login endpoint over the network is affected (Github Advisory, Note Mark Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation as of the time of writing. The EPSS score is approximately 0.029% (0.000290), placing it in the 13th percentile for exploitation likelihood within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported (Github Advisory).

1. Reconnaissance: Identify internet-facing Note Mark instances running versions prior to v0.19.2 by scanning for the application's login endpoint at POST /api/auth/token.
2. Baseline measurement: Send multiple login requests with a known nonexistent username and any password, recording average response times to establish a baseline (expected ~0.0027s).
3. Username probing: Send repeated login requests substituting candidate usernames (e.g., from a common username wordlist) with the same invalid password, measuring response times for each.
4. Timing analysis: Compare response times against the baseline — usernames that consistently return responses averaging ~0.0616s (or significantly above baseline) are valid accounts, as the server is performing bcrypt verification.
5. Targeted attack: Use the enumerated valid usernames as targets for credential stuffing, password spraying, or phishing campaigns (Github Advisory, Note Mark Advisory).

• Network: High volume of POST /api/auth/token requests from a single IP or small set of IPs, particularly with varying usernames but a consistent (invalid) password; requests with response time patterns alternating between ~0.003s and ~0.06s.
• Logs: Application access logs showing repeated failed authentication attempts cycling through many different usernames; unusual patterns of 401 responses to the /api/auth/token endpoint from the same source.
• Behavioral: Statistically anomalous authentication failure rates against the login endpoint without corresponding successful logins, suggesting automated enumeration rather than legitimate user activity.

Upgrade Note Mark to version v0.19.2 or later, which resolves the issue by ensuring a bcrypt operation is always performed regardless of whether the username exists (commit cf4c6f6). The fix introduces a pre-computed nullPasswordHash and calls IsPasswordMatch even when the user lookup fails, equalizing response times across both code paths. As interim mitigations, operators should implement rate limiting on the login endpoint, enforce account lockout policies after repeated failures, and monitor for anomalous authentication patterns (Note Mark Advisory, Patch Commit).

The vulnerability was discussed briefly on Reddit's r/selfhosted community in the context of the Note Mark v0.19.2 security update release. No significant vendor statements beyond the maintainer's own advisory, nor notable security researcher commentary beyond the credited reporters (QiaoNPC and Across-Verticals-Malaysia), have been identified (Reddit).