GHSA-29HQ-23M2-2J47
Vulnerability from github – Published: 2026-09-22 14:49 – Updated: 2026-09-22 14:49Summary
validateUser() in backend/src/authentication/providers/mysql/auth-provider-mysql.service.ts returns immediately when the supplied login/email does not match any account, without ever calling comparePassword():
async validateUser(loginOrEmail: string, password: string, ip?: string, scope?: AUTH_SCOPE): Promise<UserModel> {
let user: UserModel
try {
user = await this.usersManager.findUser(loginOrEmail, false)
} catch (e) { ... }
if (!user) {
this.logger.warn(...)
return null // <-- comparePassword() is never reached here
}
return await this.usersManager.logUser(user, password, ip, scope)
}
comparePassword() (backend/src/common/functions.ts) already contains a dummy-hash branch that was clearly added to defend against exactly this class of attack:
export async function comparePassword(password: string, hash?: string | null): Promise<boolean> {
if (!hash) {
// No hash, waste time for time-based attacks
await bcrypt.compare(password, DUMMY_PASSWORD_HASH)
return false
}
return await bcrypt.compare(password, hash)
}
The problem is that this protection only runs when comparePassword() is actually invoked with a falsy hash. Because validateUser() short-circuits with return null as soon as findUser() comes back empty, the "account doesn't exist" path skips all cryptographic work entirely, while the "account exists, wrong password" path always performs a real bcrypt comparison (cost factor 10, ~100ms+). The two outcomes are trivially distinguishable by response time.
There's already a published advisory in this repo for "Username Enumeration via Timing Attack" - this looks like the same underlying issue surfacing through a different call path (the early return in validateUser()) that the existing fix (the dummy-hash branch in comparePassword()) doesn't actually reach, rather than a brand new vulnerability class.
Impact
Any unauthenticated client can determine whether a given username/email is a valid account on the instance by timing POST /api/auth/login: - Non-existent login: near-instant rejection (no bcrypt call). - Existing login (regardless of password correctness): consistently slower due to a real bcrypt comparison.
This enables efficient enumeration of valid accounts, which can then be used to focus credential-stuffing, password-spraying, or phishing against confirmed-valid targets.
Proof of Concept
Verified with the actual comparePassword() logic and the real DUMMY_PASSWORD_HASH constant copied verbatim from backend/src/common/functions.ts, using the project's own bcryptjs dependency (no mocking of bcrypt itself):
Avg time for "login does not exist" path (validateUser returns null, no bcrypt call): 0.00 ms
Avg time for "login exists, wrong password" path (real bcrypt.compare runs): 114.90 ms
Difference: 114.90 ms (ratio: ~58923x)
The "not found" path reproduces validateUser()'s exact early return (no call into comparePassword); the "wrong password" path reproduces logUser()'s real call into comparePassword(password, user.password). The gap is large enough to be trivially observable over a real network, even accounting for jitter.
Reachable endpoint: POST /api/auth/login, guarded only by AuthLocalGuard (Passport local strategy invoking validateUser()), no authentication required.
Suggested fix
Make validateUser() always pass through comparePassword()'s timing-equalized path, even when no user is found, e.g.:
if (!user) {
await comparePassword(password, null) // burns the same time as a real comparison
return null
}
so the "account not found" and "account found, wrong password" branches take statistically indistinguishable time.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.4.0"
},
"package": {
"ecosystem": "npm",
"name": "@sync-in/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58272"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T14:49:23Z",
"nvd_published_at": "2026-09-21T21:17:06Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nvalidateUser() in backend/src/authentication/providers/mysql/auth-provider-mysql.service.ts returns immediately when the supplied login/email does not match any account, without ever calling comparePassword():\n\n async validateUser(loginOrEmail: string, password: string, ip?: string, scope?: AUTH_SCOPE): Promise\u003cUserModel\u003e {\n let user: UserModel\n try {\n user = await this.usersManager.findUser(loginOrEmail, false)\n } catch (e) { ... }\n if (!user) {\n this.logger.warn(...)\n return null // \u003c-- comparePassword() is never reached here\n }\n return await this.usersManager.logUser(user, password, ip, scope)\n }\n\ncomparePassword() (backend/src/common/functions.ts) already contains a dummy-hash branch that was clearly added to defend against exactly this class of attack:\n\n export async function comparePassword(password: string, hash?: string | null): Promise\u003cboolean\u003e {\n if (!hash) {\n // No hash, waste time for time-based attacks\n await bcrypt.compare(password, DUMMY_PASSWORD_HASH)\n return false\n }\n return await bcrypt.compare(password, hash)\n }\n\nThe problem is that this protection only runs when comparePassword() is actually invoked with a falsy hash. Because validateUser() short-circuits with return null as soon as findUser() comes back empty, the \"account doesn\u0027t exist\" path skips all cryptographic work entirely, while the \"account exists, wrong password\" path always performs a real bcrypt comparison (cost factor 10, ~100ms+). The two outcomes are trivially distinguishable by response time.\n\nThere\u0027s already a published advisory in this repo for \"Username Enumeration via Timing Attack\" - this looks like the same underlying issue surfacing through a different call path (the early return in validateUser()) that the existing fix (the dummy-hash branch in comparePassword()) doesn\u0027t actually reach, rather than a brand new vulnerability class.\n\n## Impact\n\nAny unauthenticated client can determine whether a given username/email is a valid account on the instance by timing POST /api/auth/login:\n- Non-existent login: near-instant rejection (no bcrypt call).\n- Existing login (regardless of password correctness): consistently slower due to a real bcrypt comparison.\n\nThis enables efficient enumeration of valid accounts, which can then be used to focus credential-stuffing, password-spraying, or phishing against confirmed-valid targets.\n\n## Proof of Concept\n\nVerified with the actual comparePassword() logic and the real DUMMY_PASSWORD_HASH constant copied verbatim from backend/src/common/functions.ts, using the project\u0027s own bcryptjs dependency (no mocking of bcrypt itself):\n\n Avg time for \"login does not exist\" path (validateUser returns null, no bcrypt call): 0.00 ms\n Avg time for \"login exists, wrong password\" path (real bcrypt.compare runs): 114.90 ms\n Difference: 114.90 ms (ratio: ~58923x)\n\nThe \"not found\" path reproduces validateUser()\u0027s exact early return (no call into comparePassword); the \"wrong password\" path reproduces logUser()\u0027s real call into comparePassword(password, user.password). The gap is large enough to be trivially observable over a real network, even accounting for jitter.\n\nReachable endpoint: POST /api/auth/login, guarded only by AuthLocalGuard (Passport local strategy invoking validateUser()), no authentication required.\n\n## Suggested fix\n\nMake validateUser() always pass through comparePassword()\u0027s timing-equalized path, even when no user is found, e.g.:\n\n if (!user) {\n await comparePassword(password, null) // burns the same time as a real comparison\n return null\n }\n\nso the \"account not found\" and \"account found, wrong password\" branches take statistically indistinguishable time.",
"id": "GHSA-29hq-23m2-2j47",
"modified": "2026-09-22T14:49:23Z",
"published": "2026-09-22T14:49:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/security/advisories/GHSA-29hq-23m2-2j47"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58272"
},
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/commit/b80efe04574039a7a302c0e1007f03a7dbe6a633"
},
{
"type": "PACKAGE",
"url": "https://github.com/Sync-in/server"
},
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/releases/tag/v2.4.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Sync-in Server has Username/Login Enumeration via Timing Side-Channel on POST /api/auth/login (incomplete fix of the prior timing-attack advisory)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.