Tinyauth Security Update Addresses 3 Vulnerabilities
Tech GuruQuick Answer
Tinyauth's three advisories concern username timing disclosure, mixed-case hostname bypass of per-app access rules, and login attempts that trigger a global lockout. Use application release evidence, not Go pseudo-version numbers: the timing fix starts at 5.1.0, while the ACL advisory names 5.1.2. The 5.1.0 release notes address lockdown behavior even though that advisory's patch field is blank. Plan a supported release containing all applicable changes.
Confirm Scope And Apply The Supported Fix
What to do now: inventory the running Tinyauth image, proxy integration and per-app ACL provider. Review migration notes and choose a supported release at or beyond the listed 5.1.2 ACL fix. The project moved its maintained image to ghcr.io/tinyauthapp/tinyauth; an old personal-namespace image will not receive updates. Preserve a separate trusted administrative path during the change.
Source recheck: October 2, 2026 UTC. The linked project advisories were checked for this revision; deployment applicability and successful remediation still require local evidence. Recheck the supported release before changing production.
Scope And Authority
| Product scope | Tinyauth packages and release streams identified in the project advisories |
|---|---|
| Advisory | GHSA-456h-ww26-f758 / GHSA-328g-jx67-v94g / GHSA-9xhm-w3wj-xhqh |
| CVEs | CVE-2026-77560, CVE-2026-77561, CVE-2026-77582 |
| Authoritative release date | 2026-07-15 UTC (project advisory dates, not database ingestion) |
| Authority revision date | 2026-08-20 UTC (project advisory dates, not database ingestion) |
| Affected versions | Primary timing and hostname-ACL advisories: <=5.0.7. Global-lockdown advisory: confirmed v5.0.7.The ACL patch field names >=5.1.2; the older affected-range label does not establish that intervening releases are safe. |
| Fixed version | Timing disclosure: 5.1.0 per advisory. Hostname ACL: 5.1.2 per advisory. Global lockout: 5.1.0 release notes link the advisory and describe the rate-limit rework; its primary patch field is still blank. Use the release documentation and a supported current build, not a claim that every fix is in 5.1.0. |
| CVSS base score | 5.3 / 6.9 / 8.1 (official CVSS v3/v4 scores) |
| CVSS severity | Medium to High |
| Exploitation status | Not stated by the authority; no exploitation claim is inferred. |
What Changed
The timing issue reveals whether a local username exists; it does not by itself reveal its password. The ACL issue requires an authenticated user and a hostname whose case prevents the expected per-app rule from matching. The lockdown issue permits unauthenticated login attempts to deny new logins to unrelated users; the report says existing sessions are not invalidated. These need different acceptance checks, not just a successful administrator login.
What To Validate Now
- Inventory. Record image repository/tag/digest, local-login use, trusted proxies, static versus Docker/Kubernetes app ACLs, and affected application owners.
- Establish applicability. Compare each issue with the primary ranges and release-note distinctions above. Inspect what the proxy forwards and which ACL provider actually serves the app.
- Remediate. Follow the maintained-image and configuration migration notes and retain the authentication boundary. Do not work around a failed upgrade by exposing backend apps or broadly trusting forwarded headers.
- Validate. In staging, use permitted and excluded accounts against the same app with ordinary and mixed-case hostnames. Check legitimate login, deliberate login rejection and recovery from rate limits with synthetic accounts; do not flood a production login endpoint.
- Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.
Operational Cautions
Use the exact supported release stream and repository. Test dependencies, clusters, integrations, and rollback before broad deployment; a CVSS rating or reachable feature is not evidence of exploitation.
Evidence To Retain
- Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
- UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
- Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.
Related TechGeeks Resources
Authoritative References
Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.
