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.

1027 vulnerabilities reference this CWE, most recent first.

GHSA-VM4W-8V23-V75W

Vulnerability from github – Published: 2022-10-13 12:00 – Updated: 2022-10-15 12:01
VLAI
Details

Dell EMC XtremIO versions prior to X2 6.4.0-22 contain a bruteforce vulnerability. A remote unauthenticated attacker can potentially exploit this vulnerability and gain access to an admin account.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-31228"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-12T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Dell EMC XtremIO versions prior to X2 6.4.0-22 contain a bruteforce vulnerability. A remote unauthenticated attacker can potentially exploit this vulnerability and gain access to an admin account.",
  "id": "GHSA-vm4w-8v23-v75w",
  "modified": "2022-10-15T12:01:02Z",
  "published": "2022-10-13T12:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31228"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000204112/dsa-2022-145-dell-emc-xtremeio-for-ssh-and-web-ui-vulnerability"
    }
  ],
  "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-VMFM-CH9H-5C7G

Vulnerability from github – Published: 2026-05-04 20:52 – Updated: 2026-05-13 13:41
VLAI
Summary
Signal K Server's WebSocket Login Endpoint Lacks Rate Limiting (Credential Brute-Force)
Details

Summary

The HTTP login endpoints (POST /login and POST /signalk/v1/auth/login) are protected by express-rate-limit (default: 100 attempts per 10-minute window, configurable via HTTP_RATE_LIMITS). The WebSocket login path — sending {login: {username, password}} messages over an established WebSocket connection — calls app.securityStrategy.login() directly without any rate limiting.

An attacker can bypass HTTP rate limiting entirely by opening a WebSocket connection and attempting unlimited password guesses at the speed bcrypt allows (~20 attempts/sec with 10 salt rounds).

Details

Vulnerable code: src/interfaces/ws.ts, function processLoginRequest (lines 753-780)

The function directly calls app.securityStrategy.login(msg.login.username, msg.login.password) with no throttling or attempt tracking.

Rate-limited HTTP path for comparison: src/tokensecurity.ts lines 609-617 apply loginLimiter middleware to the HTTP login routes at line 637.

Steps to Reproduce

  1. Start Signal K server with security enabled
  2. Open a WebSocket connection to ws://server:3000/signalk/v1/stream?subscribe=none
  3. Wait for the hello message
  4. Send login attempts in rapid succession: json {"requestId": "1", "login": {"username": "admin", "password": "guess1"}} {"requestId": "2", "login": {"username": "admin", "password": "guess2"}}
  5. Observe that all attempts are processed without any 429 response or throttling
  6. For comparison, send 100+ HTTP POST requests to /signalk/v1/auth/login — the 101st returns 429

A POC script is available that demonstrates both the HTTP rate limiting working correctly and the WebSocket path accepting unlimited attempts.

Impact

  • Credential brute-forcing via the WebSocket protocol at ~20 attempts/sec (bcrypt-limited)
  • Complete bypass of the HTTP rate limiting defense
  • A single WebSocket connection is sufficient for unlimited attempts
  • With multiple parallel connections, throughput multiplies
  • A 10,000-word dictionary attack completes in ~8 minutes over a single connection

Signal K servers are commonly deployed on boat networks where they may be accessible to other devices on the same LAN.

CWE

CWE-307: Improper Restriction of Excessive Authentication Attempts

Suggested Fix

Track failed login attempts per remote IP in a shared store (or reuse the existing express-rate-limit store) that is checked in both the HTTP login middleware and the processLoginRequest WebSocket handler.

Context

Found while building an open source maritime security scanner. Verified on v2.24.0 (current master).

