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.
967 vulnerabilities reference this CWE, most recent first.
GHSA-VVXM-2VXQ-RHGQ
Vulnerability from github – Published: 2024-09-18 12:31 – Updated: 2026-06-03 15:30Improper Restriction of Excessive Authentication Attempts vulnerability in Yordam Information Technology Yordam Library Automation System allows Interface Manipulation.This issue affects Yordam Library Automation System: before 20.1.
{
"affected": [],
"aliases": [
"CVE-2024-5682"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-18T12:15:03Z",
"severity": "MODERATE"
},
"details": "Improper Restriction of Excessive Authentication Attempts vulnerability in Yordam Information Technology Yordam Library Automation System allows Interface Manipulation.This issue affects Yordam Library Automation System: before 20.1.",
"id": "GHSA-vvxm-2vxq-rhgq",
"modified": "2026-06-03T15:30:34Z",
"published": "2024-09-18T12:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5682"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-24-1496"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-24-1496"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/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-VWG8-CR9J-895F
Vulnerability from github – Published: 2026-08-26 00:30 – Updated: 2026-08-26 21:31Punk::Plugin::TOTP versions before 0.05 for Perl allow the second-factor attempt limit to be reset by replaying an earlier session cookie because the challenge route counts failures in the session.
The POST handler on challenge_path keeps the failure count as tries inside the totp_pending record in the session, raising it on each rejected code and deleting the pending record once it reaches attempts, five by default. Punk::Session carries the session in a signed cookie unless the application declares a store, and keeps no server-side record, so an earlier value of the same session stays valid until the expiry stamped inside it. A client that saves the cookie before its failed attempts and presents it again gets the pending record back with its counter, and the limit never fires. The replayed record is accepted while its own expiry, pending_ttl seconds from the challenge and 300 by default, has not passed.
Sessions declared with a store are not affected: the pending record and its counter then live server-side.
The attempt limit does not bound guessing of the second factor, which is left to the per-address rate limit the plugin registers on the same path, 30 requests per 60 seconds.
{
"affected": [],
"aliases": [
"CVE-2026-78655"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T22:17:06Z",
"severity": "CRITICAL"
},
"details": "Punk::Plugin::TOTP versions before 0.05 for Perl allow the second-factor attempt limit to be reset by replaying an earlier session cookie because the challenge route counts failures in the session.\n\nThe POST handler on challenge_path keeps the failure count as tries inside the totp_pending record in the session, raising it on each rejected code and deleting the pending record once it reaches attempts, five by default. Punk::Session carries the session in a signed cookie unless the application declares a store, and keeps no server-side record, so an earlier value of the same session stays valid until the expiry stamped inside it. A client that saves the cookie before its failed attempts and presents it again gets the pending record back with its counter, and the limit never fires. The replayed record is accepted while its own expiry, pending_ttl seconds from the challenge and 300 by default, has not passed.\n\nSessions declared with a store are not affected: the pending record and its counter then live server-side.\n\nThe attempt limit does not bound guessing of the second factor, which is left to the per-address rate limit the plugin registers on the same path, 30 requests per 60 seconds.",
"id": "GHSA-vwg8-cr9j-895f",
"modified": "2026-08-26T21:31:39Z",
"published": "2026-08-26T00:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78655"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/LNATION/Punk-0.32/view/lib/Punk/Session.pm"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/LNATION/Punk-TOTP-0.04/source/include/ptotp/ptotp_plugin.h"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/LNATION/Punk-TOTP-0.04/view/lib/Punk/Plugin/TOTP.pm"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/LNATION/Punk-TOTP-0.05/source/Changes"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/25/7"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-VWQF-JX9P-3VGP
Vulnerability from github – Published: 2026-08-05 09:31 – Updated: 2026-08-05 09:31changedetection.io's /login route checks the submitted password against a single PBKDF2-HMAC-SHA256 hash with no per-IP or per-session rate limiting, failed-attempt counter, or lockout (no rate-limiting library is present in requirements.txt). Because the entire application is protected by one shared password with no per-user accounts, a successful brute-force guess grants full administrative access, including the ability to view/regenerate the API token.
{
"affected": [],
"aliases": [
"CVE-2026-71205"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-05T08:16:42Z",
"severity": "MODERATE"
},
"details": "changedetection.io\u0027s /login route checks the submitted password against a single PBKDF2-HMAC-SHA256 hash with no per-IP or per-session rate limiting, failed-attempt counter, or lockout (no rate-limiting library is present in requirements.txt). Because the entire application is protected by one shared password with no per-user accounts, a successful brute-force guess grants full administrative access, including the ability to view/regenerate the API token.",
"id": "GHSA-vwqf-jx9p-3vgp",
"modified": "2026-08-05T09:31:18Z",
"published": "2026-08-05T09:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71205"
},
{
"type": "WEB",
"url": "https://github.com/dgtlmoon/changedetection.io"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-VX4H-HJJM-MWRC
Vulnerability from github – Published: 2026-08-10 12:31 – Updated: 2026-08-10 21:32UnixAuth lacks brute-force protection in Apache Ranger versions <= 2.8.0. Note: UnixAuth is NOT a recommended option for production deployments. Users are recommended to upgrade to version 2.9.0, which fixes this issue.
{
"affected": [],
"aliases": [
"CVE-2026-65948"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T11:17:27Z",
"severity": "HIGH"
},
"details": "UnixAuth lacks brute-force protection in Apache Ranger versions \u003c= 2.8.0.\u00a0\nNote:\u00a0\u00a0UnixAuth is NOT a recommended option for production deployments.\u00a0\nUsers are recommended to upgrade to version 2.9.0, which fixes this issue.",
"id": "GHSA-vx4h-hjjm-mwrc",
"modified": "2026-08-10T21:32:02Z",
"published": "2026-08-10T12:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65948"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/cx53rbkxkn5hbvzv8ohwvndzrxhc06qf"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/09/11"
}
],
"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-VXGH-RFHR-MP4Q
Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2024-04-04 02:09An issue was discovered on V-Zug Combi-Steam MSLQ devices before Ethernet R07 and before WLAN R05. There is no bruteforce protection (e.g., lockout) established. An attacker might be able to bruteforce the password to authenticate on the device.
{
"affected": [],
"aliases": [
"CVE-2019-17215"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-06T16:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered on V-Zug Combi-Steam MSLQ devices before Ethernet R07 and before WLAN R05. There is no bruteforce protection (e.g., lockout) established. An attacker might be able to bruteforce the password to authenticate on the device.",
"id": "GHSA-vxgh-rfhr-mp4q",
"modified": "2024-04-04T02:09:02Z",
"published": "2022-05-24T16:57:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17215"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.140463"
}
],
"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-W22J-QGR5-CW5M
Vulnerability from github – Published: 2025-12-08 12:30 – Updated: 2025-12-08 12:30In affected versions, vulnerability-lookup did not track or limit failed One-Time Password (OTP) attempts during Two-Factor Authentication (2FA) verification. An attacker who already knew or guessed a valid username and password could submit an arbitrary number of OTP codes without causing the account to be locked or generating any specific alert for administrators.
This lack of rate-limiting and lockout on OTP failures significantly lowers the cost of online brute-force attacks against 2FA codes and increases the risk of successful account takeover, especially if OTP entropy is reduced (e.g. short numeric codes, user reuse, or predictable tokens). Additionally, administrators had no direct visibility into accounts experiencing repeated 2FA failures, making targeted attacks harder to detect and investigate.
The patch introduces a persistent failed_otp_attempts counter on user accounts, locks the user after 5 invalid OTP submissions, resets the counter on successful verification, and surfaces failed 2FA attempts in the admin user list. This enforces an account lockout policy for OTP brute-force attempts and improves monitoring capabilities for suspicious 2FA activity.This issue affects Vulnerability-Lookup: before 2.18.0.
{
"affected": [],
"aliases": [
"CVE-2025-42615"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-08T12:16:03Z",
"severity": "HIGH"
},
"details": "In affected versions, vulnerability-lookup did not track or limit failed\n One-Time Password (OTP) attempts during Two-Factor Authentication (2FA)\n verification. An attacker who already knew or guessed a valid username \nand password could submit an arbitrary number of OTP codes without \ncausing the account to be locked or generating any specific alert for \nadministrators.\n\n\nThis lack of rate-limiting and lockout on OTP failures significantly \nlowers the cost of online brute-force attacks against 2FA codes and \nincreases the risk of successful account takeover, especially if OTP \nentropy is reduced (e.g. short numeric codes, user reuse, or predictable\n tokens). Additionally, administrators had no direct visibility into \naccounts experiencing repeated 2FA failures, making targeted attacks \nharder to detect and investigate.\n\n\nThe patch introduces a persistent failed_otp_attempts counter on user \naccounts, locks the user after 5 invalid OTP submissions, resets the \ncounter on successful verification, and surfaces failed 2FA attempts in \nthe admin user list. This enforces an account lockout policy for OTP \nbrute-force attempts and improves monitoring capabilities for suspicious\n 2FA activity.This issue affects Vulnerability-Lookup: before 2.18.0.",
"id": "GHSA-w22j-qgr5-cw5m",
"modified": "2025-12-08T12:30:26Z",
"published": "2025-12-08T12:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-42615"
},
{
"type": "WEB",
"url": "https://vulnerability.circl.lu/vuln/gcve-1-2025-0033"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:A/VC:H/VI:N/VA:N/SC:H/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-W329-4XM8-G68X
Vulnerability from github – Published: 2026-03-10 18:31 – Updated: 2026-03-10 18:31Incorrect Access Control via missing 2FA rate-limiting allowing unlimited brute-force retries and full MFA bypass with no user interaction required. Affected Product: Deutsche Telekom AG Telekom Account Management Portal, versions before 2025-10-24, fixed 2025-11-03.
{
"affected": [],
"aliases": [
"CVE-2025-69615"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-10T18:18:01Z",
"severity": "CRITICAL"
},
"details": "Incorrect Access Control via missing 2FA rate-limiting allowing unlimited brute-force retries and full MFA bypass with no user interaction required. Affected Product: Deutsche Telekom AG Telekom Account Management Portal, versions before 2025-10-24, fixed 2025-11-03.",
"id": "GHSA-w329-4xm8-g68x",
"modified": "2026-03-10T18:31:18Z",
"published": "2026-03-10T18:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69615"
},
{
"type": "WEB",
"url": "https://gist.github.com/ethicalrohitt/b3e6d071aac8530459e8b3a5720bb832"
},
{
"type": "WEB",
"url": "https://www.telekom.com/en/company/data-privacy-and-security/news/acknowledgements-358300#R"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-W4JG-W96X-Q3WH
Vulnerability from github – Published: 2026-07-14 00:31 – Updated: 2026-07-14 00:31PasswordPusher before 2.9.2 contains a brute-force vulnerability in the POST /p/:token/access endpoint that lacks route-specific rate limiting and per-push lockout mechanisms. Attackers who know a push token can systematically guess passphrases at 120 attempts per minute without triggering any push-level defense, making short or dictionary-derived passphrases practically recoverable within hours or days.
{
"affected": [],
"aliases": [
"CVE-2026-61458"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-13T22:16:49Z",
"severity": "HIGH"
},
"details": "PasswordPusher before 2.9.2 contains a brute-force vulnerability in the POST /p/:token/access endpoint that lacks route-specific rate limiting and per-push lockout mechanisms. Attackers who know a push token can systematically guess passphrases at 120 attempts per minute without triggering any push-level defense, making short or dictionary-derived passphrases practically recoverable within hours or days.",
"id": "GHSA-w4jg-w96x-q3wh",
"modified": "2026-07-14T00:31:03Z",
"published": "2026-07-14T00:31:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pglombardo/PasswordPusher/security/advisories/GHSA-59w3-h5v2-c4xw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61458"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/passwordpusher-passphrase-brute-force-via-unthrottled-endpoint"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/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-W54H-JPCF-GVH9
Vulnerability from github – Published: 2025-10-17 21:31 – Updated: 2025-10-17 21:31A lack of rate limiting in the login mechanism of SigningHub v8.6.8 allows attackers to bypass authentication via a brute force attack.
{
"affected": [],
"aliases": [
"CVE-2025-56221"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-17T19:15:37Z",
"severity": "CRITICAL"
},
"details": "A lack of rate limiting in the login mechanism of SigningHub v8.6.8 allows attackers to bypass authentication via a brute force attack.",
"id": "GHSA-w54h-jpcf-gvh9",
"modified": "2025-10-17T21:31:18Z",
"published": "2025-10-17T21:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56221"
},
{
"type": "WEB",
"url": "https://github.com/saykino/CVE-2025-56221"
}
],
"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-W5R6-MCGQ-7PQ4
Vulnerability from github – Published: 2026-05-27 00:04 – Updated: 2026-05-27 00:04Summary
The authentication endpoint POST /auth/token in yamcs-core lacks any form of rate limiting, account lockout, or failed attempt throttling. As a result, an unauthenticated remote attacker can perform unlimited password guessing attempts against any user account.
This missing rate limiting vulnerability (CWE-307) significantly increases the risk of successful brute-force attacks.
Root Cause
File: yamcs-core/src/main/java/org/yamcs/http/auth/AuthHandler.java
POST /auth/token has no rate limiting, no lockout after failed attempts, and no CAPTCHA. The handler processes unlimited authentication requests without any throttling mechanism:
// AuthHandler.java — handleToken()
// No throttle, no failed attempt counter, no lockout
private void handleToken(HandlerContext ctx) {
...
getSecurityStore().login(token).whenComplete((info, err) -> {
// Directly attempts authentication with no rate check
});
}
This is absent by default — the official quickstart and documentation contain no guidance on configuring rate limiting.
Impact
An attacker can make unlimited authentication attempts against any account. This enables efficient brute-force attacks against any account.
Proof of Concept
# 20 attempts — zero rate limiting
for i in $(seq 1 20); do
curl -s -o /dev/null -w "Attempt $i: HTTP %{http_code}\n" \
-X POST "http://TARGET:8090/auth/token" \
-d "grant_type=password&username=operator&password=operator12$i"
done
# All return HTTP 401 — no HTTP 429 ever
Confirmed: 20 attempts in 0.07 seconds, no rate limiting enforced.
Fix
Implement DRF-style throttling on /auth/token:
// Track failed attempts per IP
private static final Cache<String, Integer> FAILED_ATTEMPTS =
CacheBuilder.newBuilder().expireAfterWrite(15, TimeUnit.MINUTES).build();
private static final int MAX_ATTEMPTS = 10;
private void handleToken(HandlerContext ctx) {
String ip = ctx.getRemoteAddress();
int attempts = Optional.ofNullable(FAILED_ATTEMPTS.getIfPresent(ip)).orElse(0);
if (attempts >= MAX_ATTEMPTS) {
throw new TooManyRequestsException("Rate limit exceeded");
}
// ... existing auth logic
// On failure: FAILED_ATTEMPTS.put(ip, attempts + 1)
}
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.yamcs:yamcs-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.12.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44596"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-27T00:04:28Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nThe authentication endpoint `POST /auth/token` in `yamcs-core` lacks any form of rate limiting, account lockout, or failed attempt throttling. As a result, an unauthenticated remote attacker can perform unlimited password guessing attempts against any user account.\n\nThis missing rate limiting vulnerability (CWE-307) significantly increases the risk of successful brute-force attacks.\n\n### Root Cause\n\n**File:** `yamcs-core/src/main/java/org/yamcs/http/auth/AuthHandler.java`\n\n`POST /auth/token` has no rate limiting, no lockout after failed attempts, and no CAPTCHA. The handler processes unlimited authentication requests without any throttling mechanism:\n\n```java\n// AuthHandler.java \u2014 handleToken()\n// No throttle, no failed attempt counter, no lockout\nprivate void handleToken(HandlerContext ctx) {\n ...\n getSecurityStore().login(token).whenComplete((info, err) -\u003e {\n // Directly attempts authentication with no rate check\n });\n}\n```\n\nThis is absent by default \u2014 the official quickstart and documentation contain no guidance on configuring rate limiting.\n\n### Impact\n\nAn attacker can make unlimited authentication attempts against any account. This enables efficient brute-force attacks against any account.\n\n### Proof of Concept\n\n```bash\n# 20 attempts \u2014 zero rate limiting\nfor i in $(seq 1 20); do\n curl -s -o /dev/null -w \"Attempt $i: HTTP %{http_code}\\n\" \\\n -X POST \"http://TARGET:8090/auth/token\" \\\n -d \"grant_type=password\u0026username=operator\u0026password=operator12$i\"\ndone\n# All return HTTP 401 \u2014 no HTTP 429 ever\n```\n\n**Confirmed:** 20 attempts in 0.07 seconds, no rate limiting enforced.\n\n### Fix\n\nImplement DRF-style throttling on `/auth/token`:\n\n```java\n// Track failed attempts per IP\nprivate static final Cache\u003cString, Integer\u003e FAILED_ATTEMPTS =\n CacheBuilder.newBuilder().expireAfterWrite(15, TimeUnit.MINUTES).build();\n\nprivate static final int MAX_ATTEMPTS = 10;\n\nprivate void handleToken(HandlerContext ctx) {\n String ip = ctx.getRemoteAddress();\n int attempts = Optional.ofNullable(FAILED_ATTEMPTS.getIfPresent(ip)).orElse(0);\n if (attempts \u003e= MAX_ATTEMPTS) {\n throw new TooManyRequestsException(\"Rate limit exceeded\");\n }\n // ... existing auth logic\n // On failure: FAILED_ATTEMPTS.put(ip, attempts + 1)\n}\n```",
"id": "GHSA-w5r6-mcgq-7pq4",
"modified": "2026-05-27T00:04:28Z",
"published": "2026-05-27T00:04:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yamcs/yamcs/security/advisories/GHSA-w5r6-mcgq-7pq4"
},
{
"type": "PACKAGE",
"url": "https://github.com/yamcs/yamcs"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Yamcs has No Rate Limiting on Authentication Endpoint"
}
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.