CVE-2026-105130: LaraDashboard Race Condition Vulnerability

CVE-2026-105130 Overview

CVE-2026-105130 is a race condition vulnerability in LaraDashboard versions 1.4.0 before 1.4.8. The flaw resides in RegisterController::register, which performs a non-atomic check against RegistrationGuardService::hasExceededIpLimit before calling recordRegistration. Unauthenticated attackers can issue many concurrent registration requests from a single IP address. All requests pass the limit check before any one of them records a registration, allowing bulk account creation and defeating the per-IP daily registration cap. The vulnerability is classified as a Time-of-Check Time-of-Use (TOCTOU) issue under [CWE-367].

Critical Impact
Unauthenticated remote attackers can bypass anti-automation controls to mass-create user accounts from a single source IP, undermining registration throttling and enabling abuse at scale.

Affected Products

LaraDashboard 1.4.0 through 1.4.7
LaraDashboard installations exposing the registration endpoint to untrusted networks
Fixed in LaraDashboard 1.4.8

Discovery Timeline

2026-10-04 - CVE-2026-105130 published to the National Vulnerability Database (NVD)
2026-10-05 - Last updated in NVD database

Technical Details for CVE-2026-105130

Vulnerability Analysis

The vulnerability stems from a classic TOCTOU pattern in the registration workflow. The controller first calls hasExceededIpLimit($request->ip()) to check whether the source IP has reached its daily registration cap. Only after validation and user creation does it call recordRegistration($request->ip()) to increment the counter. The gap between check and update is not guarded by any lock or atomic operation. Concurrent HTTP requests from the same IP can therefore all observe a counter value below the threshold and all proceed to create accounts.

The counter itself is backed by a Laravel Cache store. The pre-patch recordRegistration logic used a non-atomic Cache::has followed by Cache::put and Cache::increment, compounding the race window at the cache layer in addition to the controller layer.

Root Cause

The root cause is the absence of mutual exclusion between the limit check and the counter update. See the vulnerable sequence in RegisterController.php and RegistrationGuardService.php. Because registration is unauthenticated and the check-then-act logic is not serialized, parallel requests can all pass the gate before any of them updates shared state.

Attack Vector

An attacker scripts a burst of parallel HTTP POST requests to the registration endpoint, each supplying a unique email and password. All requests originate from the same IP within the race window. Because hasExceededIpLimit reads the counter before recordRegistration writes it, every parallel request sees a value under the daily cap and successfully creates an account. The attack requires no credentials and no user interaction.

php

// Patched RegisterController::register — atomic reservation before user creation
public function register(Request $request): RedirectResponse|JsonResponse
{
    $this->validator($request->all())->validate();

    if (! $this->registrationGuard->reserveIpRegistrationSlot($request->ip())) {
        return back()
            ->withErrors([
                'email' => __('Too many registration attempts from your network. Please try again later.'),
            ])
            ->withInput($request->except('password', 'password_confirmation'));
    }

    try {
        $user = $this->create($request->all());

        if ($this->shouldSendWelcomeEmail()) {
            $this->sendWelcomeEmail($user);
        }

Source: GitHub commit 1bc7b7e

The fix replaces the separate check-then-record pattern with a single atomic reserveIpRegistrationSlot call that uses Cache::lock to serialize concurrent requests.

Detection Methods for CVE-2026-105130

Indicators of Compromise

Multiple user accounts created from the same source IP within a short time window, especially within milliseconds of each other
Spikes of concurrent POST /register requests sharing an IP, user-agent, or TLS fingerprint
New accounts whose email addresses follow algorithmic patterns such as sequential suffixes or disposable-mail domains

Detection Strategies

Correlate web server access logs with the application users table to flag registration bursts that exceed the configured per-IP daily limit
Alert on short-interval concurrent requests to the registration endpoint from a single IP where the count exceeds the policy threshold
Review Laravel application logs for repeated calls to RegistrationGuardService paths followed by successful user creation events

Monitoring Recommendations

Instrument the registration endpoint with request counters tagged by source IP and timestamp at sub-second resolution
Forward web and application logs to a centralized analytics platform and build detections for registration velocity anomalies
Monitor downstream signals such as welcome-email volume and newly created account activity for sudden spikes

How to Mitigate CVE-2026-105130

Immediate Actions Required

Upgrade LaraDashboard to version 1.4.8 or later, which introduces atomic slot reservation using Cache::lock
Audit accounts created since deploying any version in the 1.4.0 to 1.4.7 range and disable those linked to abusive registration bursts
Place the registration endpoint behind a web application firewall or rate limiter that enforces concurrency caps per source IP

Patch Information

The fix is delivered in LaraDashboard v1.4.8 via pull request #343 and commit 1bc7b7e. The patch introduces reserveIpRegistrationSlot, which uses Cache::lock($key.':lock', 10)->block(5, ...) to serialize the check-and-increment operation. Validation is also moved before the limit check so malformed requests cannot consume slots. Full details are in the GitHub Security Advisory GHSA-gw6g-9wx9-3fpj and the VulnCheck advisory.

Workarounds

Disable public self-registration until the patched version is deployed, if the feature is non-essential
Add an upstream rate limit at the reverse proxy or WAF that caps concurrent requests to /register per source IP
Require CAPTCHA or proof-of-work on the registration form to raise the cost of parallel request bursts

bash

# Example nginx limit for concurrent registration requests per IP
http {
    limit_req_zone $binary_remote_addr zone=register_zone:10m rate=5r/m;
    limit_conn_zone $binary_remote_addr zone=register_conn:10m;

    server {
        location = /register {
            limit_req zone=register_zone burst=2 nodelay;
            limit_conn register_conn 1;
            proxy_pass http://laradashboard_backend;
        }
    }
}