GHSA-j7f5-gfqm-pcx3: Pterodactyl panel: email endpoint leaks user enumeration

GHSA-j7f5-gfqm-pcx3 MEDIUM
Published June 26, 2026
CISO Take

An authenticated user can abuse the account email-update endpoint in the Pterodactyl game/server management panel to confirm whether any given email address has a registered account, because that endpoint has no rate limiting or CAPTCHA (unlike login and password-reset, which are protected). This is not an AI/ML-specific vulnerability — Pterodactyl is a general server-hosting control panel, not an AI framework, model server, or ML tool — so its relevance to an AI threat intelligence program is limited to the subset of organizations that happen to run Pterodactyl to manage self-hosted infrastructure (including, in some cases, self-hosted LLM inference boxes). There is no EPSS score, no CISA KEV listing, no public PoC exploit, and no Nuclei template, indicating this is a low-severity, non-actively-exploited enumeration flaw rather than a critical or novel attack vector. The fix is straightforward: upgrade to Pterodactyl panel 1.12.3 or later, which patches the endpoint; in the interim, monitor for abnormal request volume against the account-settings email-change endpoint and consider adding application-layer rate limiting via a reverse proxy (e.g., Caddy/Nginx) as a compensating control.

Sources: NVD GitHub Advisory

What is the risk?

Low severity and low urgency. The flaw requires an authenticated session (any valid, even free-tier, account qualifies), has no confirmed exploitation in the wild, no EPSS/CVSS scoring, and no public exploit or scanner template. Impact is limited to user enumeration (CWE-204), which enables downstream phishing/targeting rather than direct compromise of data, models, or infrastructure. Package risk score (26/100) and lack of KEV/SSVC flags support treating this as routine patch-cycle work, not an emergency.

How does the attack unfold?

Authenticated Access
Attacker obtains any valid Pterodactyl account, including a free/trial-tier registration.
AML.T0012
Endpoint Abuse
Attacker intercepts the account email-update POST request via a proxy and replays it with varying candidate email addresses.
Enumeration
Unprotected response discrepancy confirms which emails correspond to registered accounts, with no rate limiting to stop mass requests.
AML.T0087
Downstream Targeting
Harvested email list is used to launch phishing or credential-stuffing attacks against panel operators, including administrators.
AML.T0052

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Panel composer < 1.12.3 1.12.3
5.7K OpenSSF 6.9 499 dependents Pushed 3d ago 63% patched ~16d to patch Full package profile →

Do you use Panel? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

1 step
  1. Upgrade Pterodactyl panel to version 1.12.3 or later, which addresses the missing rate limiting/CAPTCHA on the account email-update endpoint. Until upgraded, add rate limiting at the reverse proxy or WAF layer for POST requests to the account settings/email-update route, and alert on high-frequency requests to that endpoint from a single authenticated session. Review panel logs for prior bursts of email-change attempts as an indicator of past enumeration activity. Enforce MFA on all panel accounts (especially admin) to reduce the value of enumerated emails for follow-on phishing or credential-stuffing attacks.

How is it classified?

Privacy Violation Auth Bypass

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is GHSA-j7f5-gfqm-pcx3?

An authenticated user can abuse the account email-update endpoint in the Pterodactyl game/server management panel to confirm whether any given email address has a registered account, because that endpoint has no rate limiting or CAPTCHA (unlike login and password-reset, which are protected). This is not an AI/ML-specific vulnerability — Pterodactyl is a general server-hosting control panel, not an AI framework, model server, or ML tool — so its relevance to an AI threat intelligence program is limited to the subset of organizations that happen to run Pterodactyl to manage self-hosted infrastructure (including, in some cases, self-hosted LLM inference boxes). There is no EPSS score, no CISA KEV listing, no public PoC exploit, and no Nuclei template, indicating this is a low-severity, non-actively-exploited enumeration flaw rather than a critical or novel attack vector. The fix is straightforward: upgrade to Pterodactyl panel 1.12.3 or later, which patches the endpoint; in the interim, monitor for abnormal request volume against the account-settings email-change endpoint and consider adding application-layer rate limiting via a reverse proxy (e.g., Caddy/Nginx) as a compensating control.

