CVE-2026-77582

### Summary It's possible to enumerate users through a timing oracle. In other words: I can easily check if a username exists or not by observing the timing differences between logins. ### PoC Setup a tinyauth server with a local user. It can be over the network. Try to log in with the local user, using an incorrect password: there is a noticeable delay. You know that the user exists. Now try to log in with a username that does not exist, using an incorrect password: it will complete almost immediately. You know that the user does not exist. ### Expected vs actual behavior Login attempts should take roughly the same amount of time when the user exists vs when the user does not exist. Right now, nonexistent user attempts are way faster, meaning if your login attempt is slow, then the username exists for sure. ### Details Existing usernames will take an extra ~50 milliseconds to respond to login attempts, while non-existing usernames will take only ~50 microseconds (1000x less time) to return an incorrect password response. Even taking network traffic into consideration, it is trivial to check whether a local user exists or not. === Existing user, wrong password === #1: 50.52ms #2: 46.24ms #3: 43.57ms === Nonexistent user === #1: 43.03µs #2: 48.45µs #3: 59.33µs ### Suggested fix This can be solved by checking a dummy password hash when a user is not found before returning a query, this will mimic the exact same delay irrelevant of hardware capabilities. Potential patch: ``` From ca102773e0303f6025480efb26db379e3570a350 Mon Sep 17 00:00:00 2001 From: Disyer <[email protected]> Date: Tue, 14 Jul 2026 12:35:07 +0300 Subject: [PATCH] fix: prevent user enumeration by means of timing attack --- internal/controller/user_controller.go | 1 + internal/middleware/context_middleware.go | 1 + internal/service/auth_service.go | 10 ++++++++++ 3 files changed, 12 insertions(+) diff --git a/internal/controller/user_controller.go b/internal/co