Common Weakness Enumeration

CWE-307

Allowed

Improper Restriction of Excessive Authentication Attempts

Abstraction: Base · Status: Draft

The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.

1017 vulnerabilities reference this CWE, most recent first.

GHSA-9V87-664X-72QC

Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-05-24 19:09
VLAI
Details

An issue was discovered in LemonLDAP::NG before 2.0.12. Session cache corruption can lead to authorization bypass or spoofing. By running a loop that makes many authentication attempts, an attacker might alternately be authenticated as one of two different users.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-35472"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-30T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in LemonLDAP::NG before 2.0.12. Session cache corruption can lead to authorization bypass or spoofing. By running a loop that makes many authentication attempts, an attacker might alternately be authenticated as one of two different users.",
  "id": "GHSA-9v87-664x-72qc",
  "modified": "2022-05-24T19:09:22Z",
  "published": "2022-05-24T19:09:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35472"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/commit/8d3b763b6af2b8a9c4ad2765fbfabffec8a73af5"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2539"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/tags"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4943"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9W2M-C6WC-48Q6

Vulnerability from github – Published: 2023-12-08 15:30 – Updated: 2023-12-11 21:30
VLAI
Details

DoraCMS v2.1.8 was discovered to re-use the same code for verification of valid usernames and passwords. This vulnerability allows attackers to gain access to the application via a bruteforce attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-49443"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-08T15:15:07Z",
    "severity": "CRITICAL"
  },
  "details": "DoraCMS v2.1.8 was discovered to re-use the same code for verification of valid usernames and passwords. This vulnerability allows attackers to gain access to the application via a bruteforce attack.",
  "id": "GHSA-9w2m-c6wc-48q6",
  "modified": "2023-12-11T21:30:21Z",
  "published": "2023-12-08T15:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49443"
    },
    {
      "type": "WEB",
      "url": "https://github.com/woshinibaba222/DoraCMS-Verification-Code-Reuse"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9WC2-MV76-38JP

Vulnerability from github – Published: 2022-11-14 19:00 – Updated: 2022-11-18 00:30
VLAI
Details

Authentication Bypass by Primary Weakness in GitHub repository kareadita/kavita prior to 0.6.0.3.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-3993"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-305",
      "CWE-307",
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-14T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Authentication Bypass by Primary Weakness in GitHub repository kareadita/kavita prior to 0.6.0.3.",
  "id": "GHSA-9wc2-mv76-38jp",
  "modified": "2022-11-18T00:30:20Z",
  "published": "2022-11-14T19:00:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3993"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kareadita/kavita/commit/f8db37d3f9aa42d47e7c4f4ca839e892d3f97afb"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/bebd0cd6-18ec-469c-b6ca-19ffa9db0699"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9WCJ-2Q46-8J24

Vulnerability from github – Published: 2026-03-06 18:31 – Updated: 2026-03-06 18:31
VLAI
Details

The WebSocket Application Programming Interface lacks restrictions on the number of authentication requests. This absence of rate limiting may allow an attacker to conduct denial-of-service attacks by suppressing or mis-routing legitimate charger telemetry, or conduct brute-force attacks to gain unauthorized access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-24696"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-06T16:16:10Z",
    "severity": "HIGH"
  },
  "details": "The WebSocket Application Programming Interface lacks restrictions on the number of authentication requests. This absence of rate limiting may allow an attacker to conduct denial-of-service attacks by suppressing or mis-routing legitimate charger telemetry, or conduct brute-force attacks to gain unauthorized access.",
  "id": "GHSA-9wcj-2q46-8j24",
  "modified": "2026-03-06T18:31:13Z",
  "published": "2026-03-06T18:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24696"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-062-08.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-062-08"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-9WQC-R42G-8QGM

Vulnerability from github – Published: 2026-04-21 15:32 – Updated: 2026-04-21 15:32
VLAI
Details