Discovered by Mark Curphey

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.24.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "signalk-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.25.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T20:52:06Z",
    "nvd_published_at": "2026-05-09T20:16:27Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe HTTP login endpoints (`POST /login` and `POST /signalk/v1/auth/login`) are protected by `express-rate-limit` (default: 100 attempts per 10-minute window, configurable via `HTTP_RATE_LIMITS`). The WebSocket login path \u2014 sending `{login: {username, password}}` messages over an established WebSocket connection \u2014 calls `app.securityStrategy.login()` directly without any rate limiting.\n\nAn attacker can bypass HTTP rate limiting entirely by opening a WebSocket connection and attempting unlimited password guesses at the speed bcrypt allows (~20 attempts/sec with 10 salt rounds).\n\n## Details\n\n**Vulnerable code:** `src/interfaces/ws.ts`, function `processLoginRequest` (lines 753-780)\n\nThe function directly calls `app.securityStrategy.login(msg.login.username, msg.login.password)` with no throttling or attempt tracking.\n\n**Rate-limited HTTP path for comparison:** `src/tokensecurity.ts` lines 609-617 apply `loginLimiter` middleware to the HTTP login routes at line 637.\n\n## Steps to Reproduce\n\n1. Start Signal K server with security enabled\n2. Open a WebSocket connection to `ws://server:3000/signalk/v1/stream?subscribe=none`\n3. Wait for the hello message\n4. Send login attempts in rapid succession:\n   ```json\n   {\"requestId\": \"1\", \"login\": {\"username\": \"admin\", \"password\": \"guess1\"}}\n   {\"requestId\": \"2\", \"login\": {\"username\": \"admin\", \"password\": \"guess2\"}}\n   ```\n5. Observe that all attempts are processed without any 429 response or throttling\n6. For comparison, send 100+ HTTP POST requests to `/signalk/v1/auth/login` \u2014 the 101st returns 429\n\nA POC script is available that demonstrates both the HTTP rate limiting working correctly and the WebSocket path accepting unlimited attempts.\n\n## Impact\n\n- Credential brute-forcing via the WebSocket protocol at ~20 attempts/sec (bcrypt-limited)\n- Complete bypass of the HTTP rate limiting defense\n- A single WebSocket connection is sufficient for unlimited attempts\n- With multiple parallel connections, throughput multiplies\n- A 10,000-word dictionary attack completes in ~8 minutes over a single connection\n\nSignal K servers are commonly deployed on boat networks where they may be accessible to other devices on the same LAN.\n\n## CWE\n\nCWE-307: Improper Restriction of Excessive Authentication Attempts\n\n## Suggested Fix\n\nTrack failed login attempts per remote IP in a shared store (or reuse the existing express-rate-limit store) that is checked in both the HTTP login middleware and the processLoginRequest WebSocket handler.\n\n## Context\n\nFound while building an open source maritime security scanner. Verified on v2.24.0 (current master).\n\nDiscovered by Mark Curphey",
  "id": "GHSA-vmfm-ch9h-5c7g",
  "modified": "2026-05-13T13:41:34Z",
  "published": "2026-05-04T20:52:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SignalK/signalk-server/security/advisories/GHSA-vmfm-ch9h-5c7g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41893"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SignalK/signalk-server/pull/2568"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SignalK/signalk-server/commit/215d81eb700d5419c3396a0fbf23f2e246dfac2d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SignalK/signalk-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SignalK/signalk-server/releases/tag/v2.25.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Signal K Server\u0027s WebSocket Login Endpoint Lacks Rate Limiting (Credential Brute-Force)"
}

GHSA-VP33-G4HG-RCWQ

Vulnerability from github – Published: 2024-09-11 12:30 – Updated: 2024-09-11 12:30
VLAI
Details

An improper authorization vulnerability [CWE-285] in FortiSOAR version 7.4.0 through 7.4.3, 7.3.0 through 7.3.2, 7.2.0 through 7.2.2, 7.0.0 through 7.0.3 change password endpoint may allow an authenticated attacker to perform a brute force attack on users and administrators password via crafted HTTP requests.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-45327"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-11T10:15:02Z",
    "severity": "HIGH"
  },
  "details": "An improper authorization vulnerability [CWE-285] in FortiSOAR version 7.4.0 through 7.4.3, 7.3.0 through 7.3.2, 7.2.0 through 7.2.2, 7.0.0 through 7.0.3 change password endpoint may allow an authenticated attacker to perform a brute force attack on users and administrators password via crafted HTTP requests.",
  "id": "GHSA-vp33-g4hg-rcwq",
  "modified": "2024-09-11T12:30:51Z",
  "published": "2024-09-11T12:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45327"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-048"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQ9X-W82R-RHMC

Vulnerability from github – Published: 2025-08-13 15:30 – Updated: 2025-08-20 15:54
VLAI
Summary
Soosyze CMS's /user/login endpoint missing rate-limiting and lockout mechanisms
Details

Soosyze CMS 2.0 allows brute-force login attacks via the /user/login endpoint due to missing rate-limiting and lockout mechanisms. An attacker can repeatedly submit login attempts without restrictions, potentially gaining unauthorized administrative access. This vulnerability corresponds to CWE-307: Improper Restriction of Excessive Authentication Attempts.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "soosyze/soosyze"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-52392"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-13T23:13:41Z",
    "nvd_published_at": "2025-08-13T14:15:31Z",
    "severity": "HIGH"
  },
  "details": "Soosyze CMS 2.0 allows brute-force login attacks via the /user/login endpoint due to missing rate-limiting and lockout mechanisms. An attacker can repeatedly submit login attempts without restrictions, potentially gaining unauthorized administrative access. This vulnerability corresponds to CWE-307: Improper Restriction of Excessive Authentication Attempts.",
  "id": "GHSA-vq9x-w82r-rhmc",
  "modified": "2025-08-20T15:54:59Z",
  "published": "2025-08-13T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52392"
    },
    {
      "type": "WEB",
      "url": "https://github.com/soosyze/soosyze/issues/269"
    },
    {
      "type": "WEB",
      "url": "https://beafn28.gitbook.io/beafn28/cve/brute-force-login-vulnerability-in-soosyze-cms-2.0-cve-2025-52392"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/soosyze/soosyze"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/52416"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Soosyze CMS\u0027s /user/login endpoint missing rate-limiting and lockout mechanisms"
}

