Impact
When a user disables two-factor authentication via the Panel, a DELETE request with their current password in a query parameter will be sent. While query parameters are encrypted when using TLS, many webservers (including ones officially documented for use with Pterodactyl) will log query parameters in plain-text, storing a user's password in plain text.
If a malicious user obtains access to these logs they could potentially authenticate against a user's account; assuming they are able to discover the account's email address or username separately.
Patches
This problem has been patched by pterodactyl/panel@8be2b89 on the 1.0-develop branch and released under v1.11.8 as a single commit on top of v1.11.7 pterodactyl/panel@75b5908
Patch file: https://github.com/pterodactyl/panel/commit/8be2b892c3940bdc0157ccdab16685a72d105dd1.patch
Workarounds
There are no workarounds at this time. There is not a direct vulnerability within the software as it relates to logs generated by intermediate components such as webservers or Layer 7 proxies.
Updating to v1.11.8 or adding the linked patch manually are the only ways to avoid this problem.
User Notice
As this vulnerability relates to historical logging of sensitive data, users who have ever disabled 2FA on a Panel (self-hosted or operated by a company) should change their passwords and consider enabling 2FA if it was left disabled. While it's unlikely that your account will be compromised by this vulnerability, it's not impossible.
Panel administrators should consider clearing any access logs that may contain sensitive data, for Panels using NGINX, the access log is located at /var/log/nginx/pterodactyl.app-access.log.
References
pebblehosts Reporter
Impact
When a user disables two-factor authentication via the Panel, a
DELETErequest with their current password in a query parameter will be sent. While query parameters are encrypted when using TLS, many webservers (including ones officially documented for use with Pterodactyl) will log query parameters in plain-text, storing a user's password in plain text.If a malicious user obtains access to these logs they could potentially authenticate against a user's account; assuming they are able to discover the account's email address or username separately.
Patches
This problem has been patched by pterodactyl/panel@8be2b89 on the
1.0-developbranch and released underv1.11.8as a single commit on top ofv1.11.7pterodactyl/panel@75b5908Patch file: https://github.com/pterodactyl/panel/commit/8be2b892c3940bdc0157ccdab16685a72d105dd1.patch
Workarounds
There are no workarounds at this time. There is not a direct vulnerability within the software as it relates to logs generated by intermediate components such as webservers or Layer 7 proxies.
Updating to
v1.11.8or adding the linked patch manually are the only ways to avoid this problem.User Notice
As this vulnerability relates to historical logging of sensitive data, users who have ever disabled 2FA on a Panel (self-hosted or operated by a company) should change their passwords and consider enabling 2FA if it was left disabled. While it's unlikely that your account will be compromised by this vulnerability, it's not impossible.
Panel administrators should consider clearing any access logs that may contain sensitive data, for Panels using NGINX, the access log is located at
/var/log/nginx/pterodactyl.app-access.log.References