Is GHSA-j7f5-gfqm-pcx3 actively exploited?

No confirmed active exploitation of GHSA-j7f5-gfqm-pcx3 has been reported, but organizations should still patch proactively.

How to fix GHSA-j7f5-gfqm-pcx3?

Upgrade Pterodactyl panel to version 1.12.3 or later, which addresses the missing rate limiting/CAPTCHA on the account email-update endpoint. Until upgraded, add rate limiting at the reverse proxy or WAF layer for POST requests to the account settings/email-update route, and alert on high-frequency requests to that endpoint from a single authenticated session. Review panel logs for prior bursts of email-change attempts as an indicator of past enumeration activity. Enforce MFA on all panel accounts (especially admin) to reduce the value of enumerated emails for follow-on phishing or credential-stuffing attacks.

What is the CVSS score for GHSA-j7f5-gfqm-pcx3?

No CVSS score has been assigned yet.

What are the technical details?

Original Advisory

### Summary An unprotected user enumeration vulnerability exists in the account email update endpoint, allowing authenticated users to verify whether email addresses are registered on the panel through automated requests without rate limiting or CAPTCHA protection. ### Details The account settings page allows authenticated users to update their email address through a POST request. Unlike the login and password reset forms which implement reCAPTCHA and rate limiting protections, this endpoint lacks these safeguards entirely. An attacker can capture the email update request (for example, using Burp Suite's proxy) and modify the email field to test arbitrary addresses. The panel's response will confirm whether each tested email is already registered in the system. Because there are no rate limits implemented, attackers can send hundreds or thousands of requests to enumerate the user base. This is concerning because: - The login and password reset pages correctly implement protections against enumeration - The account page has no reCAPTCHA option available - No rate limiting exists in the panel for this endpoint - Authentication is required, but any valid account (including free tier/trial accounts) can exploit this ### PoC - Log into the Pterodactyl panel with any valid account - Navigate to Account Settings - Open Burp Suite (or similar proxy tool) and configure your browser to proxy through it - Attempt to change your email address and capture the POST request - Send the captured request to Repeater - Modify the email field to test different addresses (e.g., admin@example.com, test@example.com) - Send multiple requests in rapid succession - Observe the response messages which confirm whether each email exists or not - Repeat indefinitely without encountering rate limits or CAPTCHA challenges ### Impact This is a user enumeration vulnerability (CWE-204: Observable Response Discrepancy). Who is impacted: - All Pterodactyl panel installations are affected - Any registered user's email address can be discovered - Particularly impacts administrators and high-value accounts Potential consequences: - Attackers can build a complete database of registered users - Enumerated emails can be used for targeted phishing campaigns - Combined with other attacks (credential stuffing, social engineering) - Privacy violation for all users on the platform - Competitive intelligence gathering (identifying which companies/individuals use specific panels)

Exploitation Scenario

An attacker registers or obtains a free-tier account on a Pterodactyl-based hosting panel, then uses a proxy tool (e.g., Burp Suite) to capture the POST request used to change the account email address. By replaying this request thousands of times with different candidate email addresses and observing the panel's response (which differs when an email is already registered), the attacker builds a list of valid accounts on the panel, including likely administrator or operator emails. That list is then used to launch targeted phishing or credential-stuffing campaigns against the panel's operators, who may be the administrators of AI-adjacent self-hosted infrastructure.

Weaknesses (CWE)

CWE-204 — Observable Response Discrepancy: The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.

  • [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
  • [Implementation] Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

Source: MITRE CWE corpus.

Timeline

Published
June 26, 2026
Last Modified
June 26, 2026
First Seen
June 27, 2026

Related Vulnerabilities