CVE-2025-69198: Pterodactyl Panel DOS Vulnerability

CVE-2025-69198 Overview

Pterodactyl, a popular open-source game server management panel, contains a race condition vulnerability in its resource limit validation mechanism. The vulnerability exists because resource limits for servers (databases, port allocations, and backups) are validated early in the request cycle without implementing proper locking mechanisms. This allows attackers to bypass configured resource limits by sending concurrent requests, potentially leading to resource exhaustion and denial of service conditions affecting other users on the platform.

Critical Impact

Malicious users can bypass server resource limits to create more databases, allocations, or backups than permitted, potentially exhausting node allocations and backup storage space while denying resources to other legitimate users.

Affected Products

• Pterodactyl Panel versions prior to 1.12.0

Discovery Timeline

• 2026-01-19 - CVE CVE-2025-69198 published to NVD
• 2026-01-19 - Last updated in NVD database

Technical Details for CVE-2025-69198

Vulnerability Analysis

The vulnerability stems from improper resource validation handling in Pterodactyl Panel's server resource management. When a user attempts to create resources such as databases, port allocations, or backups, the system validates whether the server has reached its configured limits. However, this validation occurs without acquiring a lock on the target resource during the entire request lifecycle.

This creates a classic Time-of-Check Time-of-Use (TOCTOU) race condition. When multiple concurrent requests arrive simultaneously, each request individually validates against the current resource count before any of them complete their creation operations. Since none of the in-flight requests have yet committed their changes, all concurrent requests pass validation and proceed to create resources, resulting in the server exceeding its configured limits.

Root Cause

The root cause is the absence of proper resource locking during the validation and creation workflow. The original implementation performed resource count validation early in the request cycle but did not implement database-level locking or transaction isolation to prevent concurrent requests from racing past the validation check. This falls under CWE-400 (Uncontrolled Resource Consumption) as it allows attackers to consume resources beyond their allocated quotas.

Attack Vector

An attacker with authenticated access to a Pterodactyl server can exploit this vulnerability by sending a high volume of concurrent HTTP requests to create resources. The attack vector is network-based and requires low-privilege authentication. The attacker must have permission to create the target resource type (databases, allocations, or backups) on their assigned server. By timing a burst of simultaneous requests, the attacker can bypass per-server resource limits and potentially:

1. Exhaust node-level port allocations, preventing other servers from obtaining new ports
2. Fill backup storage beyond configured quotas
3. Create excessive database instances, consuming shared database server resources

The fix implemented in version 1.12.0 introduces a ResourceLimit enum class that implements proper throttling and resource locking:

+<?php
+
+namespace Pterodactyl\Enum;
+
+use Illuminate\Http\Request;
+use Webmozart\Assert\Assert;
+use Pterodactyl\Models\Server;
+use Illuminate\Cache\RateLimiting\Limit;
+use Illuminate\Support\Facades\RateLimiter;
+use Illuminate\Routing\Middleware\ThrottleRequests;
+
+/**
+ * A basic resource throttler for individual servers. This is applied in addition
+ * to existing rate limits and allows the code to slow down speedy users that might
+ * be creating resources a little too quickly for comfort. This throttle generally
+ * only applies to creation flows, and not general view/edit/delete flows.
+ */
+enum ResourceLimit
+{
+    case Allocation;
+    case Backup;
+    case Database;
+    case Schedule;
+    case Subuser;
+    case Websocket;
+    case FilePull;
+
+    public function throttleKey(): string
+    {
+        return mb_strtolower("api.client:server-resource:{$this->name}");

Source: GitHub Commit Changes

The backup controller was also patched to implement proper database locking during backup creation:

         // how best to allow a user to create a backup that is locked without also preventing
         // them from just filling up a server with backups that can never be deleted?
         if ($request->user()->can(Permission::ACTION_BACKUP_DELETE, $server)) {
-            $action->setIsLocked((bool) $request->input('is_locked'));
+            $action->setIsLocked($request->boolean('is_locked'));
         }
 
-        $backup = $action->handle($server, $request->input('name'));
+        $backup = Activity::event('server:backup.start')->transaction(function ($log) use ($action, $server, $request) {
+            $server->backups()->lockForUpdate();
 
-        Activity::event('server:backup.start')
-            ->subject($backup)
-            ->property(['name' => $backup->name, 'locked' => (bool) $request->input('is_locked')])
-            ->log();
+            $backup = $action->handle($server, $request->input('name'));
+
+            $log->subject($backup)->property([
+                'name' => $backup->name,
+                'locked' => $request->boolean('is_locked'),
+            ]);
+
+            return $backup;
+        });
 
         return $this->fractal->item($backup)
             ->transformWith($this->getTransformer(BackupTransformer::class))

Source: GitHub Commit Changes

Detection Methods for CVE-2025-69198

Indicators of Compromise

• Servers with resource counts (databases, allocations, backups) exceeding their configured limits
• Unusual bursts of API requests to resource creation endpoints from single user sessions
• Database or backup storage consumption exceeding expected thresholds for individual servers
• Logs showing multiple simultaneous resource creation requests within milliseconds

Detection Strategies

• Monitor web server access logs for rapid concurrent POST requests to /api/client/servers/*/databases, /api/client/servers/*/network/allocations, and /api/client/servers/*/backups endpoints
• Implement alerting on servers where resource counts exceed configured limits by querying the database directly
• Review application logs for patterns indicating race condition exploitation attempts
• Set up anomaly detection for API request rates per authenticated user session

Monitoring Recommendations

• Configure rate limiting at the reverse proxy or load balancer level as an additional defense layer
• Establish baseline metrics for resource creation patterns and alert on deviations
• Monitor disk usage trends on backup storage volumes for unexpected growth
• Track database server connection counts and creation rates across all Pterodactyl nodes

How to Mitigate CVE-2025-69198

Immediate Actions Required

• Upgrade Pterodactyl Panel to version 1.12.0 or later immediately
• Audit existing servers for resource count violations and remediate any that exceed configured limits
• Review access logs for evidence of exploitation attempts prior to patching
• Consider temporarily reducing resource limits while preparing the upgrade

Patch Information

The vulnerability is fixed in Pterodactyl Panel version 1.12.0. The patch introduces a new ResourceLimit enum that implements per-server resource throttling and adds proper database-level locking (lockForUpdate()) during resource creation transactions. Organizations should upgrade by following the standard Pterodactyl upgrade procedure.

For detailed patch information, see the GitHub Security Advisory GHSA-jw2v-cq5x-q68g and the associated commit.

Workarounds

• Implement external rate limiting at the web server or reverse proxy level (nginx, Apache, HAProxy) to throttle requests to resource creation API endpoints
• Restrict network access to the Pterodactyl Panel API to trusted IP ranges where feasible
• Temporarily disable self-service resource creation by adjusting user permissions until the patch can be applied
• Monitor and manually audit resource counts regularly as a compensating control

# Example nginx rate limiting configuration for Pterodactyl API endpoints
limit_req_zone $binary_remote_addr zone=pterodactyl_api:10m rate=5r/s;

location ~ ^/api/client/servers/.*/databases$ {
    limit_req zone=pterodactyl_api burst=3 nodelay;
    proxy_pass http://pterodactyl_backend;
}

location ~ ^/api/client/servers/.*/backups$ {
    limit_req zone=pterodactyl_api burst=3 nodelay;
    proxy_pass http://pterodactyl_backend;
}

location ~ ^/api/client/servers/.*/network/allocations$ {
    limit_req zone=pterodactyl_api burst=3 nodelay;
    proxy_pass http://pterodactyl_backend;
}