| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.4, the PIN-type challenge throttle uses `emailHash` as the only key. The throttle rows live in the central `challenge_throttle` table, which is shared across all tenants. Every tenant's `/api/tenants/{id}/appointments/verify-challenge` endpoint increments the same row when a PIN response fails, and every tenant's `/api/tenants/{id}/appointments/challenge` endpoint reads the same row when deciding whether to issue a new challenge. When the same `emailHash` exists in multiple tenants on the same OpenReception instance (the same patient holding tunnels in two different clinics that share the platform), an attacker who knows the patient's email can lock out that patient on tenant B by issuing failed challenge responses against tenant A. The attacker needs no relationship to tenant B; the lockout propagates through the shared throttle row. The lockout escalates with repeated failures. The first lockout triggers at 4 failed attempts and lasts approximately 60 seconds. Subsequent failures escalate the lockout duration to 5 minutes, 30 minutes, and 60 minutes per the throttle service's escalation logic. Repeated bursts produce sustained denial of service against the targeted email. Version 1.0.4 patches the issue. |
| The miniOrange 2FA WordPress plugin before 6.2.8 does not correctly limit the number of second-factor verification attempts, tracking them against a client-supplied identifier that is reissued on every login, allowing an attacker who already knows a user's password to guess the one-time code without limit and take over the account. |
| OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Versions prior to 1.0.2 don't throttle failed passphrase login attempts. An attacker can submit unlimited wrong passphrase guesses against any known email address, capped only by the Argon2 verification cost (about 100 milliseconds per attempt on the tested host, giving 10 attempts per second sustained). The same backend implements a working per-account throttle on the WebAuthn challenge endpoint, which returns HTTP 429 after roughly 19 attempts. The passphrase branch simply does not invoke that throttle, leaving a supported high-value login path unprotected against credential stuffing and dictionary attacks. The asymmetry confirms this is an oversight rather than a design choice. The throttle infrastructure exists, is wired into the same auth backend, and works on the WebAuthn path. The passphrase branch in `/api/auth/login` was not updated to record failed attempts. Combined with the application's minimum-passphrase policy (12 characters, no entropy or dictionary checks), accounts using common base patterns such as `Spring2026!XX` or words from a leak corpus are realistically reachable in days on a single CPU, hours on a small GPU farm. Version 1.0.2 patches the issue. |
| Typemill's login endpoint (POST /tm/login, ControllerWebAuth::login()) performs no rate-limiting, failed-attempt counting, or account lockout when captcha is disabled, which is the default configuration. An unauthenticated attacker can send unlimited password-guessing requests against any account, including administrators, with no throttling. The only attempt-counting/lockout logic present in the same file protects an optional secondary email-authcode step and does not apply to the primary password check. |
| changedetection.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. |
| PaperCut NG/MF does not properly restrict excessive authentication attempts within its login component. An unauthenticated remote attacker can exploit this vulnerability to perform unrestricted brute-force or credential-stuffing attacks without triggering account lockout or rate-limiting mechanisms in some configurations. |
| A race condition in the account lockout mechanism in Delphix Continous Data allowed the lockout threshold to be bypassed through concurrent authentication requests. Parallel login attempts were processed before the failed-login counter and lockout status were updated, defeating brute-force protections and enabling continued password guessing against a targeted account. |
| @fastify/rate-limit before 11.2.0 keys rate-limit buckets by the verbatim client IP string returned from request.ip. Because a single IPv6 client can control a large address range (a /64 holds 2^64 distinct addresses) and the same address has multiple valid textual representations, an IPv6 capable client can defeat the rate-limit boundary by rotating addresses or by rewriting the same address in different forms. Applications that use @fastify/rate-limit to protect endpoints such as authentication, password reset, OTP delivery, or expensive API calls can be bypassed by IPv6 clients behind a proxy that surfaces IPv6 to the origin when trustProxy is enabled. The issue is fixed in @fastify/rate-limit 11.2.0, where the default key generator normalizes IPv6 addresses to their canonical form, collapses IPv4 mapped IPv6 to IPv4, and applies a configurable prefix mask (default /64) via a new ipv6Subnet option. |
| InvoicePlane 1.5.11 doesn't have any rate-limiting for password reset and the reset token is generated using a weak mechanism that is predictable. |
| MikroTik RouterOS contains a weakness in its API authentication handling that lacks effective safeguards against excessive login attempts. The system does not enforce meaningful rate-limiting, account lockout, or source-based restrictions, allowing repeated authentication failures to proceed without defensive response. In some versions, a fixed per-connection delay is present, but it can be bypassed through concurrent sessions, resulting in continued high-volume attempts. This deficiency increases the risk that an attacker could eventually obtain valid credentials and gain unauthorized access to administrative services. |
| Successful exploitation of this vulnerability
could allow an attacker with local network access to bypass the application's
rate-limiting mechanism, enabling brute-forcing of the screen-sharing code and
potentially displaying harmful content on the affected screen. |
| Improper restriction of excessive authentication attempts vulnerability in Universal Software Inc. FlexCity allows Excessive Allocation.
This issue affects FlexCity: from 5.536.0 before 5.542.0. |
| This vulnerability exists in CP PLUS EZ-P21 IP Camera due to improper authentication of HTTP endpoints. A remote attacker could exploit this vulnerability by conducting brute-force attacks against HTTP endpoint on the targeted device.
Successful exploitation of this vulnerability could allow an attacker to gain unauthorized access to live video snapshots from the targeted device. |
| dataCycle is a data management system for centrally storing, managing, searching, finding, and distributing data. In dataCycle-CORE, the module handling core processing and framework rules, before and including version 25.07.3, the application accepts unlimited password guesses against both the browser login flow and the JSON login endpoint. The source code enables Devise's `:lockable` module on the user model but explicitly disables both lock and unlock strategies, and no request throttling or rate-limiting layer was identified in the Rails code. This creates a direct online password-guessing risk:
- valid user accounts can be attacked continuously without temporary lockout
- the same weakness is reachable through both `/users/sign_in` and `/api/v4/auth/login`
- successful guessing yields a normal session cookie in the HTML flow or a fresh JWT in the API flow
- the API endpoint is especially attractive for automation because it requires no CSRF token
This has been patched in version 26.06.08. |
| Yamcs is a mission control framework. Prior to 5.12.7, the authentication endpoint POST /auth/token in yamcs-core, handled by yamcs-core/src/main/java/org/yamcs/http/auth/AuthHandler.java, lacked any rate limiting, account lockout, or failed-attempt throttling, so an unauthenticated remote attacker could perform unlimited password-guessing attempts against any user account, significantly increasing the risk of successful brute-force attacks. This issue is fixed in versions 5.12.7 and 5.13.0. |
| OpenClaw 2026.2.25 before 2026.5.26 allow a lower-trust caller or configured input path to bypass non-browser rate limits on WebSocket authentication attempts. When the affected feature is enabled and reachable by lower-trust input, this can consume gateway resources and reduce service availability. |
| 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. |
| Previously, there was no throttling on repeated authentication attempts
to the charging station backend, which could allow an attacker to
execute a denial-of-service attack. |
| vulnerability in Drupal Brute force attack protection allows . This issue affects Brute force attack protection versions: *.*. |
| Improper Restriction of Excessive Authentication Attempts vulnerability in Drupal Login Disable allows Brute Force. This issue affects Login Disable versions: from 0.0.0 to 2.1.4. |