The login limit is not enforced on the SFTP service of Fortra's GoAnywhere MFT prior to 7.10.0 if the Web User attempting to be logged in to is configured to log in with an SSH Key, making the SSH key vulnerable to being guessed via Brute Force.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-14362"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T15:16:35Z",
    "severity": "HIGH"
  },
  "details": "The login limit is not enforced on the\u00a0SFTP service of Fortra\u0027s GoAnywhere MFT prior to 7.10.0 if the Web User attempting to be logged in to is configured to log in with an SSH Key, making the SSH key vulnerable to being guessed via Brute Force.",
  "id": "GHSA-9wqc-r42g-8qgm",
  "modified": "2026-04-21T15:32:22Z",
  "published": "2026-04-21T15:32:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14362"
    },
    {
      "type": "WEB",
      "url": "https://fortra.com/security/advisories/product-security/FI-2026-002"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9X5F-WQXF-4PMW

Vulnerability from github – Published: 2023-10-11 12:30 – Updated: 2024-04-04 08:33
VLAI
Details

Vulnerability of brute-force attacks on the device authentication module.Successful exploitation of this vulnerability may affect service confidentiality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-44111"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-11T12:15:11Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability of brute-force attacks on the device authentication module.Successful exploitation of this vulnerability may affect service confidentiality.",
  "id": "GHSA-9x5f-wqxf-4pmw",
  "modified": "2024-04-04T08:33:40Z",
  "published": "2023-10-11T12:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44111"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2023/10"
    },
    {
      "type": "WEB",
      "url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202310-0000001663676540"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9XH6-8FCG-F9QM

Vulnerability from github – Published: 2022-09-29 00:00 – Updated: 2022-10-01 00:00
VLAI
Details

WiseConnect - ScreenConnect Session Code Bypass. An attacker would have to use a proxy to monitor the traffic, and perform a brute force on the session code in order to get in. Sensitive data about the company , get in a session.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-36781"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-28T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "WiseConnect - ScreenConnect Session Code Bypass. An attacker would have to use a proxy to monitor the traffic, and perform a brute force on the session code in order to get in. Sensitive data about the company , get in a session.",
  "id": "GHSA-9xh6-8fcg-f9qm",
  "modified": "2022-10-01T00:00:24Z",
  "published": "2022-09-29T00:00:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36781"
    },
    {
      "type": "WEB",
      "url": "https://www.gov.il/en/Departments/faq/cve_advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9XHM-W3WJ-XHQH

Vulnerability from github – Published: 2026-09-22 20:37 – Updated: 2026-09-22 20:37
VLAI
Summary
Tinyauth: Unauthenticated login attempts can trigger global login lockdown denial of service
Details

Summary

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.

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.

Details

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.

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.

The rate-limit map has a hard cap of 256 records at internal/service/auth_service.go:29. RecordLoginAttempt checks len(auth.loginAttempts) >= MaxLoginAttemptRecords at internal/service/auth_service.go:261 and, once the cap is reached, launches auth.lockdownMode() at internal/service/auth_service.go:265 instead of evicting old identifiers or rejecting only the new identifier.

lockdownMode sets a global auth.lockdown value with Active: true and ActiveUntil: now + auth.config.LoginTimeout at internal/service/auth_service.go:790-804. IsAccountLocked checks this global lockdown before looking up the requested identifier at internal/service/auth_service.go:227-234, so every username is treated as locked while the global lockdown is active.

The default configuration enables this path with LoginTimeout: 300 and LoginMaxRetries: 3 at internal/config/config.go:23-24.

Source-to-sink path:

Unauthenticated POST /api/user/login JSON username
  -> loginHandler binds LoginRequest
  -> unknown username path records RecordLoginAttempt(attacker-chosen username, false)
  -> 257 unique identifiers fill loginAttempts beyond MaxLoginAttemptRecords
  -> RecordLoginAttempt starts lockdownMode()
  -> lockdownMode sets global auth.lockdown.Active = true
  -> IsAccountLocked returns locked for unrelated valid users
  -> login endpoint returns HTTP 429 for valid credentials until loginTimeout expires

Candidate score: 13/14. Reachability 2, attacker control 2, privilege required 2, sink impact 1, mitigation weakness 2, default exposure 2, safe reproduction feasibility 2.

PoC

This PoC is local and non-destructive. It was tested against stable tag v5.0.7. It proves that 257 distinct unknown-user identifiers trigger global lockdown for an unrelated valid user, while that user's password still verifies successfully.

  1. Check out stable v5.0.7.

  2. Create internal/service/login_lockdown_stable_poc_test.go:

package service

import (
    "fmt"
    "testing"
    "time"

    "github.com/steveiliop56/tinyauth/internal/config"
    "github.com/steveiliop56/tinyauth/internal/utils/tlog"
    "github.com/stretchr/testify/require"
)

func TestPoCStableUnknownUsersTriggerGlobalLoginLockdown(t *testing.T) {
    tlog.NewTestLogger().Init()

    authServiceCfg := AuthServiceConfig{
        Users: []config.User{{
            Username: "testuser",
            Password: "$2a$10$ZwVYQH07JX2zq7Fjkt3gU.BjwvvwPeli4OqOno04RQIv0P7usBrXa", // password
        }},
        LoginTimeout:    2,
        LoginMaxRetries: 3,
    }

    authService := NewAuthService(authServiceCfg, &DockerService{}, &LdapService{}, nil, nil)
    t.Cleanup(authService.ClearRateLimitsTestingOnly)

    require.True(t, authService.VerifyUser(config.UserSearch{
        Username: "testuser",
        Type:     "local",
    }, "password"))

    for i := 0; i <= MaxLoginAttemptRecords; i++ {
        authService.RecordLoginAttempt(fmt.Sprintf("attacker-%03d", i), false)
    }

    require.Eventually(t, func() bool {
        locked, _ := authService.IsAccountLocked("testuser")
        return locked
    }, time.Second, 10*time.Millisecond)

    locked, remaining := authService.IsAccountLocked("testuser")
    require.True(t, locked)
    require.GreaterOrEqual(t, remaining, 0)

    require.True(t, authService.VerifyUser(config.UserSearch{
        Username: "testuser",
        Type:     "local",
    }, "password"))

    t.Logf("proof on v5.0.7: %d distinct failed unknown-user identifiers caused unrelated valid user testuser to be locked", MaxLoginAttemptRecords+1)
}
  1. Run:
go test ./internal/service -run 'TestPoCStableUnknownUsersTriggerGlobalLoginLockdown' -count=1 -v

Observed output from this environment:

=== RUN   TestPoCStableUnknownUsersTriggerGlobalLoginLockdown
auth_service.go:798: Multiple login attempts detected, possibly DDOS attack. Activating temporary lockdown.
    login_lockdown_stable_poc_test.go:42: proof on v5.0.7: 257 distinct failed unknown-user identifiers caused unrelated valid user testuser to be locked
--- PASS: TestPoCStableUnknownUsersTriggerGlobalLoginLockdown (0.10s)
PASS
ok      github.com/steveiliop56/tinyauth/internal/service    0.111s
  1. Cleanup:
rm internal/service/login_lockdown_stable_poc_test.go

Impact

A remote unauthenticated attacker who can reach Tinyauth's login endpoint can temporarily deny login for unrelated valid users by sending a small number of login attempts using unique nonexistent usernames.

With default configuration, the global lockdown lasts 300 seconds. The attack does not invalidate existing sessions, but users who need to log in during the lockdown window receive rate-limit responses even when providing valid credentials.

This affects availability of local login and any flow that depends on the same account-lock check. The issue is especially relevant for internet-exposed Tinyauth deployments where /api/user/login is reachable.

Suggested remediation: do not enter global lockdown because of attacker-controlled unknown usernames. Use bounded LRU eviction for old login-attempt records instead of global lockout; consider rate limiting by client IP plus normalized username; avoid counting unlimited nonexistent usernames toward a global security state. If a global safety mode is desired, require stronger signals such as source-based thresholds rather than only distinct username count.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/steveiliop56/tinyauth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.1-0.20260715123057-dade1e2c8f27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77561"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:37:11Z",
    "nvd_published_at": "2026-09-21T17:18:52Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nTinyauth\u0027s 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.\n\nThis 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.\n\n### Details\n\nIn 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`.\n\nWhen 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`.\n\nThe rate-limit map has a hard cap of 256 records at `internal/service/auth_service.go:29`. `RecordLoginAttempt` checks `len(auth.loginAttempts) \u003e= MaxLoginAttemptRecords` at `internal/service/auth_service.go:261` and, once the cap is reached, launches `auth.lockdownMode()` at `internal/service/auth_service.go:265` instead of evicting old identifiers or rejecting only the new identifier.\n\n`lockdownMode` sets a global `auth.lockdown` value with `Active: true` and `ActiveUntil: now + auth.config.LoginTimeout` at `internal/service/auth_service.go:790-804`. `IsAccountLocked` checks this global lockdown before looking up the requested identifier at `internal/service/auth_service.go:227-234`, so every username is treated as locked while the global lockdown is active.\n\nThe default configuration enables this path with `LoginTimeout: 300` and `LoginMaxRetries: 3` at `internal/config/config.go:23-24`.\n\nSource-to-sink path:\n\n```text\nUnauthenticated POST /api/user/login JSON username\n  -\u003e loginHandler binds LoginRequest\n  -\u003e unknown username path records RecordLoginAttempt(attacker-chosen username, false)\n  -\u003e 257 unique identifiers fill loginAttempts beyond MaxLoginAttemptRecords\n  -\u003e RecordLoginAttempt starts lockdownMode()\n  -\u003e lockdownMode sets global auth.lockdown.Active = true\n  -\u003e IsAccountLocked returns locked for unrelated valid users\n  -\u003e login endpoint returns HTTP 429 for valid credentials until loginTimeout expires\n```\n\nCandidate score: 13/14. Reachability 2, attacker control 2, privilege required 2, sink impact 1, mitigation weakness 2, default exposure 2, safe reproduction feasibility 2.\n\n### PoC\n\nThis PoC is local and non-destructive. It was tested against stable tag `v5.0.7`. It proves that 257 distinct unknown-user identifiers trigger global lockdown for an unrelated valid user, while that user\u0027s password still verifies successfully.\n\n1. Check out stable `v5.0.7`.\n\n2. Create `internal/service/login_lockdown_stable_poc_test.go`:\n\n```go\npackage service\n\nimport (\n    \"fmt\"\n    \"testing\"\n    \"time\"\n\n    \"github.com/steveiliop56/tinyauth/internal/config\"\n    \"github.com/steveiliop56/tinyauth/internal/utils/tlog\"\n    \"github.com/stretchr/testify/require\"\n)\n\nfunc TestPoCStableUnknownUsersTriggerGlobalLoginLockdown(t *testing.T) {\n    tlog.NewTestLogger().Init()\n\n    authServiceCfg := AuthServiceConfig{\n        Users: []config.User{{\n            Username: \"testuser\",\n            Password: \"$2a$10$ZwVYQH07JX2zq7Fjkt3gU.BjwvvwPeli4OqOno04RQIv0P7usBrXa\", // password\n        }},\n        LoginTimeout:    2,\n        LoginMaxRetries: 3,\n    }\n\n    authService := NewAuthService(authServiceCfg, \u0026DockerService{}, \u0026LdapService{}, nil, nil)\n    t.Cleanup(authService.ClearRateLimitsTestingOnly)\n\n    require.True(t, authService.VerifyUser(config.UserSearch{\n        Username: \"testuser\",\n        Type:     \"local\",\n    }, \"password\"))\n\n    for i := 0; i \u003c= MaxLoginAttemptRecords; i++ {\n        authService.RecordLoginAttempt(fmt.Sprintf(\"attacker-%03d\", i), false)\n    }\n\n    require.Eventually(t, func() bool {\n        locked, _ := authService.IsAccountLocked(\"testuser\")\n        return locked\n    }, time.Second, 10*time.Millisecond)\n\n    locked, remaining := authService.IsAccountLocked(\"testuser\")\n    require.True(t, locked)\n    require.GreaterOrEqual(t, remaining, 0)\n\n    require.True(t, authService.VerifyUser(config.UserSearch{\n        Username: \"testuser\",\n        Type:     \"local\",\n    }, \"password\"))\n\n    t.Logf(\"proof on v5.0.7: %d distinct failed unknown-user identifiers caused unrelated valid user testuser to be locked\", MaxLoginAttemptRecords+1)\n}\n```\n\n3. Run:\n\n```bash\ngo test ./internal/service -run \u0027TestPoCStableUnknownUsersTriggerGlobalLoginLockdown\u0027 -count=1 -v\n```\n\nObserved output from this environment:\n\n```text\n=== RUN   TestPoCStableUnknownUsersTriggerGlobalLoginLockdown\nauth_service.go:798: Multiple login attempts detected, possibly DDOS attack. Activating temporary lockdown.\n    login_lockdown_stable_poc_test.go:42: proof on v5.0.7: 257 distinct failed unknown-user identifiers caused unrelated valid user testuser to be locked\n--- PASS: TestPoCStableUnknownUsersTriggerGlobalLoginLockdown (0.10s)\nPASS\nok      github.com/steveiliop56/tinyauth/internal/service    0.111s\n```\n\n4. Cleanup:\n\n```bash\nrm internal/service/login_lockdown_stable_poc_test.go\n```\n\n### Impact\n\nA remote unauthenticated attacker who can reach Tinyauth\u0027s login endpoint can temporarily deny login for unrelated valid users by sending a small number of login attempts using unique nonexistent usernames.\n\nWith default configuration, the global lockdown lasts 300 seconds. The attack does not invalidate existing sessions, but users who need to log in during the lockdown window receive rate-limit responses even when providing valid credentials.\n\nThis affects availability of local login and any flow that depends on the same account-lock check. The issue is especially relevant for internet-exposed Tinyauth deployments where `/api/user/login` is reachable.\n\nSuggested remediation: do not enter global lockdown because of attacker-controlled unknown usernames. Use bounded LRU eviction for old login-attempt records instead of global lockout; consider rate limiting by client IP plus normalized username; avoid counting unlimited nonexistent usernames toward a global security state. If a global safety mode is desired, require stronger signals such as source-based thresholds rather than only distinct username count.",
  "id": "GHSA-9xhm-w3wj-xhqh",
  "modified": "2026-09-22T20:37:11Z",
  "published": "2026-09-22T20:37:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tinyauthapp/tinyauth/security/advisories/GHSA-9xhm-w3wj-xhqh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77561"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinyauthapp/tinyauth/pull/1008"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinyauthapp/tinyauth/pull/943"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinyauthapp/tinyauth/commit/654b5cc436fc67865c1f55edf9ba9fbded50b74f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinyauthapp/tinyauth/commit/dade1e2c8f27a23df56ac216dcaf4b37081698e7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tinyauthapp/tinyauth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinyauthapp/tinyauth/releases/tag/v5.1.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Tinyauth: Unauthenticated login attempts can trigger global login lockdown denial of service"
}

