Pterodactyl Panel — The Free and Open-Source Self-Hosted Game Control Panel

ATTN: Critical Security Vulnerability affecting all versions of Daemon from 0.4.0-pre.1 to 0.4.1

This is a critical security release to address a bug in the implementation of the daemon. You should update immediately.

Upgrade Guide:

Due to an oversight in how the websockets were configured in the daemon, the last person to load the console socket would apply their permissions for anyone who had the console loaded. This caused anyone who should not have had permissions to send commands to the console to suddenly have permissions to do so.

The root cause of this exploit was setting the authentication token on line 34 of socket.js which applied it globally to the socket, rather than locally to the connected client. This issue has been rectified to read the token passed on each call to the Socket, and removes the global token apply which should not have existed.

This exploit required a valid user authentication token to be provided in order to even authenticate with the websocket, as such any non-subusers would not have been able to access data from or send data to the websocket. However, due to the structure of the code, a user could spam the websocket connection and cause all other authenticated users to be de-authenticated with the spammed invalid token. This method would still have required a user to know a server’s UUID, which is generally not public information unless the user already had some type of access to that server. Users who had both a valid server UUID and authentication token would have been able to bypass their own lower permissions if a user with higher permissions loaded the websocket in their browser.

This was a fairly unique “edge” case, but is none-the-less something that should not have been introduced. Moving forward we will be sure to include this type of dual-user load testing on the application and daemon to ensure that permissions are not overwritten when a new user loads the page.

Thank you to Mohron#9350 who discovered this issue and reported it to us on Discord. This vulnerability was disclosed on June 14, 2017 at 20:44 U.S. Central Time and a fix was pushed to Github at 21:34.

Affected Versions

This bug was introduced in c73056ff; this exploit is present in all versions of the Daemon from 0.4.0-pre.1 to 0.4.1 and is patched in 0.4.2.

Security Vulnerability Disclosure: June 26th, 2017

On June 26th, 2017 we made an immediate hot-fix security release to address a critical application bug that allowed unauthenticated users the ability to execute arbitrary code aganist any server running on Pterodactyl Panel. At the time this incident was determined to be too significant to warrant an immediate full-disclosure and we made only basic detail available encouraging all users to update immediately. As we have now passed our cut-off date that we announced, a full disclosure will be happening in this post.

Due to an implementation in the jQuery based terminal we were using, anything that was passed inside of double square brackets was determined to be a new command, and was executed as such. This exploit hinged on a user loading the web-console within Pterodactyl to execute any commands sorrounded by brackets. As soon as this bug was reported I took immediate action to narrow down the exact scope of the bug, and determine if it was isolated to specific games and if it required specific knowledge to execute. Unfortunately it quickly because clear that all software running via the Panel was at risk, and that no special knowledge was required in order to execute commands. The full attack vector quickly became more obvious as any commands in the server’s console history would also be executed, even if the console was not open at the time of the command execution.

This exploit did not require any access to the panel, and any user who could send input to the server that was rendered in a log would be able to execute arbitrary commands aganist the game server. Commands simply needed to be sorrounded in square brackets, and it did not matter where in the line they were. An example of this exploit is below.

this is my [[op Username]] text

In this instance, the output would be parsed by the web terminal to execute op Username as a second command as the currently authenticated panel user. This execution also caused the original message to be lost in most cases. Because of the way the terminal loaded messages on page load, any commands in the console buffer history were also executed. This allowed a malicious user to send a command, and even if the terminal was not currently open, as long as the message remainined in the scrollback history, it would be executed when the page was loaded.

Narrowing down the scope of this bug to determine which versions of the Panel were affected it discovered that the bug was introduced in v0.4.0 resulting in a significant vulnerability that affected nearly every panel that was being operated.

Upon discovery I attempted to find a solution that would allow us to continue using the web-console that we were already using, but all solutions hinged on client-side JS, and were not something I felt comfortable pushing onto production environments, nor was I positive that it would cover all edge cases. The jQuery terminal plugin in use did provide functionality to escape brackets, however that caused color formatting to be escaped which made it impossible to filter ANSI codes. Because of these issues, I made the decision to completely strip the web-terminal from the project and a few hours later pushed up a hot-fix using a custom written terminal that did not execute any commands, it simply took the output and pasted it to the browser (escaping code as necessary, and handling ANSI color codes).

