CVE-2026-77582

CVE-2026-77582 is a medium-severity security vulnerability in github.com/tinyauthapp/tinyauth (go), affecting versions < 1.0.1-0.20260714134959-c22925c2fba9. It is fixed in 1.0.1-0.20260714134959-c22925c2fba9.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

Tinyauth: User enumeration attack by timing oracle

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

Impact

Affected versions

github.com/tinyauthapp/tinyauth (< 1.0.1-0.20260714134959-c22925c2fba9)

Security releases

github.com/tinyauthapp/tinyauth → 1.0.1-0.20260714134959-c22925c2fba9 (go)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

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

Frequently Asked Questions

  1. What is CVE-2026-77582? CVE-2026-77582 is a medium-severity security vulnerability in github.com/tinyauthapp/tinyauth (go), affecting versions < 1.0.1-0.20260714134959-c22925c2fba9. It is fixed in 1.0.1-0.20260714134959-c22925c2fba9.
  2. Which versions of github.com/tinyauthapp/tinyauth are affected by CVE-2026-77582? github.com/tinyauthapp/tinyauth (go) versions < 1.0.1-0.20260714134959-c22925c2fba9 is affected.
  3. Is there a fix for CVE-2026-77582? Yes. CVE-2026-77582 is fixed in 1.0.1-0.20260714134959-c22925c2fba9. Upgrade to this version or later.
  4. Is CVE-2026-77582 exploitable, and should I be worried? Whether CVE-2026-77582 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether CVE-2026-77582 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix CVE-2026-77582? Upgrade github.com/tinyauthapp/tinyauth to 1.0.1-0.20260714134959-c22925c2fba9 or later.

Other vulnerabilities in github.com/tinyauthapp/tinyauth

Stop the waste.
Protect your environment with Kodem.