GHSA-VQPR-CWPG-2999

Vulnerability from github – Published: 2022-12-26 06:30 – Updated: 2023-01-05 18:30
VLAI
Details

Weak password derivation for export in Devolutions Remote Desktop Manager before 2022.1 allows information disclosure via a password brute-force attack. An error caused base64 to be decoded.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-26964"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-26T06:15:00Z",
    "severity": "HIGH"
  },
  "details": "Weak password derivation for export in Devolutions Remote Desktop Manager before 2022.1 allows information disclosure via a password brute-force attack. An error caused base64 to be decoded.",
  "id": "GHSA-vqpr-cwpg-2999",
  "modified": "2023-01-05T18:30:29Z",
  "published": "2022-12-26T06:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26964"
    },
    {
      "type": "WEB",
      "url": "https://devolutions.net/security/advisories/DEVO-2022-0002"
    }
  ],
  "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-VRW5-9J4X-CHW5

Vulnerability from github – Published: 2026-08-24 21:33 – Updated: 2026-08-24 21:33
VLAI
Details

RansomLook contains multiple weaknesses in its authentication endpoint that allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially exhaust application worker resources.

For local authentication, the login implementation previously checked whether a submitted username existed before invoking the password hash verification function. Requests containing a nonexistent username therefore returned significantly faster than requests for valid accounts, for which the computationally expensive password verification routine was executed. A remote attacker could measure these response-time differences to determine which usernames correspond to valid RansomLook accounts.

In addition, the /login endpoint did not restrict the number or frequency of failed authentication attempts. An attacker could consequently perform password brute-force, dictionary, password-spraying, or credential-stuffing attacks against known accounts without server-side throttling. For valid usernames, each authentication attempt also invokes the password key-derivation function, which consumes a significant amount of CPU time. A sufficiently high rate of login attempts could therefore occupy the application's synchronous Gunicorn workers and cause a denial of service affecting the entire application.

The issue has been addressed by always performing password verification using a randomly generated dummy password hash when the supplied username does not exist, eliminating the username-dependent timing discrepancy. Failed authentication attempts are additionally rate-limited per client IP address using Valkey/Redis, with five failed attempts within five minutes resulting in a one-hour block. The reverse-proxy configuration was also updated so that the application derives the client address from a trusted X-Forwarded-For value that cannot be overridden by a client-supplied header.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-78551"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-24T20:17:23Z",
    "severity": "HIGH"
  },
  "details": "RansomLook contains multiple weaknesses in its authentication endpoint that allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially exhaust application worker resources.\n\nFor local authentication, the login implementation previously checked whether a submitted username existed before invoking the password hash verification function. Requests containing a nonexistent username therefore returned significantly faster than requests for valid accounts, for which the computationally expensive password verification routine was executed. A remote attacker could measure these response-time differences to determine which usernames correspond to valid RansomLook accounts.\n\nIn addition, the /login endpoint did not restrict the number or frequency of failed authentication attempts. An attacker could consequently perform password brute-force, dictionary, password-spraying, or credential-stuffing attacks against known accounts without server-side throttling. For valid usernames, each authentication attempt also invokes the password key-derivation function, which consumes a significant amount of CPU time. A sufficiently high rate of login attempts could therefore occupy the application\u0027s synchronous Gunicorn workers and cause a denial of service affecting the entire application.\n\nThe issue has been addressed by always performing password verification using a randomly generated dummy password hash when the supplied username does not exist, eliminating the username-dependent timing discrepancy. Failed authentication attempts are additionally rate-limited per client IP address using Valkey/Redis, with five failed attempts within five minutes resulting in a one-hour block. The reverse-proxy configuration was also updated so that the application derives the client address from a trusted X-Forwarded-For value that cannot be overridden by a client-supplied header.",
  "id": "GHSA-vrw5-9j4x-chw5",
  "modified": "2026-08-24T21:33:45Z",
  "published": "2026-08-24T21:33:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78551"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RansomLook/RansomLook/commit/8602740347b0e928ad9fbaf5bc6ff242337dec6b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/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-VV3H-7QWR-722V