This fix was pushed later that night, and a subsequent patch to address residual JS issues and formatting a few days later.

In all previous software bugs, some level of Panel access has been required, and the bugs had been deemed to be something that could be disclosed at the time of the bug-fix release. This bug highlighted a danger in relying on external software to handle different actions, and also highlights a danger in not fully reading the documentation for software being used. During the review phase of this incident, I discovered a small amount of documentation for the web terminal that indicated this behavior was possible that was not seen during the initial implementation.

One of the core principals of this software is to be transparent about any security issues that arise in the course of development. I aim to never make these notifications, unfortunately that has not been the case in recent months. I welcome any questions, comments, or concerns that you might have about this announcement.

June 26th @ 15:00 CST — Support Team member is alerted to the presence of a vulnerability in command handling process. Project team is notifed immediately, basic testing performed to verify legitimacy of bug.

18:00 CST — Full investigation into source of bug is launched, patching begins immediately.

22:36 CST — Bug is patched in develop branch, and releases are prepared.

23:08 CST — v0.6.3 release is pushed to GitHub and made available to all users, minutes later notification is made in Discord to alert all inidividuals on the server of the urgency. CDN files updated to reflect a new update that began propigating to all active Panels.

July 27th — Second notification made in Discord to alert users during more active peak times of the security disclosure, and to urge them to update immediately.

July 30th — v0.6.4 released with a memo at the bottom to encourage updates. An email was sent to the mailing list to reach out to more individuals.

July 8th — Additional notification made in Discord to alert users to update pending this announcement.


I don’t understand, were the commands being issued by the web browser clients watching a server? or were they being executed server side of the panel?

Surely if the first, a client-side JS fix would have been appropriate? Or was it the type of fix that was the problem?

There could have been a client side fix, but that posed a few problems:

1.) The only feasible way was to escape brackets, which works fine, until you factor in ANSI codes which are rendered with brackets in the output, thus breaking the parsing of colors.
2.) Clearly this terminal is designed to be quite functional, and posed a lot of potential issues in the future, so I made the decision to just in-house it so that it would be very simple, and only do exactly what I needed it to do.
3.) There were already a few bug reports coming from users especially with mobile use, which is fixed with the custom written console.

1 Like

v0.7 beta is coming… soon™…

New scheduled tasks, code overhaul, internal SFTP, and unit tests!

1 Like

I am happy to announce that the latest versions of the Panel and Daemon have reached the release candidate phase! This means that they are considered feature complete, and the remaining time before stable release will be spent hunting down remaining bugs, finalizing our test suite, and documenting the API fully. Thank you to our wonderful beta testers who have continued to provide excellent feedback and bug reports that should make our stable release continue smoothly once it is release. For those of you on the beta, or looking to upgrade to the beta, the upgrade guides can be found below. Please remember, just because these are a release candidate does not mean they are bug free, it only means they are feature complete!

It is with great excitement that I can announce the first stable release of Pterodactyl Panel v0.7, codename Derelict Dermodactylus. This version of Pterodactyl has been under constant development for the last 6 months, meticulously being rewritten to improve our codebase moving forward, address significant underlying bugs in the Daemon architecture, implement a new SFTP subsystem, and focus heavily on improving the Panel you’ve come to love.

Today would not be possible without the help of every member of this community, but a special thanks go to our Project Team, the ever-amazing Support Team, and all of you who helped beta test this new version so thoroughly. This release has taken significantly more time than was ever anticipated and for that I apologize. Moving forward there will be much smaller, incremental updates to the Panel, ideally every 2 weeks at most.

Please be aware that this release completely rewrites how the API works and as such, the existing WHMCS module does not work on this release. If you are reliant on that module please hold off updating until it is upgraded or another module becomes available. Links for upgrades are below, expect a blog post in the coming days showing off why Pterodactyl is now one of the best game-server control panels on the market, and the best open-source solution for your community.


We will continue to support v0.6.4 for the next while, do not feel that you need to rush to upgrade tonight.