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.
1033 vulnerabilities reference this CWE, most recent first.
GHSA-22C4-JFR4-3Q58
Vulnerability from github – Published: 2026-09-08 18:31 – Updated: 2026-09-08 18:31WWBN AVideo through commit e01e41ecc (no patched version available) exposes get_api_preauthorize in plugin/API/API.php as a second, undocumented login path. Unlike get_api_signIn, which enforces a rate limit of 10 attempts per 5 minutes via checkRateLimit(), get_api_preauthorize performs the same credential check with no throttling for any client, allowing unlimited remote password guessing against arbitrary accounts, including admin. The endpoint also acts as a credential oracle: it returns the message "Invalid credentials" for both correct and incorrect passwords, while the users_id field in the response body discloses the authenticated identity (users_id:1 on success, users_id:0 on failure), and a correct password establishes a session cookie that remains usable for authenticated API requests. Together these issues permit unauthenticated brute-force account takeover.
{
"affected": [],
"aliases": [
"CVE-2026-86729"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-08T16:18:34Z",
"severity": "CRITICAL"
},
"details": "WWBN AVideo through commit e01e41ecc (no patched version available) exposes get_api_preauthorize in plugin/API/API.php as a second, undocumented login path. Unlike get_api_signIn, which enforces a rate limit of 10 attempts per 5 minutes via checkRateLimit(), get_api_preauthorize performs the same credential check with no throttling for any client, allowing unlimited remote password guessing against arbitrary accounts, including admin. The endpoint also acts as a credential oracle: it returns the message \"Invalid credentials\" for both correct and incorrect passwords, while the users_id field in the response body discloses the authenticated identity (users_id:1 on success, users_id:0 on failure), and a correct password establishes a session cookie that remains usable for authenticated API requests. Together these issues permit unauthenticated brute-force account takeover.",
"id": "GHSA-22c4-jfr4-3q58",
"modified": "2026-09-08T18:31:53Z",
"published": "2026-09-08T18:31:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-vvqm-mgc5-hhx3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86729"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/wwbn-avideo-unrestricted-authentication-attempts-via-get-api-preauthorize"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/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-22JV-36FH-M28X
Vulnerability from github – Published: 2024-07-09 12:30 – Updated: 2024-07-09 12:30A vulnerability has been identified in SINEMA Remote Connect Server (All versions < V3.2 SP1). The affected application does not properly implement brute force protection against user credentials in its Client Communication component. This could allow an attacker to learn user credentials that are vulnerable to brute force attacks.
{
"affected": [],
"aliases": [
"CVE-2024-39874"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-09T12:15:19Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in SINEMA Remote Connect Server (All versions \u003c V3.2 SP1). The affected application does not properly implement brute force protection against user credentials in its Client Communication component. This could allow an attacker to learn user credentials that are vulnerable to brute force attacks.",
"id": "GHSA-22jv-36fh-m28x",
"modified": "2024-07-09T12:30:58Z",
"published": "2024-07-09T12:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39874"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-381581.html"
}
],
"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-22PF-6RH7-89GJ
Vulnerability from github – Published: 2024-11-26 15:31 – Updated: 2024-11-26 15:31A vulnerability exists in NSD570 login panel that does not restrict excessive authentication attempts. If exploited, this could cause account takeover and unauthorized access to the system when an attacker conducts brute-force attacks against the equipment login. Note that the system supports only one concurrent session and implements a delay of more than a second between failed login attempts making it difficult to automate the attacks.
{
"affected": [],
"aliases": [
"CVE-2024-9928"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-26T14:15:22Z",
"severity": "MODERATE"
},
"details": "A vulnerability exists in NSD570 login panel that does not restrict excessive authentication attempts. If exploited, this could\ncause account takeover and unauthorized access to the system\nwhen an attacker conducts brute-force attacks against the\nequipment login. Note that the system supports only one concurrent session and implements a delay of more than a second\nbetween failed login attempts making it difficult to automate the\nattacks.",
"id": "GHSA-22pf-6rh7-89gj",
"modified": "2024-11-26T15:31:03Z",
"published": "2024-11-26T15:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9928"
},
{
"type": "WEB",
"url": "https://publisher.hitachienergy.com/preview?DocumentID=8DBD000173\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=launch"
}
],
"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-23WC-J7FG-6XP5
Vulnerability from github – Published: 2023-11-06 06:30 – Updated: 2023-11-06 06:30Improper Restriction of Excessive Authentication Attempts vulnerability in Mitsubishi Electric Corporation MELSEC iQ-F Series CPU modules Web server function allows a remote unauthenticated attacker to prevent legitimate users from logging into the Web server function for a certain period after the attacker has attempted to log in illegally by continuously attempting unauthorized login to the Web server function. The impact of this vulnerability will persist while the attacker continues to attempt unauthorized login.
{
"affected": [],
"aliases": [
"CVE-2023-4625"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-06T05:15:15Z",
"severity": "MODERATE"
},
"details": "Improper Restriction of Excessive Authentication Attempts vulnerability in Mitsubishi Electric Corporation MELSEC iQ-F Series CPU modules Web server function allows a remote unauthenticated attacker to prevent legitimate users from logging into the Web server function for a certain period after the attacker has attempted to log in illegally by continuously attempting unauthorized login to the Web server function. The impact of this vulnerability will persist while the attacker continues to attempt unauthorized login.",
"id": "GHSA-23wc-j7fg-6xp5",
"modified": "2023-11-06T06:30:26Z",
"published": "2023-11-06T06:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4625"
},
{
"type": "WEB",
"url": "https://jvn.jp/vu/JVNVU94620134"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-306-02"
},
{
"type": "WEB",
"url": "https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2023-014_en.pdf"
}
],
"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-245G-9F78-5JXC
Vulnerability from github – Published: 2023-08-24 18:30 – Updated: 2024-04-04 07:10There is no limit on the number of login attempts in the web server for the SNAP PAC S1 Firmware version R10.3b. This could allow for a brute-force attack on the built-in web server login.
{
"affected": [],
"aliases": [
"CVE-2023-40706"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-24T17:15:08Z",
"severity": "CRITICAL"
},
"details": "There is no limit on the number of login attempts in the web server for the SNAP PAC S1 Firmware version R10.3b. This could allow for a brute-force attack on the built-in web server login.",
"id": "GHSA-245g-9f78-5jxc",
"modified": "2024-04-04T07:10:46Z",
"published": "2023-08-24T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40706"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-236-02"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-24WR-GX4F-PWRH
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12VMware Workspace ONE Access and Identity Manager, unintentionally provide a login interface on port 7443. A malicious actor with network access to port 7443 may attempt user enumeration or brute force the login endpoint, which may or may not be practical based on lockout policy configuration and password complexity for the target account.
{
"affected": [],
"aliases": [
"CVE-2021-22003"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-31T22:15:00Z",
"severity": "HIGH"
},
"details": "VMware Workspace ONE Access and Identity Manager, unintentionally provide a login interface on port 7443. A malicious actor with network access to port 7443 may attempt user enumeration or brute force the login endpoint, which may or may not be practical based on lockout policy configuration and password complexity for the target account.",
"id": "GHSA-24wr-gx4f-pwrh",
"modified": "2022-05-24T19:12:51Z",
"published": "2022-05-24T19:12:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22003"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2021-0016.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-26WW-2C8F-2RGH
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15Dell BIOS contains an Improper Restriction of Excessive Authentication Attempts vulnerability. A local authenticated malicious administrator could exploit this vulnerability to bypass excessive NVMe password attempt mitigations in order to carry out a brute force attack.
{
"affected": [],
"aliases": [
"CVE-2021-36285"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-28T20:15:00Z",
"severity": "MODERATE"
},
"details": "Dell BIOS contains an Improper Restriction of Excessive Authentication Attempts vulnerability. A local authenticated malicious administrator could exploit this vulnerability to bypass excessive NVMe password attempt mitigations in order to carry out a brute force attack.",
"id": "GHSA-26ww-2c8f-2rgh",
"modified": "2022-05-24T19:15:56Z",
"published": "2022-05-24T19:15:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36285"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/000191495"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-274F-6W77-8QM9
Vulnerability from github – Published: 2026-09-22 14:44 – Updated: 2026-09-22 14:44Affected component: Sync-in Server v2.3.0, POST /api/app/sync/register.
Required attacker capability: Valid login and password for a TOTP-enabled account with desktop sync permission.
Summary
POST /api/app/sync/register accepts credentials and a TOTP code to register a desktop sync client. In the vulnerable version, on a failed TOTP attempt, SyncClientsManager.register() called updateAccesses(user, ip, false), which hit a freeze branch that wrote passwordAttempts back unchanged. The counter never reached USER_MAX_PASSWORD_ATTEMPTS (10), so the account lockout gate never fired for repeated TOTP failures through this endpoint.
A successful TOTP guess registers a sync client and returns a {clientId, clientToken} pair, provided the account has the required desktop app permission and the registration payload is valid. The token can then be exchanged via POST /api/app/sync/auth/cookie for an authenticated session. While the guessed TOTP code is still valid, and because the attacker already knows the password, the attacker can also call POST /api/auth/2fa/disable to remove MFA.
Details
The endpoint is declared at sync.controller.ts line 71. @AuthTokenSkip() bypasses the bearer-token guard, so the route is reachable without any prior session:
@Post(SYNC_ROUTE.REGISTER)
@AuthTokenSkip()
register(@Body() syncClientRegistrationDto: SyncClientRegistrationDto, @Req() req: FastifyRequest): Promise<SyncClientAuthRegistration> {
return this.syncClientsManager.register(syncClientRegistrationDto, req.ip)
}
Inside SyncClientsManager.register(), after both the TOTP code and the recovery code are rejected, the handler fires a fire-and-forget access update and throws (sync-clients-manager.service.ts line 73):
this.usersManager.updateAccesses(user, ip, false).catch((e: Error) => this.logger.error({ tag: this.register.name, msg: `${e}` }))
throw new HttpException(authCode.message, HttpStatus.UNAUTHORIZED)
In the vulnerable version, updateAccesses() at users-manager.service.ts line 182 defaulted isAuthTwoFa to false:
async updateAccesses(user: UserModel, ip: string, success: boolean, isAuthTwoFa = false) {
let passwordAttempts: number
if (!isAuthTwoFa && configuration.auth.mfa.totp.enabled && user.twoFaEnabled) {
passwordAttempts = user.passwordAttempts
} else {
passwordAttempts = success ? 0 : Math.min(user.passwordAttempts + 1, USER_MAX_PASSWORD_ATTEMPTS)
}
await this.usersQueries.updateUserOrGuest(user.id, {
...
passwordAttempts: passwordAttempts,
isActive: user.isActive && passwordAttempts < USER_MAX_PASSWORD_ATTEMPTS
})
}
When register() called updateAccesses(user, ip, false), isAuthTwoFa defaulted to false. The condition on line 184 evaluated to true when TOTP was enabled site-wide and the account had it active. The else branch with Math.min(user.passwordAttempts + 1, ...) was never reached. passwordAttempts was written back unchanged, and the lockout gate in validateUserAccess() at line 89 never fired for repeated TOTP failures through this endpoint.
The freeze was designed for the web login flow, where a correct password at POST /api/auth/login produces a partial session and the counter should be preserved until POST /api/auth/2fa/login/verify completes. That route calls authProvider2FA.verify(body, req, true), which passes isAuthTwoFa=true into updateAccesses() and correctly increments on 2FA failure. The register() endpoint reused updateAccesses() for an outright TOTP rejection while passing the default isAuthTwoFa=false, triggering the freeze incorrectly.
The same freeze also applied to logUser() (users-manager.service.ts line 69), called by both POST /api/auth/login and POST /api/auth/token. On a wrong password for a 2FA-enabled account, updateAccesses(user, ip, false) was called without an isAuthTwoFa argument, so the freeze fired and passwordAttempts was preserved rather than incremented.
PoC
First, create a test account with TOTP MFA enabled and desktop sync permission. Then run the following:
$ python3 poc_totp_bruteforce.py --url http://192.168.16.132:8080 --user mfatest --password 'Str0ngP@ss99!' --concurrency 4 --batch 100
Example output:
[*] Target : http://192.168.16.132:8080
[*] Account : mfatest
[*] Concurrency : 4
[*] Step 1: Confirming credentials and 2FA status...
[+] Credentials valid, 2FA active.
[*] Step 2: Brute-forcing TOTP codes (4 workers)...
Ranges: W0=000000-250000, W1=250000-500000, W2=500000-750000, W3=750000-1000000
[W2] 1,100 total | 11.3 req/s | retries: 0
<snip>
[W1] 195,400 total | 11.0 req/s | retries: 0
[*] Step 3: Results
Total attempts : 195,907
Time elapsed : 17769.5s (296.2min)
Average RPS : 11.0
[+] VALID TOTP CODE FOUND : 026961
[+] clientId : 13951b88-03d4-4854-8a29-cd8921d73d82
[+] clientToken : c92ef5ca-7432-44d0-8a94-56398bfe4117
[*] Step 4: Confirming access and attempting to disable 2FA...
[+] Authenticated as : mfatest (id=3, role=1)
passwordAttempts : 0
[+] 2FA DISABLED. Account 'mfatest' now accessible with password alone.
Measured observations:
- No account lockout was observed across 195,907 failed TOTP attempts in this test against the vulnerable version.
- The
clientTokenwas exchanged for an authenticated session. - MFA was disabled via
POST /api/auth/2fa/disablewhile the guessed TOTP code was still valid and because the attacker already knew the account password.
Impact
An attacker who already knows valid credentials for a TOTP-enabled account with desktop sync permission can brute-force the second factor through POST /api/app/sync/register without triggering account lockout.
With drift: 1, 3 of 1,000,000 six-digit codes are valid per 30-second window (p = 3/1,000,000), giving an expected 333,333 attempts to find a valid code.
At 3 r/s, measured against a default single-worker deployment:
| Success probability | Attempts | Time at 3 r/s |
|---|---|---|
| 50% | 231,049 | 21.4 h |
| 90% | 767,528 | 71.1 h |
| 95% | 998,577 | 92.5 h |
| 99% | 1,535,056 | 142.1 h |
| Expected (mean) | 333,333 | 30.9 h |
Deployments with server.workers > 1 may allow higher throughput, depending on CPU capacity and other bottlenecks. Throughput is heavily influenced by server-side password verification cost, worker count, database latency, and deployment limits, not only by the attacker's network speed.
Remediation
Add && success to the freeze condition at users-manager.service.ts line 184:
// Before
if (!isAuthTwoFa && configuration.auth.mfa.totp.enabled && user.twoFaEnabled) {
// After
if (!isAuthTwoFa && configuration.auth.mfa.totp.enabled && user.twoFaEnabled && success) {
The freeze still applies when a password succeeds but 2FA is pending, which was its intended purpose. A failed TOTP at register() and a failed password at login/token both fall through to the increment path, restoring lockout after 10 failures.
For defense-in-depth, apply an IP and/or account-based rate limiter to POST /api/app/sync/register and other pre-auth credential endpoints.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.3.0"
},
"package": {
"ecosystem": "npm",
"name": "@sync-in/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58271"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T14:44:43Z",
"nvd_published_at": "2026-09-21T20:17:26Z",
"severity": "MODERATE"
},
"details": "**Affected component:** Sync-in Server v2.3.0, `POST /api/app/sync/register`.\n\n**Required attacker capability:** Valid login and password for a TOTP-enabled account with desktop sync permission.\n\n## Summary\n\n`POST /api/app/sync/register` accepts credentials and a TOTP code to register a desktop sync client. In the vulnerable version, on a failed TOTP attempt, `SyncClientsManager.register()` called `updateAccesses(user, ip, false)`, which hit a freeze branch that wrote `passwordAttempts` back unchanged. The counter never reached `USER_MAX_PASSWORD_ATTEMPTS` (10), so the account lockout gate never fired for repeated TOTP failures through this endpoint.\n\nA successful TOTP guess registers a sync client and returns a `{clientId, clientToken}` pair, provided the account has the required desktop app permission and the registration payload is valid. The token can then be exchanged via `POST /api/app/sync/auth/cookie` for an authenticated session. While the guessed TOTP code is still valid, and because the attacker already knows the password, the attacker can also call `POST /api/auth/2fa/disable` to remove MFA.\n\n## Details\n\nThe endpoint is declared at `sync.controller.ts` line 71. `@AuthTokenSkip()` bypasses the bearer-token guard, so the route is reachable without any prior session:\n```typescript\n@Post(SYNC_ROUTE.REGISTER)\n@AuthTokenSkip()\nregister(@Body() syncClientRegistrationDto: SyncClientRegistrationDto, @Req() req: FastifyRequest): Promise\u003cSyncClientAuthRegistration\u003e {\n return this.syncClientsManager.register(syncClientRegistrationDto, req.ip)\n}\n```\nInside `SyncClientsManager.register()`, after both the TOTP code and the recovery code are rejected, the handler fires a fire-and-forget access update and throws (`sync-clients-manager.service.ts` line 73):\n```typescript\nthis.usersManager.updateAccesses(user, ip, false).catch((e: Error) =\u003e this.logger.error({ tag: this.register.name, msg: `${e}` }))\nthrow new HttpException(authCode.message, HttpStatus.UNAUTHORIZED)\n```\n\nIn the vulnerable version, `updateAccesses()` at `users-manager.service.ts` line 182 defaulted `isAuthTwoFa` to `false`:\n\n```typescript\nasync updateAccesses(user: UserModel, ip: string, success: boolean, isAuthTwoFa = false) {\n let passwordAttempts: number\n if (!isAuthTwoFa \u0026\u0026 configuration.auth.mfa.totp.enabled \u0026\u0026 user.twoFaEnabled) {\n passwordAttempts = user.passwordAttempts\n } else {\n passwordAttempts = success ? 0 : Math.min(user.passwordAttempts + 1, USER_MAX_PASSWORD_ATTEMPTS)\n }\n await this.usersQueries.updateUserOrGuest(user.id, {\n ...\n passwordAttempts: passwordAttempts,\n isActive: user.isActive \u0026\u0026 passwordAttempts \u003c USER_MAX_PASSWORD_ATTEMPTS\n })\n}\n```\n\nWhen `register()` called `updateAccesses(user, ip, false)`, `isAuthTwoFa` defaulted to `false`. The condition on line 184 evaluated to `true` when TOTP was enabled site-wide and the account had it active. The `else` branch with `Math.min(user.passwordAttempts + 1, ...)` was never reached. `passwordAttempts` was written back unchanged, and the lockout gate in `validateUserAccess()` at line 89 never fired for repeated TOTP failures through this endpoint.\n\nThe freeze was designed for the web login flow, where a correct password at `POST /api/auth/login` produces a partial session and the counter should be preserved until `POST /api/auth/2fa/login/verify` completes. That route calls `authProvider2FA.verify(body, req, true)`, which passes `isAuthTwoFa=true` into `updateAccesses()` and correctly increments on 2FA failure. The `register()` endpoint reused `updateAccesses()` for an outright TOTP rejection while passing the default `isAuthTwoFa=false`, triggering the freeze incorrectly.\n\nThe same freeze also applied to `logUser()` (`users-manager.service.ts` line 69), called by both `POST /api/auth/login` and `POST /api/auth/token`. On a wrong password for a 2FA-enabled account, `updateAccesses(user, ip, false)` was called without an `isAuthTwoFa` argument, so the freeze fired and `passwordAttempts` was preserved rather than incremented.\n\n## PoC\n\nFirst, create a test account with TOTP MFA enabled and desktop sync permission. Then run the following:\n\n[poc_totp_bruteforce.py](https://github.com/user-attachments/files/28857878/poc_totp_bruteforce.py)\n\n```bash\n$ python3 poc_totp_bruteforce.py --url http://192.168.16.132:8080 --user mfatest --password \u0027Str0ngP@ss99!\u0027 --concurrency 4 --batch 100\n```\n\nExample output:\n\n```text\n[*] Target : http://192.168.16.132:8080\n[*] Account : mfatest\n[*] Concurrency : 4\n\n[*] Step 1: Confirming credentials and 2FA status...\n[+] Credentials valid, 2FA active.\n\n[*] Step 2: Brute-forcing TOTP codes (4 workers)...\n Ranges: W0=000000-250000, W1=250000-500000, W2=500000-750000, W3=750000-1000000\n [W2] 1,100 total | 11.3 req/s | retries: 0\n \u003csnip\u003e\n [W1] 195,400 total | 11.0 req/s | retries: 0\n\n[*] Step 3: Results\n Total attempts : 195,907\n Time elapsed : 17769.5s (296.2min)\n Average RPS : 11.0\n\n[+] VALID TOTP CODE FOUND : 026961\n[+] clientId : 13951b88-03d4-4854-8a29-cd8921d73d82\n[+] clientToken : c92ef5ca-7432-44d0-8a94-56398bfe4117\n\n[*] Step 4: Confirming access and attempting to disable 2FA...\n [+] Authenticated as : mfatest (id=3, role=1)\n passwordAttempts : 0\n [+] 2FA DISABLED. Account \u0027mfatest\u0027 now accessible with password alone.\n```\n\n**Measured observations:**\n\n- No account lockout was observed across 195,907 failed TOTP attempts in this test against the vulnerable version.\n- The `clientToken` was exchanged for an authenticated session.\n- MFA was disabled via `POST /api/auth/2fa/disable` while the guessed TOTP code was still valid and because the attacker already knew the account password.\n\n## Impact\n\nAn attacker who already knows valid credentials for a TOTP-enabled account with desktop sync permission can brute-force the second factor through `POST /api/app/sync/register` without triggering account lockout.\n\nWith `drift: 1`, 3 of 1,000,000 six-digit codes are valid per 30-second window (`p = 3/1,000,000`), giving an expected 333,333 attempts to find a valid code.\n\nAt 3 r/s, measured against a default single-worker deployment:\n\n| Success probability | Attempts | Time at 3 r/s |\n|---|---:|---:|\n| 50% | 231,049 | 21.4 h |\n| 90% | 767,528 | 71.1 h |\n| 95% | 998,577 | 92.5 h |\n| 99% | 1,535,056 | 142.1 h |\n| Expected (mean) | 333,333 | 30.9 h |\n\nDeployments with `server.workers \u003e 1` may allow higher throughput, depending on CPU capacity and other bottlenecks. Throughput is heavily influenced by server-side password verification cost, worker count, database latency, and deployment limits, not only by the attacker\u0027s network speed.\n\n## Remediation\n\nAdd `\u0026\u0026 success` to the freeze condition at `users-manager.service.ts` line 184:\n\n```typescript\n// Before\nif (!isAuthTwoFa \u0026\u0026 configuration.auth.mfa.totp.enabled \u0026\u0026 user.twoFaEnabled) {\n\n// After\nif (!isAuthTwoFa \u0026\u0026 configuration.auth.mfa.totp.enabled \u0026\u0026 user.twoFaEnabled \u0026\u0026 success) {\n```\n\nThe freeze still applies when a password succeeds but 2FA is pending, which was its intended purpose. A failed TOTP at `register()` and a failed password at `login`/`token` both fall through to the increment path, restoring lockout after 10 failures.\n\nFor defense-in-depth, apply an IP and/or account-based rate limiter to `POST /api/app/sync/register` and other pre-auth credential endpoints.",
"id": "GHSA-274f-6w77-8qm9",
"modified": "2026-09-22T14:44:43Z",
"published": "2026-09-22T14:44:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/security/advisories/GHSA-274f-6w77-8qm9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58271"
},
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/pull/228"
},
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/commit/b13a4aad5c2b38fe8231a0d007cd08a086ec5bdb"
},
{
"type": "PACKAGE",
"url": "https://github.com/Sync-in/server"
},
{
"type": "WEB",
"url": "https://github.com/Sync-in/server/releases/tag/v2.4.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "@sync-in/server vulnerable to TOTP Brute-Force via `POST /api/app/sync/register`"
}
GHSA-27MC-9399-R9MX
Vulnerability from github – Published: 2025-10-30 00:31 – Updated: 2025-10-30 17:05Improper Restriction of Excessive Authentication Attempts vulnerability in Drupal Access code allows Brute Force. This issue affects Access code: from 0.0.0 before 2.0.5.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/access_code"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-10928"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-30T17:05:05Z",
"nvd_published_at": "2025-10-30T00:15:34Z",
"severity": "MODERATE"
},
"details": "Improper Restriction of Excessive Authentication Attempts vulnerability in Drupal Access code allows Brute Force. This issue affects Access code: from 0.0.0 before 2.0.5.",
"id": "GHSA-27mc-9399-r9mx",
"modified": "2025-10-30T17:05:06Z",
"published": "2025-10-30T00:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10928"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-contrib-2025-108"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Drupal Access code allows Brute Force Attempts"
}
GHSA-27X5-H3JG-F385
Vulnerability from github – Published: 2024-06-24 15:31 – Updated: 2026-06-03 15:30Improper Restriction of Excessive Authentication Attempts vulnerability in Mia Technology Inc. Mia-Med Health Aplication allows Interface Manipulation.This issue affects Mia-Med Health Aplication: before 1.0.14.
{
"affected": [],
"aliases": [
"CVE-2024-5862"
],
"database_specific": {
"cwe_ids": [
"CWE-307"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-24T13:15:12Z",
"severity": "HIGH"
},
"details": "Improper Restriction of Excessive Authentication Attempts vulnerability in Mia Technology Inc. Mia-Med Health Aplication allows Interface Manipulation.This issue affects Mia-Med Health Aplication: before 1.0.14.",
"id": "GHSA-27x5-h3jg-f385",
"modified": "2026-06-03T15:30:33Z",
"published": "2024-06-24T15:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5862"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-24-0765"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-24-0765"
}
],
"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"
}
]
}
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.