GHSA-FGMM-W5CX-VRFW
Vulnerability from github – Published: 2026-05-26 19:30 – Updated: 2026-05-26 19:30Summary
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.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "pterodactyl/panel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35202"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-26T19:30:02Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nThe 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\u0027t actually lock anything.\n\n### Details\n\nInside `DatabaseController.php`, the code tries to prevent multiple databases from being created at once by calling `$server-\u003edatabases()-\u003elockForUpdate()`. In Laravel, this just configures a query builder but never actually sends a command to the database because it\u2019s missing a terminal method like `count()` or `get()`. It\u2019s basically a no-op that does nothing.\n\nSince there\u2019s 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.\n\n### Impact\n\nUsers are able to create more databases than they are supposed to, potentially also breaking the web interface.",
"id": "GHSA-fgmm-w5cx-vrfw",
"modified": "2026-05-26T19:30:02Z",
"published": "2026-05-26T19:30:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pterodactyl/panel/security/advisories/GHSA-fgmm-w5cx-vrfw"
},
{
"type": "PACKAGE",
"url": "https://github.com/pterodactyl/panel"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Pterodactyl has a database resource limit bypass via race condition in Client API"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.