TREK’s authentication flow permits an attacker to distinguish valid email addresses from invalid ones by observing response times. When a supplied address exists, the back‑end performs a bcrypt password comparison before returning a 401 Unauthorized, adding roughly 370 ms of latency. If the address does not exist, the system returns in about 10 ms. The ~14× timing disparity can be detected even though HTTP status codes and bodies are identical, enabling enumeration of registered users without any additional information leakage.

This flaw affects all instances of the TREK collaborative travel planner built by mauriceboe running versions earlier than 3.0.18. Versions 3.0.18 and later contain the fix; no other versions are known to be affected.

Based on the description, the likely attack vector is remote access to the publicly exposed authentication endpoint. The attacker only needs to send repeated login attempts with different email addresses to observe the timing discrepancy. The severity is moderate, with a CVSS score of 5.3. Because EPSS is not available and the vulnerability is not flagged in the CISA KEV catalog, the likelihood of exploitation remains uncertain, but user enumeration can facilitate credential stuffing or social engineering.