CVE-2026-77582: Tinyauth Information Disclosure Vulnerability

CVE-2026-77582 Overview

CVE-2026-77582 is a timing side-channel vulnerability in Tinyauth, an authentication and authorization server. Versions prior to 5.1.0 expose a remotely observable timing difference between login attempts for existing and nonexistent local usernames. When a submitted username does not exist, the server returns quickly. When the username exists, the server performs bcrypt password verification, which introduces measurable latency. An attacker who repeats measurements can enumerate valid usernames and use that list to focus credential attacks such as password spraying or brute forcing. The issue is fixed in Tinyauth 5.1.0. It is classified under CWE-208: Observable Timing Discrepancy.

Critical Impact
Remote, unauthenticated attackers can enumerate valid Tinyauth usernames by measuring authentication response times, enabling targeted credential attacks.

Affected Products

Tinyauth authentication and authorization server, all versions prior to 5.1.0
Deployments exposing the loginHandler endpoint in internal/controller/user_controller.go
Deployments relying on the basicAuth handler in internal/middleware/context_middleware.go

Discovery Timeline

2026-09-21 - CVE-2026-77582 published to NVD
2026-09-23 - Last updated in NVD database
v5.1.0 - Tinyauth releases fixed version, see GitHub Release v5.1.0

Technical Details for CVE-2026-77582

Vulnerability Analysis

The flaw lives in Tinyauth's local authentication path. The loginHandler in internal/controller/user_controller.go and the basicAuth handler in internal/middleware/context_middleware.go both call into internal/service/auth_service.go to resolve a user. When the service returns ErrUserNotFound, both handlers exit early without performing any password verification work. When the user exists, the handlers proceed to bcrypt hashing, which is intentionally expensive.

The two code paths therefore diverge by tens of milliseconds. That gap is trivially observable over the network. An attacker can script authentication requests against a list of candidate usernames, record response latencies, and separate valid accounts from invalid ones. The disclosed usernames then feed downstream credential attacks such as password spraying, phishing, and MFA fatigue.

Root Cause

The root cause is a failure to make the login response time independent of user existence. Bcrypt is invoked only for real accounts, so the CPU work performed per request leaks the account's existence. This is a classic CWE-208 observable timing discrepancy in an authentication routine.

Attack Vector

Exploitation requires only network access to the Tinyauth login endpoint or a resource protected by basic authentication. No credentials, user interaction, or elevated privileges are required. An attacker sends repeated login attempts across a candidate username list and computes latency statistics per username to classify accounts as valid or invalid.

// Patch excerpt: internal/controller/user_controller.go
// fix: use constant time in user checks (#1004)
	if err != nil {
		if errors.Is(err, service.ErrUserNotFound) {
+			controller.auth.DummyPasswordCheck(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")

Source: GitHub Commit c22925c. The fix invokes DummyPasswordCheck on the not-found branch so both paths perform equivalent bcrypt work.

Detection Methods for CVE-2026-77582

Indicators of Compromise

High volumes of failed authentication attempts from a single source IP against the Tinyauth login endpoint, especially with many distinct usernames per source.
Sequential or dictionary-ordered username submissions to loginHandler or basic-auth-protected routes.
Repeated requests with identical or clearly placeholder passwords across many usernames, consistent with enumeration probes.

Detection Strategies

Alert on authentication request bursts where the ratio of unique usernames to source IPs exceeds a normal baseline.
Correlate user not found audit log entries against login failure entries to identify enumeration patterns.
Track per-source rate of failed logins over short windows and flag traffic that exceeds interactive-user thresholds.

Monitoring Recommendations

Ship Tinyauth audit logs to a central SIEM or data lake and retain them long enough to spot slow, low-and-slow enumeration.
Monitor upstream reverse proxies for anomalous request timing distributions targeting the Tinyauth login route.
Baseline login endpoint latency after upgrading to 5.1.0 so any future divergence between valid and invalid usernames is detectable.

How to Mitigate CVE-2026-77582

Immediate Actions Required

Upgrade Tinyauth to version 5.1.0 or later, which introduces constant-time behavior via DummyPasswordCheck.
Restrict network exposure of the Tinyauth login endpoint to trusted networks or VPN clients while patching is scheduled.
Enable and enforce rate limiting on authentication endpoints to slow enumeration and credential-attack follow-on.

Patch Information

The fix is delivered in Tinyauth 5.1.0. See the GitHub Security Advisory GHSA-456h-ww26-f758, the merged Pull Request #1004, and the v5.1.0 release notes. The patch commit is c22925c.

Workarounds

Place Tinyauth behind a reverse proxy that enforces per-IP rate limiting and lockouts on repeated failed authentications.
Require an additional network authentication layer, such as mutual TLS or a VPN, in front of Tinyauth until the upgrade lands.
Rotate any usernames that are known-sensitive or predictable so leaked enumeration data has reduced value to attackers.

bash

# Example: verify the running Tinyauth version and upgrade the container image
docker inspect tinyauth --format '{{.Config.Image}}'
docker pull ghcr.io/tinyauthapp/tinyauth:5.1.0
docker stop tinyauth && docker rm tinyauth
# Recreate the container using your existing compose or run parameters, pinned to 5.1.0