Global authentication rate limiter enables login denial of service in Pterodactyl Panel

Pterodactyl is a free, open-source game server management panel. From 1.7.0 until 1.13.0, the authentication rate limiter defined in RouteServiceProvider::configureRateLimiting() applied a single global bucket to the login and two-factor checkpoint endpoints instead of keying by IP or account: the fall-through Limit::perMinute(10) covering POST /auth/login and POST /auth/login/checkpoint omitted ->by(), so Laravel derived a constant cache key (md5('authentication')) shared by every request. An unauthenticated attacker sending roughly ten requests per minute from a single IP, most cheaply against the checkpoint endpoint (which has no reCAPTCHA), exhausts the shared counter and causes HTTP 429 for every user attempting to log in or complete two-factor authentication, a panel-wide authentication denial of service that also locks out administrators. This issue is fixed in version 1.13.0.

• pterodactyl/panel: the CNA advisory identifies versions >= 1.7.0, <= 1.12.4 as affected.
• The normalized CVE record represents the affected range as >= 1.7.0, < 1.13.0.
• Patched version: 1.13.0.
• The advisory identifies the forgot-password endpoint as unaffected because its limiter is keyed by IP. No separate evidence establishes the status of other parallel release branches.

The flaw is in the authentication limiter configured by RouteServiceProvider::configureRateLimiting(). The branch covering POST /auth/login and POST /auth/login/checkpoint calls Limit::perMinute(10) without ->by(), so Laravel derives a constant cache key from the authentication limiter name instead of keying requests by IP or account. Requests from every client therefore increment the same counter; after the limit is reached, the throttle middleware returns HTTP 429 for subsequent authentication requests during the rate-limit window. POST /auth/login/checkpoint has no reCAPTCHA and is therefore the easiest endpoint through which to fill the shared counter; on POST /auth/login, throttling is applied before the reCAPTCHA middleware. The forgot-password branch uses ->by($request->ip()) and is identified by the advisory as unaffected. The available evidence does not describe additional cache behavior beyond the shared-key construction.

The vulnerability is reachable over the network without authentication, privileges, or user interaction. A single IP can send roughly ten requests per minute to the checkpoint endpoint to exhaust the shared bucket; the public advisory documents a proof of concept for this behavior. Once the bucket is exhausted, valid users from other IP addresses can also receive HTTP 429 when logging in or completing two-factor authentication. Repeating traffic in each rate-limit window can maintain the authentication lockout. The available evidence confirms a public proof of concept, but does not establish exploitation in the wild.

The flaw allows an unauthenticated client to affect authentication for other clients because all requests contend for one shared cache counter. The technical result is HTTP 429 responses on the login and checkpoint endpoints, creating panel-wide authentication denial of service rather than limiting the effect to one IP or account. Administrators and ordinary users can both be affected, while the forgot-password endpoint remains IP-keyed. The available evidence does not indicate privilege escalation, unauthorized data access, or an integrity impact to the panel.

• Valid users may be unable to log in or complete two-factor authentication while the attack is sustained.
• Administrators can be locked out of the panel, delaying incident response and service recovery.
• The game server management panel may continue running, but its administrative and login channel can become unavailable to users who need access.
• The issue is not described as enabling data access or configuration changes; the confirmed consequence is denial of service against authentication.

1. Upgrade pterodactyl/panel to 1.13.0, the patched version identified by the CNA advisory.
2. If an upgrade cannot be completed immediately, apply the confirmed source change in app/Providers/RouteServiceProvider.php: change the fall-through limiter to return Limit::perMinute(10)->by($request->ip());. This is a temporary source-level measure based on the fixing commit and should be tested through the organization’s deployment process.
3. After updating, test both POST /auth/login and POST /auth/login/checkpoint from separate clients to confirm that requests no longer consume one global bucket. A design that combines the IP with an account identifier or checkpoint token may warrant separate review to preserve brute-force protection, but the advisory does not confirm a specific design beyond removing the global bucket.

1. Inventory Pterodactyl Panel deployments and identify panels reachable from untrusted networks.
2. Check the installed pterodactyl/panel version in each environment.
3. Inspect app/Providers/RouteServiceProvider.php and verify that the fall-through authentication limiter keys requests by IP with ->by($request->ip()), rather than only calling Limit::perMinute(10).
4. Review telemetry for POST /auth/login and POST /auth/login/checkpoint for unusual HTTP 429 responses, especially when they occur simultaneously for multiple accounts or source IPs.
5. A synchronized throttling pattern across otherwise unrelated clients is a precautionary signal to investigate, not a vendor-confirmed IOC. The absence of matching log evidence does not prove that a deployment is safe.