<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-01T22:29:50.865532+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-77561</id>
    <title>fkie_cve-2026-77561</title>
    <updated>2026-10-01T22:29:50.899354+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Tinyauth is an authentication and authorization server. Prior to 5.1.0, an unauthenticated remote attacker can send POST /api/user/login requests with 257 distinct nonexistent usernames to fill MaxLoginAttemptRecords and activate a global login lockdown. internal/controller/user_controller.go loginHandler passes each attacker-controlled identifier to internal/service/auth_service.go RecordLoginAttempt, which invokes lockdownMode after the map reaches its cap. IsAccountLocked checks that global state before validating unrelated accounts, causing valid users to receive HTTP 429 until auth.loginTimeout expires, approximately 300 seconds by default. The attack can be repeated, but existing authenticated sessions are not invalidated. This issue is fixed in version 5.1.0.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-77561"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-9xhm-w3wj-xhqh</id>
    <title>GHSA-9xhm-w3wj-xhqh — Tinyauth: Unauthenticated login attempts can trigger global login lockdown denial of service</title>
    <updated>2026-10-01T22:29:50.899527+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/steveiliop56/tinyauth</p>
<p>### Summary</p>
<p>Tinyauth's login rate-limit bookkeeping can enter a global lockdown mode when its in-memory login-attempt map reaches 256 distinct identifiers. Because unauthenticated `POST /api/user/login` requests for unknown usernames are recorded in this same map, a remote unauthenticated attacker can submit 257 unique bogus usernames and cause valid credentials for unrelated users to be treated as locked until `auth.loginTimeout` expires.</p>
<p>This was confirmed against the stable `v5.0.7` release. With default configuration, `auth.loginTimeout` is 300 seconds and `auth.loginMaxRetries` is 3, so the denial lasts about 5 minutes and can be repeated.</p>
<p>### Details</p>
<p>In stable `v5.0.7`, the login endpoint is registered at `internal/controller/user_controller.go:45` and accepts unauthenticated JSON credentials in `loginHandler` at `internal/controller/user_controller.go:50`. Before validating credentials, it calls `controller.auth.IsAccountLocked(req.Username)` at `internal/controller/user_controller.go:65`.</p>
<p>When a username does not exist, the login handler records a failed login attempt for the attacker-controlled username with `controller.auth.RecordLoginAttempt(req.Username, false)` at `internal/controller/user_controller.go:83`. Invalid passwords for existing users do the same at `internal/controller/user_controller.go:94`.</p>
<p>The rate-limit map has a hard cap of 256 records at `internal/service/auth_service.go:29`. `RecordLoginAttempt` checks `len(auth.loginAttempts) &gt;= MaxLogin…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-9xhm-w3wj-xhqh"/>
  </entry>
</feed>