Vulnerability from github – Published: 2026-03-11 15:33 – Updated: 2026-03-24 21:11
VLAI
Summary
Anytype Heart's gRPC API client challenge verification can be bypassed on localhost
Details

Impact

The challenge-based authentication for the local gRPC client API can be bypassed, allowing an attacker to gain access without the 4-digit code.

Affected components: - Anytype Desktop (all platforms) ≤ v0.48.2 - Anytype-CLI (headless deployments) ≤ v0.1.9

Not affected: - Anytype mobile apps (iOS, Android) - do not expose a local gRPC server

Who is impacted: This vulnerability is scoped to localhost. The gRPC and gRPC-Web ports bind to 127.0.0.1 only and are not exposed to the local network or internet.

Exploitation requires:

  • Local user-level access to the machine running Anytype
  • Discovery of the randomized listening port
  • A running Anytype instance

Anytype-CLI headless deployments may be at higher risk only if an administrator has chosen to set up their own reverse proxy and configured it in a way that exposes gRPC or gRPC-Web ports to an external network. By default, these ports are not externally accessible and there is no built-in mechanism to expose them.

Patches

Workarounds

  • Desktop users: No immediate action required. The vulnerability requires existing local access to the machine.
  • Anytype-CLI administrators: If using a custom reverse proxy, ensure it does not expose gRPC or gRPC-Web ports to external networks.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/anyproto/anytype-heart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.48.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/anyproto/anytype-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31863"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-11T15:33:29Z",
    "nvd_published_at": "2026-03-11T18:16:25Z",
    "severity": "LOW"
  },
  "details": "#### Impact\nThe challenge-based authentication for the local gRPC client API can be bypassed, allowing an attacker to gain access without the 4-digit code.\n\nAffected components:\n- Anytype Desktop (all platforms) \u2264 v0.48.2\n- Anytype-CLI (headless deployments) \u2264 v0.1.9\n\nNot affected:\n- Anytype mobile apps (iOS, Android) - do not expose a local gRPC server\n\nWho is impacted:\nThis vulnerability is scoped to localhost. The gRPC and gRPC-Web ports bind to 127.0.0.1 only and are not exposed to the local network or internet.\n\n### Exploitation requires:\n- Local user-level access to the machine running Anytype\n- Discovery of the randomized listening port\n- A running Anytype instance\n\nAnytype-CLI headless deployments may be at higher risk only if an administrator has chosen to set up their own reverse proxy and configured it in a way that\nexposes gRPC or gRPC-Web ports to an external network. **By default, these ports are not externally accessible and there is no built-in mechanism to expose them.**\n\n#### Patches\n- anytype-heart library: v0.48.4\n- [Anytype Desktop](https://github.com/anyproto/anytype-ts): v0.54.5\n- [Anytype-CLI](https://github.com/anyproto/anytype-cli): v0.1.11\n\n#### Workarounds\n- Desktop users: No immediate action required. The vulnerability requires existing local access to the machine.\n- Anytype-CLI administrators: If using a custom reverse proxy, ensure it does not expose gRPC or gRPC-Web ports to external networks.",
  "id": "GHSA-vv3h-7qwr-722v",
  "modified": "2026-03-24T21:11:53Z",
  "published": "2026-03-11T15:33:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/anyproto/anytype-heart/security/advisories/GHSA-vv3h-7qwr-722v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31863"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anyproto/anytype-cli"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/anyproto/anytype-heart"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anyproto/anytype-ts"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4680"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Anytype Heart\u0027s gRPC API client challenge verification can be bypassed on localhost"
}

GHSA-VVGV-54PP-4XR8

Vulnerability from github – Published: 2023-07-07 00:30 – Updated: 2024-04-04 05:50
VLAI
Details

The number of login attempts is not limited. This could allow an attacker to perform a brute force on HTTP basic authentication.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-33868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-06T23:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "\n\n\nThe number of login attempts is not limited. This could allow an attacker to perform a brute force on HTTP basic authentication.\n\n\n\n",
  "id": "GHSA-vvgv-54pp-4xr8",
  "modified": "2024-04-04T05:50:06Z",
  "published": "2023-07-07T00:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33868"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-187-01"
    }
  ],
  "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"
    }
  ]
}

GHSA-VVXM-2VXQ-RHGQ

Vulnerability from github – Published: 2024-09-18 12:31 – Updated: 2026-06-03 15:30
VLAI
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.

Show details on source website

{
  "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:31
VLAI
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.

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.

Show details on source website

{
  "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"
    }
  ]
}

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.