LaraDashboard EUVD-2026-92052

Requires that LaraDashboard (versions 1.4.0 through before 1.4.8) has public self-registration enabled and the per-IP daily registration limit feature active (getMaxRegistrationsPerIpPerDay greater than 0); if the cap is disabled or set to 0 there is nothing to bypass. Exploitation further requires the attacker to send many registration requests concurrently from one IP so they all clear RegistrationGuardService::hasExceededIpLimit before any recordRegistration call commits - i.e., winning the TOCTOU window. Limiting factors: high attack complexity and the need to reliably race the check (CVSS AC:H/AT:P), and the impact is confined to creating excess accounts (anti-automation/anti-spam bypass) with no confidentiality or availability effect.

This is a genuine but low-to-moderate priority issue, not a critical one. The vendor CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N) scores 6.3 (Medium), and the metrics are internally consistent with a TOCTOU race (CWE-367): network-reachable and unauthenticated (PR:N) but gated by high attack complexity (AC:H) and a present attack requirement (AT:P) because the attacker must win a narrow timing window by flooding concurrent requests. Impact is deliberately narrow - VI:L only, with VC:N/VA:N - reflecting that the flaw bypasses an anti-automation control (per-IP daily registration cap) rather than granting code execution, data access, or privilege escalation. No EPSS score, KEV listing, or public exploit was provided in the input, so there is no signal of active or widespread exploitation; the only exploitation evidence is the patch diff and advisory describing the technique. Net: a real abuse/anti-spam weakness worth patching on a normal cycle, but the raw 6.3 overstates practical urgency given the race-condition complexity and purely integrity-limited impact. Note the input tag 'Authentication Bypass' is misleading - this bypasses a registration rate-limit, not authentication.

An attacker targeting a LaraDashboard instance with open self-registration scripts a burst of many simultaneous POST requests to the registration endpoint from a single IP. Because each request checks hasExceededIpLimit before any of them calls recordRegistration, all concurrent requests pass the check and create accounts, overrunning the per-IP daily cap. No public exploit was identified in the provided data, though the vendor advisory and patch diff fully describe the concurrency technique.