CVE-2026-47114: Pterodactyl Panel Admin Settings Bypass
TL;DR - Pterodactyl Panel before 1.11.11 lets certain low-privileged users change admin settings via crafted requests. - Affects accounts with specific view-only admin permissions; upgrade to 1.11.11+ and review access now. - High severity (CVSS 8.8); no confirmed in-the-wild exploitation in available sources.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-47114 |
| CVSS score | 8.8 (High) |
| Attack vector | Network |
| Auth required | Yes — low privileges required |
| Patch status | Fixed in Pterodactyl Panel 1.11.11 |
What is CVE-2026-47114?
CVE-2026-47114 is an improper access control issue (CWE-284) in Pterodactyl Panel. According to the NVD description, “In Pterodactyl Panel before 1.11.11, settings in the Admin area can be updated with crafted requests. The activity audit is not recorded, and the settings are changed. Any user account capable of viewing those settings can change them.” That is the core risk: a user who should only be able to see certain administrative settings can instead modify them.
The GitHub security advisory adds important scope. The vulnerable functionality includes node-level settings and some settings in the Nest and Egg management pages. The affected permission model is especially concerning because the advisory explicitly says users with these view-level permissions may abuse the flaw:
- Admin > Nodes > View
- Admin > Nests > View Egg
- Admin > Nests > View Nest
This is not an unauthenticated internet worm scenario. The attacker needs valid access to the panel and the relevant low-privilege permissions. But in shared hosting, gaming communities, managed environments, and multi-admin deployments, that is still a realistic threat model. The lack of activity audit logging for the unauthorized changes increases operational impact because responders may not see the change where they expect it.
Who is affected?
The affected product is Pterodactyl Panel, with the vulnerable version range stated as “before 1.11.11.” Based on the published advisory and NVD record, defenders should treat all releases earlier than 1.11.11 as affected unless they have independently verified a downstream backport from a trusted maintainer. The fixed version called out by the advisory is 1.11.11.
If you operate a packaged or containerized deployment, do not assume the package name alone tells you whether you are safe. Many organizations run Pterodactyl from Git checkouts, custom Docker images, or local forks. In those cases, confirm the actual application version and, if necessary, verify whether the fix commit referenced by the advisory has been incorporated. In the absence of reliable packaging metadata, defenders should assume exposure until they can prove the instance is running 1.11.11 or later.
| Product | Affected versions | Fixed version |
|---|---|---|
| Pterodactyl Panel | before 1.11.11 | 1.11.11 |
The most important exposure question is not just versioning, but which users hold the relevant permissions. Even if those users are considered “trusted staff,” the flaw breaks the intended authorization boundary. Any account with the listed view permissions should be treated as potentially able to make unauthorized changes on vulnerable versions.
CVSS score and practical risk
The vulnerability has a CVSS v3.1 base score of 8.8 (High) with vector:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
That score makes sense operationally. The issue is remotely reachable over the network (AV:N), requires only low privileges (PR:L), and does not require user interaction (UI:N). High impact across confidentiality, integrity, and availability reflects the fact that administrative settings often influence panel behavior, node definitions, and service handling. If an attacker can change infrastructure-related settings, they may be able to disrupt workloads, reroute operations, or weaken downstream controls.
The most important practical nuance is that this is not a generic “admin takeover” by anonymous attackers. It is an authorization bypass inside an authenticated workflow. For many organizations, that still lands high on the priority list because shared administration is common, and insider or compromised-staff scenarios are a realistic source of abuse. Also, because the activity audit may not record the change, even modest unauthorized edits can become hard-to-explain outages or misconfigurations during incident response.
Exploitation status
Based on the sources provided, there is no confirmed in-the-wild exploitation of CVE-2026-47114 at this time. It is not listed in CISA KEV, which means there is no current CISA-backed confirmation of active exploitation. That does not mean the issue is safe to defer; it only means the available public evidence does not confirm active abuse.
There is also no public proof-of-concept explicitly cited in the available source material. The GitHub advisory confirms the exploit path in enough detail to establish that the bug is real and practically exploitable via crafted HTTP requests by users with certain low-privileged admin-view permissions. In other words: exploitability is established by the vendor advisory, but a separate public PoC is not known from the supplied sources.
When public exploitation data is unknown, defenders should assume that any moderately skilled authenticated user could reproduce the issue from normal browser traffic and endpoint inspection. That is especially true for web application authorization flaws where the vulnerable requests are often straightforward mutations of legitimate UI actions.
So what? Business and operational impact
For practitioners, the immediate concern is unauthorized configuration change in management paths that should be read-only for affected users. The advisory specifically mentions node settings, nest settings, and some egg settings. In a Pterodactyl deployment, these settings can materially affect provisioning behavior, service definitions, or operational stability. Even without code execution, unauthorized configuration drift can create outages, break server templates, or expose internal details.
The second-order problem is visibility. The advisory states that activity audit is not recorded for these unauthorized changes. That means your panel’s normal audit history may underreport or completely miss the state change. If you rely heavily on the application audit trail for investigations, this flaw weakens one of your main forensic sources. In practice, defenders may need to pivot to reverse proxy logs, web server access logs, infrastructure snapshots, configuration backups, or database-level history if available.
Bottom line
CVE-2026-47114 is a high-severity authorization flaw in Pterodactyl Panel before 1.11.11 that allows users with certain view-only admin permissions to make unauthorized settings changes using crafted requests. The issue is especially important because the activity audit may not record the changes, creating a detection and response blind spot.
There is no confirmed in-the-wild exploitation in the provided sources and no known public PoC explicitly cited there, but the vendor advisory clearly establishes exploitability. For defenders, the right response is straightforward: upgrade to 1.11.11 or later immediately, review the affected permissions, and inspect HTTP-layer logs for unexpected admin-setting updates.
For further information, you can check the following resources: - What is the difference between phishing and spear phishing? - What is path traversal?
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
How to detect possible exploitation
Detection is harder than usual because the panel’s own activity audit may not record the unauthorized changes. That means defenders should focus on HTTP-layer evidence, configuration drift, and permission-to-action mismatches. A useful heuristic is to look for requests to administrative update endpoints made by accounts that only have view-level permissions for Nodes, Nests, or Eggs.
You should also review recent changes to node, nest, and egg-related settings and correlate them with known maintenance windows, ticket history, or legitimate admin actions. If settings changed but there is no corresponding panel audit event, that gap itself is suspicious in the context of this CVE. In environments without detailed request logging, assume that historical certainty may be limited and prioritize patching plus permission cleanup.
Technical Notes
Because the advisory does not publish exact endpoint paths in the supplied material, defenders should not rely on a single fixed URI. Instead, inspect logs for state-changing HTTP methods to admin routes involving nodes, nests, or eggs, especially when performed by users who should only have “view” permissions.
Example patterns to search in web or reverse-proxy logs:
POST /admin/nodes/
PUT /admin/nodes/
PATCH /admin/nodes/
POST /admin/nests/
PUT /admin/nests/
PATCH /admin/nests/
POST /admin/nests/*/eggs/
PUT /admin/nests/*/eggs/
PATCH /admin/nests/*/eggs/
Example grep against Nginx or Apache-style access logs:
grep -E '"(POST|PUT|PATCH) /admin/(nodes|nests)' /var/log/nginx/access.log
Example Splunk query:
index=web sourcetype=access_combined ("POST /admin/nodes" OR "PUT /admin/nodes" OR "PATCH /admin/nodes" OR "POST /admin/nests" OR "PUT /admin/nests" OR "PATCH /admin/nests")
| stats count by clientip, user, uri_path, method, status
Example Sigma-style detection idea for proxy logs:
title: Pterodactyl Admin Settings Update by Low-Privilege User
status: experimental
logsource:
product: webserver
detection:
selection:
cs-method|contains:
- POST
- PUT
- PATCH
cs-uri-stem|contains:
- /admin/nodes
- /admin/nests
condition: selection
fields:
- c-ip
- cs-username
- cs-uri-stem
- sc-status
level: medium
If your logs include authenticated usernames or session-linked identities, compare the actor against a list of accounts granted only:
Admin > Nodes > View
Admin > Nests > View Egg
Admin > Nests > View Nest
Any successful state-changing request from those accounts is highly suspicious on vulnerable versions.
Mitigation and patching
The primary remediation is to upgrade Pterodactyl Panel to version 1.11.11 or later. The vulnerable range is before 1.11.11, and the fixed release identified in the advisory is 1.11.11. If you run a fork or distribution package, verify that the vendor has actually incorporated the fix rather than only updating documentation or package metadata.
Before and during patching, reduce exposure by reviewing and temporarily restricting the permissions explicitly mentioned in the advisory. If operationally possible, remove or narrow the following grants until all panel instances are confirmed fixed:
- Admin > Nodes > View
- Admin > Nests > View Egg
- Admin > Nests > View Nest
This is particularly important in environments with many moderators, junior administrators, or delegated operational staff. Because the flaw enables unauthorized updates with crafted requests, relying on the UI alone is not enough; access must be constrained at the permission layer or the software must be patched.
Technical Notes
The exact upgrade method depends on how you installed Pterodactyl Panel. If you deployed from Git, verify the current version and update to the 1.11.11 release tag or later. Example workflow:
cd /var/www/pterodactyl
git fetch --tags
git checkout v1.11.11
php artisan optimize:clear
php artisan migrate --force
If you use Composer in your deployment process, follow your standard release procedure and confirm the application reports 1.11.11 afterward. Where applicable, restart PHP-FPM and your web server:
sudo systemctl restart php-fpm
sudo systemctl restart nginx
If you need a temporary workaround before patching, reduce or remove the affected permissions from non-essential accounts. This is not equivalent to a full fix, but it can lower risk while you schedule maintenance. For example, document and revoke those permissions in the panel’s role model, then re-test who can access Nodes, Nests, and Egg management pages. In the absence of a published vendor workaround beyond upgrading, defenders should assume that patching is the only complete remediation.
If you maintain infrastructure as code or config backups, capture the current panel configuration before the upgrade and compare post-upgrade state to identify any unexplained drift:
tar czf /root/pterodactyl-panel-backup-$(date +%F).tar.gz /var/www/pterodactyl
Incident response checklist
If you suspect abuse, start by identifying all users who currently have or recently had the relevant permissions. Then review web logs, reverse-proxy logs, and any external audit source for state-changing requests to node, nest, or egg administration paths. Because panel activity logs may omit the unauthorized changes, collect alternate evidence early before retention windows expire.
Next, compare current configuration against last-known-good backups or documented baselines. Focus on node definitions, nest settings, and egg settings. If you find unexplained modifications, rotate any related secrets, review downstream service behavior, and preserve logs for timeline reconstruction. Even if no malicious change is obvious, patching and permission review should still be treated as urgent given the low-complexity exploit path.
References
- NVD CVE entry: CVE-2026-47114
- GitHub Security Advisory: GHSA-2jx7-8v2c-j8r8
- GitHub Advisory Database mirror: GHSA-2jx7-8v2c-j8r8
- Fix commit: bd37978ec4db4f19771da9f5d4f8902f329cda54