GHSA-9XWG-WXGQ-6VPH

Vulnerability from github – Published: 2024-11-04 15:31 – Updated: 2024-11-08 15:31
VLAI
Details

This vulnerability exists in the Wave 2.0 due to missing restrictions for excessive failed authentication attempts on its API based login. A remote attacker could exploit this vulnerability by conducting a brute force attack against legitimate user OTP, MPIN or password, which could lead to gain unauthorized access and compromise other user accounts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-51558"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-04T13:17:05Z",
    "severity": "CRITICAL"
  },
  "details": "This vulnerability exists in the Wave 2.0\u00a0due to missing restrictions for excessive failed authentication attempts on its API based login. A remote attacker could exploit this vulnerability by conducting a brute force attack against legitimate user OTP, MPIN or password, which could lead to gain unauthorized access and compromise other user accounts.",
  "id": "GHSA-9xwg-wxgq-6vph",
  "modified": "2024-11-08T15:31:12Z",
  "published": "2024-11-04T15:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51558"
    },
    {
      "type": "WEB",
      "url": "https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01\u0026VLCODE=CIVN-2024-0332"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-C25Q-57MR-RV37

Vulnerability from github – Published: 2025-10-11 00:30 – Updated: 2026-03-27 00:31
VLAI
Details

Improper Restriction of Excessive Authentication Attempts vulnerability in Drupal Protected Pages allows Brute Force.This issue affects Protected Pages: from 0.0.0 before 1.8.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-9551"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-10T23:15:37Z",
    "severity": "MODERATE"
  },
  "details": "Improper Restriction of Excessive Authentication Attempts vulnerability in Drupal Protected Pages allows Brute Force.This issue affects Protected Pages: from 0.0.0 before 1.8.0.",
  "id": "GHSA-c25q-57mr-rv37",
  "modified": "2026-03-27T00:31:19Z",
  "published": "2025-10-11T00:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9551"
    },
    {
      "type": "WEB",
      "url": "https://d7es.tag1.com/security-advisories/protected-pages-moderately-critical-access-bypass-sa-contrib-2025-101"
    },
    {
      "type": "WEB",
      "url": "https://docs.herodevs.com/drupal/release-notes/protected-pages"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-contrib-2025-101"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design
  • Common protection mechanisms include:
  • Disconnecting the user after a small number of failed attempts
  • Implementing a timeout
  • Locking out a targeted account
  • Requiring a computational task on the user's part.
Mitigation MIT-4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
  • Consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator. [REF-45]
CAPEC-16: Dictionary-based Password Attack

An attacker tries each of the words in a dictionary as passwords to gain access to the system via some user's account. If the password chosen by the user was a word within the dictionary, this attack will be successful (in the absence of other mitigations). This is a specific instance of the password brute forcing attack pattern.

Dictionary Attacks differ from similar attacks such as Password Spraying (CAPEC-565) and Credential Stuffing (CAPEC-600), since they leverage unknown username/password combinations and don't care about inducing account lockouts.

CAPEC-49: Password Brute Forcing

An adversary tries every possible value for a password until they succeed. A brute force attack, if feasible computationally, will always be successful because it will essentially go through all possible passwords given the alphabet used (lower case letters, upper case letters, numbers, symbols, etc.) and the maximum length of the password.

CAPEC-560: Use of Known Domain Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.

CAPEC-565: Password Spraying

In a Password Spraying attack, an adversary tries a small list (e.g. 3-5) of common or expected passwords, often matching the target's complexity policy, against a known list of user accounts to gain valid credentials. The adversary tries a particular password for each user account, before moving onto the next password in the list. This approach assists the adversary in remaining undetected by avoiding rapid or frequent account lockouts. The adversary may then reattempt the process with additional passwords, once enough time has passed to prevent inducing a lockout.

CAPEC-600: Credential Stuffing

An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.

CAPEC-652: Use of Known Kerberos Credentials

An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.

CAPEC-653: Use of Known Operating System Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.