2.3

CVSS Score

4.0

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-35202

CVE-2026-35202: Pterodactyl has a database resource limit bypass via race condition in Client API

Summary

The Pterodactyl Client API has a logic flaw that lets users bypass their assigned limits for database allocations. This happens because the database locking mechanism used in the controllers is totally broken and doesn't actually lock anything.

Details

Inside DatabaseController.php, the code tries to prevent multiple databases from being created at once by calling $server->databases()->lockForUpdate(). In Laravel, this just configures a query builder but never actually sends a command to the database because it’s missing a terminal method like count() or get(). It’s basically a no-op that does nothing.

Since there’s no real lock, multiple requests hitting the endpoint at the exact same time will all see that the database count is under the limit. They all move forward to the DeployServerDatabaseService and successfully create extra resources on the physical host.

Impact

Users are able to create more databases than they are supposed to, potentially also breaking the web interface.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-35202

CVE-2026-35202:

2.3

CVSS Score

4.0

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
pterodactyl/panel	composer	< 1.12.3	1.12.3

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability lies in a common mistake when using Laravel's pessimistic locking. The lockForUpdate() method on a query builder only sets up the lock; it doesn't execute it. A terminal method like get(), first(), or count() is required to actually send the SELECT ... FOR UPDATE query to the database. The vulnerable code was missing this terminal method, so no lock was ever acquired.

This allowed for a classic Time-of-check Time-of-use (TOCTOU) race condition. Multiple concurrent API requests to create a database would all check the current database count, see that it's below the limit, and then proceed to create a new database. By the time all requests are finished, the user has more databases than their limit allows.

The patch fixes this by adding .count() to the query builder chain after lockForUpdate(). This forces the query to execute, acquiring a lock on the rows and correctly checking the count within the lock, thus preventing the race condition. The same pattern of vulnerability and fix was identified in both the DatabaseController for creating databases and the BackupController for creating backups. A similar locking issue was also addressed in the rotatePassword flow.

Vulnerable functions

App\Http\Controllers\Api\Client\Servers\DatabaseController::store

app/Http/Controllers/Api/Client/Servers/DatabaseController.php

The `store` function in `DatabaseController.php` attempts to lock the server's databases for updating before creating a new one. However, the call to `lockForUpdate()` was missing a terminal method like `count()` or `get()`, rendering it a no-op. This allows concurrent requests to bypass the database limit check, resulting in a race condition that allows the creation of more databases than permitted.

App\Http\Controllers\Api\Client\Servers\BackupController::store

app/Http/Controllers/Api/Client/Servers/BackupController.php

Similar to the `DatabaseController`, the `store` function in `BackupController.php` had a flawed locking mechanism. The `lockForUpdate()` call was ineffective, creating a race condition that could allow users to exceed their backup limits by making concurrent requests.

App\Http\Controllers\Api\Client\Servers\DatabaseController::rotatePassword

app/Http/Controllers/Api/Client/Servers/DatabaseController.php

The `rotatePassword` function, in conjunction with `DatabasePasswordService`, had a potential race condition when updating a database password. The original implementation did not correctly lock the database record during the update, which could lead to unpredictable behavior under concurrent requests. The patch corrects this by using a `sharedLock` during the update transaction.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.