Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
17 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A privilege escalation vulnerability exists in the Wings /upload/file endpoint due to insufficient validation of panel-signed JWTs. Wings accepts any valid panel-signed JWT containing serveruuid, useruuid, and uniqueid, regardless of the token’s intended purpose. Because the Panel issues JWTs with these same claims for other lower-privilege operations (such as WebSocket authentication and file download links), an authenticated subuser can reuse one of those tokens to upload arbitrary files without possessing the required file.create permission. Impact Any subuser with permission to connect to a server's console, download files, or download backups could reuse those tokens to upload arbitrary files to the same server. A user that does not have access to a server as a subuser is not able to arbitrarily upload files. Details The panel generated JWT tokens for various purposes: -…
Recommended action: Upgrade to 1.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A maliciously crafted packet received & parsed during the SFTP connection handshake will cause a Go panic. Impact All wings users with an open SFTP port. Workarounds Close SFTP port.
Recommended action: Upgrade to 1.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Type: Exposure of sensitive information / insufficiently protected credentials leading to privilege escalation and full node compromise. Wings exposes its entire daemon configuration to the egg configuration-file templating engine. When Wings renders a server's configuration files, any {{config.<path}} placeholder in a replacement value is resolved against the full marshalled daemon configuration, with no restriction on which paths may be read. Because the Panel substitutes user-controlled egg variable values into these replacements before sending them to Wings, a low-privileged user can smuggle a {{config.}} placeholder through a variable value. The placeholder is then resolved by Wings and written into a file inside the user's own server, where it can be read via the file manager or SFTP. This allows reading, among other values: - {{config.token}} - the node's daemon token, which is both the API bearer for the Panel⇆Wings channel and the HMAC signing key for every JWT the…
Recommended action: Upgrade to 1.12.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Config file parsers, json, yaml, xml etc in parser.go have no file size limit/checks, allowing for a giant config file to potentially OOM the wings process. Impact All wings users who have an egg with a non-file parser configuration file setting.
Recommended action: Upgrade to 1.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/pterodactyl/wings >= 1.11.9, < 1.12.2
Fixed in
1.12.2· Vendor fix available
Issue
In wings/internal/ufs/fsunix.go (line 92-94), this function is defined and is used to change permissions of files in the server: This call to the unix function fchmodat(int fd, char name, modet mode, int flags) does not have the flag ATSYMLINKNOFOLLOW set, and Wings neither checks or validate if the target file is a symlink. This allows one to change permissions of files or folders outside of the server container by making symlinks to existing files in the host and then chmoding it.
Recommended action: Upgrade to 1.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Deleting a user account with SFTP access or changing the user's password does not immediately terminate existing SFTP sessions, allowing continued filesystem access after credentials are revoked. This can result in unintended and unauthorized access to server files even after administrators believe access has been fully invalidated. Details When a user with SFTP access is deleted from the Pterodactyl Panel or when the user's password is changed while one or more SFTP connections are active, those existing connections remain fully functional. Neither account deletion nor password change invalidates the authentication state of already-established SFTP sessions. As a result, the active SFTP connection pool continues to allow read and write operations until the client disconnects or the session times out. This behavior occurs even when the password is changed by an administrator through the panel, meaning credential rotation does not revoke active access. This suggests that…
Recommended action: Upgrade to 1.12.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/pterodactyl/wings >= 1.7.0, < 1.12.0
Fixed in
1.12.0· Vendor fix available
Issue
Wings does not consider SQLite max parameter limit when processing activity log entries allowing for low privileged user to trigger a condition that floods the panel with activity records Details After wings sends activity logs to the panel it deletes the processed activity entries from the wings SQLite database. However, it does not consider the max parameter limit of SQLite, 32766 as of SQLite 3.32.0. If wings attempts to delete more than 32766 entries from the SQLite database in one query, it triggers an error (SQL logic error: too many SQL variables (1)) and does not remove any entries from the database. These entries are then indefinitely re-processed and resent to the panel each time the cron runs. https://github.com/pterodactyl/wings/blob/9ffbcdcdb1163da823cf9959b9602df9f7dcb54a/internal/cron/activitycron.go#L81 https://github.com/pterodactyl/wings/blob/9ffbcdcdb1163da823cf9959b9602df9f7dcb54a/internal/cron/sftpcron.go#L86 PoC Any method that can create the required…
Recommended action: Upgrade to 1.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Websockets within wings lack proper rate limiting and throttling. As a result a malicious user can open a large number of connections and then request data through these sockets, causing an excessive volume of data over the network and overloading the host system memory and cpu. Additionally, there is not a limit applied to the total size of messages being sent or received, allowing a malicious user to open thousands of websocket connections and then send massive volumes of information over the socket, overloading the host network, and causing increased CPU and memory load within Wings.
Recommended action: Upgrade to 1.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Pterodactyl does not revoke active SFTP connections when a user is removed from a server instance or has their permissions changes with respect to file access over SFTP. This allows a user that was already connected to SFTP to remain connected and access files even after their permissions are revoked. Details When a user opens a connection to a server using the Wings SFTP server instance the permissions are checked and returned from the authentication API call made to the Panel. However, credentials are not checked again after the initial handshake. Thus, if a user is removed from a server in the panel or have their permissions modified, those permissions are not updated in the SFTP connection. As a result, a user that has already gained access to a server's files via the SFTP subsystem will maintain those permissions until disconnected (via Wings restart, or a manual disconnection on their end). [!NOTE] This issue impacts the SFTP subsystem for server files specifically.…
Recommended action: Upgrade to 1.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user who has access to a game server is able to bypass the previously implemented access control (https://github.com/pterodactyl/wings/security/advisories/GHSA-6rg3-8h8x-5xfv) that prevents accessing internal endpoints of the node hosting Wings in the pull endpoint. This would allow malicious users to potentially access resources on local networks that would otherwise be inaccessible. Workarounds Enabling the api.disableremotedownload option or updating to the latest version of Wings are the only known workarounds. Patches https://github.com/pterodactyl/wings/commit/c152e36101aba45d8868a9a0eeb890995e8934b8
Recommended action: Upgrade to 1.11.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If the Wings token is leaked either by viewing the node configuration or posting it accidentally somewhere, an attacker can use it to gain arbitrary file write and read access on the node the token is associated to. Workarounds Enabling the ignorepanelconfigupdates option or updating to the latest version of Wings are the only known workarounds. Patches https://github.com/pterodactyl/wings/commit/5415f8ae07f533623bd8169836dd7e0b933964de
Recommended action: Upgrade to 1.11.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This vulnerability impacts anyone running the affected versions of Wings. The vulnerability can potentially be used to access files and directories on the host system. The full scope of impact is exactly unknown, but reading files outside of a server's base directory (sandbox root) is possible. In order to use this exploit, an attacker must have an existing "server" allocated and controlled by Wings. Details on the exploitation of this vulnerability are embargoed until March 27th, 2024 at 18:00 UTC. Resolution In order to mitigate this vulnerability, a full rewrite of the entire server filesystem was necessary. Because of this, the size of the patch is massive, however effort was made to reduce the amount of breaking changes. While tests were written to ensure security and functionality, there may be some semantic differences of certain operations, such as different errors being returned for example. If you notice any major semantic differences, please open an issue on our…
Recommended action: Upgrade to 1.11.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/pterodactyl/wings < 1.7.5; >= 1.11.0, < 1.11.6
Fixed in
1.11.61.7.5· Vendor fix available
Issue
Impact This vulnerability impacts anyone running the affected versions of Wings. This vulnerability can be used to gain access to the host system running Wings if a user is able to modify an server's install script or the install script executes code supplied by the user (either through environment variables, or commands that execute commands based off of user data). Patches This vulnerability has been resolved in version v1.11.6 of Wings, and has been back-ported to the 1.7 release series in v1.7.5. Anyone running v1.11.x should upgrade to v1.11.6 and anyone running v1.7.x should upgrade to v1.7.5. Workarounds Running Wings with a rootless container runtime may mitigate the severity of any attacks, however the majority of users are using container runtimes that run as root as per our documentation. SELinux may prevent attackers from performing certain operations against the host system, however privileged containers have a lot of freedom even on systems with SELinux enabled. TL;DR:…
Recommended action: Upgrade to 1.11.6 or 1.7.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/pterodactyl/wings < 1.7.4; >= 1.11.0, < 1.11.4
Fixed in
1.7.41.11.4· Vendor fix available
Issue
Impact This vulnerability impacts anyone running the affected versions of Wings. The vulnerability can be used to delete files and directories recursively on the host system. This vulnerability can be combined with GHSA-p8r3-83r8-jwj5 to overwrite files on the host system. In order to use this exploit, an attacker must have an existing "server" allocated and controlled by Wings. Information on how the exploitation of this vulnerability works will be released on February 24th, 2023 in North America. Patches This vulnerability has been resolved in version v1.11.4 of Wings, and has been back-ported to the 1.7 release series in v1.7.4. Anyone running v1.11.x should upgrade to v1.11.4 and anyone running v1.7.x should upgrade to v1.7.4. Workarounds None at this time.
Recommended action: Upgrade to 1.11.4 or 1.7.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/pterodactyl/wings >= 1.11.0, < 1.11.3; < 1.7.3
Fixed in
1.11.31.7.3· Vendor fix available
Issue
Impact This vulnerability impacts anyone running the affected versions of Wings. The vulnerability can be used to create new files and on the host system that previously did not exist, potentially allowing attackers to change their resource allocations, promote their containers to privileged mode, or potentially add ssh authorized keys to allow the attacker access to a remote shell on the target machine. In order to use this exploit, an attacker must have an existing "server" allocated and controlled by Wings. Information on how the exploitation of this vulnerability works will be released on February 24th, 2023 in North America. Patches This vulnerability has been resolved in version v1.11.3 of Wings, and has been back-ported to the 1.7 release series in v1.7.3. Anyone running v1.11.x should upgrade to v1.11.3 and anyone running v1.7.x should upgrade to v1.7.3. Workarounds None at this time.
Recommended action: Upgrade to 1.11.3 or 1.7.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/pterodactyl/wings >= 1.2.0, <= 1.2.0
Fixed in
1.2.1· Vendor fix available
Issue
Impact A newly implemented route allowing users to download files from remote endpoints was not properly verifying the destination hostname for user provided URLs. This would allow malicious users to potentially access resources on local networks that would otherwise be inaccessible. This vulnerability requires valid authentication credentials and is therefore not exploitable by unauthenticated users. If you are running an instance for yourself or other trusted individuals this impact is unlikely to be of major concern to you. However, you should still upgrade for security sake. Patches Users should upgrade to the latest version of Wings. Workarounds There is no workaround available that does not involve modifying Panel or Wings code.
Recommended action: Upgrade to 1.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact All versions of Pterodactyl Wings preior to 1.4.4 are vulnerable to system resource exhaustion due to improper container process limits being defined. A malicious user can consume more resources than intended and cause downstream impacts to other clients on the same hardware, eventually causing the physical server to stop responding. Patches Users should upgrade to 1.4.4. Workarounds There is no non-code based workaround for impacted versions of the software. Users running customized versions of this software can manually set a PID limit for containers created. For more information If you have any questions or comments about this advisory: Contact us on Discord Email us at dane ät pterodactyl dot io
Recommended action: Upgrade to 1.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.