Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

Tinyauth: User enumeration attack by timing oracleGHSA-456h-ww26-f758

Fix: tinyauthapp/tinyauth#1004

GHSA-456h-ww26-f758 is a CWE-208 vulnerability in github.com/tinyauthapp/tinyauth. A fix is available for github.com/tinyauthapp/tinyauth — see the affected versions and patch details below.

Also known asCVE-2026-77582GO-2026-6555
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-456h-ww26-f758.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs41th percentile — riskier than 41% of all scored CVEsHighest risk
0.00%0.33%0.65%0.98%0.5%0.5%Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐹github.com/tinyauthapp/tinyauth

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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/controller/user_controller.go
index ae6c23b..2ecc996 100644
--- a/internal/controller/user_controller.go
+++ b/internal/controller/user_controller.go
@@ -90,6 +90,7 @@ func (controller *UserController) loginHandler(c *gin.Context) {
 
        if err != nil {
                if errors.Is(err, service.ErrUserNotFound) {
+                       controller.auth.DummyCheckPassword(req.Password)
                        controller.log.App.Warn().Str("username", req.Username).Msg("User not found during login attempt")
                        controller.auth.RecordLoginAttempt(req.Username, false)
                        controller.log.AuditLoginFailure(req.Username, "unknown", c.ClientIP(), "user not found")
diff --git a/internal/middleware/context_middleware.go b/internal/middleware/context_middleware.go
index f49c85a..f70c9e7 100644
--- a/internal/middleware/context_middleware.go
+++ b/internal/middleware/context_middleware.go
@@ -244,6 +244,7 @@ func (m *ContextMiddleware) basicAuth(username string, password string) (*model.
        search, err := m.auth.SearchUser(username)
 
        if err != nil {
+               m.auth.DummyCheckPassword(password)
                return nil, nil, fmt.Errorf("error searching for user: %w", err)
        }
 
diff --git a/internal/service/auth_service.go b/internal/service/auth_service.go
index eeb5c8e..9cbc105 100644
--- a/internal/service/auth_service.go
+++ b/internal/service/auth_service.go
@@ -28,6 +28,10 @@ import (
 const MaxOAuthPendingSessions = 256
 const OAuthCleanupCount = 16
 
+// a dummy hash to check when a user is not found, to prevent user enumeration
+// hardcoded to prevent having to generate a hash on every startup
+const dummyHash = "$2a$10$iFQ6./j2a.UShYQOzWh4vOlnoze5DmHI3tRY3WU4YMj3zwp.t3TnO"
+
 var (
        ErrUserNotFound = errors.New("user not found")
 )
@@ -204,6 +208,12 @@ func (auth *AuthService) CheckUserPassword(search model.UserSearch, password str
        return errors.New("user authentication failed")
 }
 
+func (auth *AuthService) DummyCheckPassword(password string) {
+       // When a user is not found, we still want to perform a password check to prevent
+       // timing attacks that could reveal whether a user exists or not
+       bcrypt.CompareHashAndPassword([]byte(dummyHash), []byte(password))
+}
+
 func (auth *AuthService) GetLocalUser(username string) *model.LocalUser {
        if auth.runtime.LocalUsers == nil {
                return nil
-- 
2.55.0

After testing the proposed fix, there is no discernible timing difference:

=== Existing user, wrong password === #1: 43.23ms #2: 43.26ms #3: 42.57ms

=== Nonexistent user === #1: 42.45ms #2: 42.11ms #3: 47.71ms

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/tinyauthapp/tinyauthall versions1.0.1-0.20260714134959-c22925c2fba9go get github.com/tinyauthapp/tinyauth@v1.0.1-0.20260714134959-c22925c2fba9

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/tinyauthapp/tinyauth, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/tinyauthapp/tinyauth to 1.0.1-0.20260714134959-c22925c2fba9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-456h-ww26-f758 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### 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
O3 Security · Impact-Aware SCA

Is GHSA-456h-ww26-f758 in your dependencies?

Find it across Go, including transitive dependencies.

Tinyauth: User enumeration attack by timing oracle