CVE-2026-61609 in panel
Summary
by MITRE • 07/28/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/28/2026
The vulnerability in Pterodactyl versions 1.7.0 through 1.13.0 represents a critical design flaw in the authentication rate limiting mechanism that fundamentally undermines the security and availability of the game server management panel. This issue stems from improper implementation of Laravel's rate limiting capabilities within the RouteServiceProvider::configureRateLimiting() method, where a single global rate limiting bucket was applied across multiple authentication endpoints instead of properly segmenting limits by IP address or account identifier. The technical flaw manifests specifically through the omission of the ->by() method in the Limit::perMinute(10) configuration that governs both POST /auth/login and POST /auth/login/checkpoint endpoints, resulting in Laravel generating a constant cache key of md5('authentication') for all authentication requests regardless of their source or target.
The operational impact of this vulnerability creates a severe denial of service condition that affects the entire panel infrastructure rather than individual users or accounts. An unauthenticated attacker capable of sending approximately ten requests per minute from a single IP address can systematically exhaust the shared rate limiting counter, thereby blocking legitimate users from accessing authentication endpoints for both login and two-factor checkpoint processes. This attack vector is particularly dangerous because it targets the checkpoint endpoint which lacks additional security measures like reCAPTCHA protection, making it easier for attackers to exploit without additional hurdles. The consequences extend beyond simple user inconvenience to full administrative lockout scenarios where even authorized administrators become unable to authenticate, effectively neutralizing the entire authentication system and potentially compromising the panel's operational integrity.
The vulnerability aligns with CWE-305 Authentication Bypass Through Multiple Failures, where improper handling of authentication attempts creates pathways for denial of service attacks that can be executed with minimal resources. From an adversarial perspective, this flaw corresponds to techniques found in the MITRE ATT&CK framework under T1499 - Endpoint Denial of Service and T1110 - Brute Force, specifically targeting authentication systems through resource exhaustion rather than direct credential guessing. The implementation error demonstrates a fundamental misunderstanding of how rate limiting should function in multi-user environments where individual access patterns need to be tracked separately to prevent legitimate users from being impacted by malicious activity. This type of vulnerability highlights the importance of proper security architecture design and the critical nature of authentication system resilience against abuse, particularly in open-source platforms where widespread deployment increases potential attack surface exposure.
The fix implemented in version 1.13.0 addresses this issue by ensuring that rate limiting is properly segmented by either IP address or account identifier through appropriate use of the ->by() method in Laravel's rate limiting configuration. This change ensures that each unique client or user maintains their own rate limiting counter rather than sharing a single global bucket, thereby preventing malicious actors from affecting legitimate users while maintaining effective protection against automated attack vectors. The remediation approach aligns with security best practices for implementing rate limiting mechanisms that preserve system availability for legitimate users while still providing adequate protection against abuse. Organizations should also consider implementing additional authentication security measures such as account lockout policies, CAPTCHA verification for failed attempts, and monitoring for suspicious authentication patterns to further strengthen their defenses beyond basic rate limiting implementations.