EUVD-2026-33070Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Lifecycle Timeline
2DescriptionGitHub Advisory
TREK is a collaborative travel planner. Prior to 3.0.18, early return on missing user during login flow allowed an attacker to enumerate valid user accounts via response timing discrepancy. When an email address existed in the database, the backend performed a bcrypt password comparison before returning a 401 Unauthorized, adding ~370 ms of latency. When the email did not exist, the backend returned immediately (~10 ms). This ~14× timing difference could be detected without any difference in HTTP status codes or response bodies. This vulnerability is fixed in 3.0.18.
AnalysisAI
Timing-based user account enumeration in TREK collaborative travel planner (prior to 3.0.18) leaks the existence of registered email addresses through measurable login response latency. When an email exists in the database, the backend performs a bcrypt password comparison before returning HTTP 401, adding approximately 370 ms of latency; when the email does not exist, the backend returns immediately in approximately 10 ms - a ~14× discrepancy that is reliably detectable despite identical HTTP status codes and response bodies. CVSS AV:N/AC:L/PR:N/UI:N confirms remote unauthenticated exploitation with no special configuration required; no public exploit identified at time of analysis and this CVE is not listed in CISA KEV.
Technical ContextAI
CWE-203 (Observable Discrepancy) describes side-channel leakage through differences in system behavior observable to an external party. The root cause is an early-return code path in TREK's login flow: when a submitted email is absent from the database, the application short-circuits and returns a 401 without invoking bcrypt, whose intentional computational cost (~370 ms) is what makes password hashing resistant to brute force. The absence of a constant-time dummy bcrypt evaluation for missing accounts transforms bcrypt's protective cost asymmetry into an enumeration oracle. No CPE string was provided in the source data; the affected software is the TREK open-source collaborative travel planner hosted under github.com/mauriceboe/TREK. The referenced GitHub Security Advisory GHSA-3552-3c98-x79r is the primary authoritative source.
RemediationAI
Upgrade TREK to version 3.0.18 or later, which is confirmed by the GitHub Security Advisory GHSA-3552-3c98-x79r as the release containing the fix. The standard remediation for CWE-203 timing discrepancies in login flows is to perform a dummy bcrypt hash evaluation even when the submitted email is not found in the database, ensuring constant response time regardless of account existence. If immediate upgrade is not feasible, operators can partially mitigate enumeration risk by introducing artificial response-time normalization at the application or reverse-proxy layer (e.g., enforcing a minimum response delay of ~400 ms for all login responses), though this introduces latency for all users and does not eliminate the root cause. Rate-limiting the login endpoint per source IP reduces enumeration throughput but does not close the timing channel. The advisory and fix are available at https://github.com/mauriceboe/TREK/security/advisories/GHSA-3552-3c98-x79r.
Same weakness CWE-203 – Observable Discrepancy
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today