Plesk Security Review

Restricted Mode is the setting that decides whether an additional administrator account has the same privileges as the default Administrator, or only the specific tasks you switch on for it.

Why Plesk security comes down to account roles and installed extensions

Plesk separates administration into an Administrator account, any additional administrator accounts, Reseller accounts and Customer accounts, and each sits at a different depth in the server. Plesk’s own documentation is direct about the risk here: an unrestricted additional administrator account, in its own words, ‘effectively has the same level of privileges and access to the server as the default administrator account’, which is why it recommends an individual account per person with Restricted Mode applied wherever full access is not actually needed. Underneath that sit Customer accounts and their own additional users, each assigned a role that Plesk’s role utility can restrict down to individual permissions such as managing websites and domains. We test what every account in that hierarchy can actually reach, not what its label implies it should be able to do.

Every entry in the Plesk Extensions Catalog is written by a party outside Plesk itself, and Plesk’s own extensions guide describes an extension as simply third-party software that adds new functionality to Plesk. Once installed, an extension gets its own access into Plesk’s entities and data to do its job, the same third-party risk we test on any platform built around an open extension model. WP Toolkit is one such extension, Plesk’s own tool for installing and managing WordPress sites from the panel, and it has to be installed from that same catalog before it appears. We review every installed extension’s access directly, and where WP Toolkit is managing live WordPress sites we can extend the review into our dedicated WordPress penetration testing scope.

Plesk also exposes a REST API, an XML API and command-line utilities, and access to all three is granted per role rather than assumed. Plesk’s documentation confirms that session-token creation is scoped by role: an administrator can create a token for anyone, a reseller only for themselves and their own customers, and a customer only for themselves, and an additional administrator needs the Ability to use remote API permission switched on before the API works at all. The XML API can authenticate with a secret key instead of a password, and Plesk stores only the key’s hash once it has been created. We test whether those role and permission boundaries actually hold when we call the API and CLI directly, not just what the panel’s own interface prevents.