### 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.
Update pterodactyl/panel to 1.12.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanPterodactyl has a database resource limit bypass via race condition in Client API affects pterodactyl/panel (composer). Severity is low. ### 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.
AI coding agents often install or upgrade packages automatically in composer. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
### 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.
Update pterodactyl/panel to 1.12.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanPterodactyl has a database resource limit bypass via race condition in Client API affects pterodactyl/panel (composer). Severity is low. ### 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.
AI coding agents often install or upgrade packages automatically in composer. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|
| pterodactyl/panelcomposer | <1.12.3 | 1.12.3 |
|---|
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard| Package | Affected range | Fixed version |
|---|
| pterodactyl/panelcomposer | <1.12.3 | 1.12.3 |
|---|
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard