Issue Major security inconsistency in Plesk admin access control logic

[zigzag]

Plesk Obsidian 18.0.68 Web Host Edition here.​

I'm reporting a major security and design inconsistency in how Plesk handles access control for the admin interface.

As part of the basic hardening process, I ensured that only essential ports — 80 and 443 — were exposed, as expected for a standard web server.

Since Plesk’s admin interface is officially documented to run on port 8443 and 8880, it was entirely reasonable to assume that administrative access would be strictly tied to that port.



To secure the environment, I not only applied restrictions at the edge firewall level, but also configured Plesk’s own Tools & Settings > Firewall to allow access to the admin interface only from specific IP addresses.



This setup clearly implies that the admin interface will be protected by that rule, and that such configuration should be sufficient to prevent unauthorized access to Plesk.

As previously stated, the admin interface is meant to be accessible only via port 8443 and 8880. Therefore, it’s entirely logical to expect that blocking that port for untrusted IPs would effectively make the admin interface inaccessible to them — as it should be. That’s the expected and logical behavior.

However, that's not the case. Apparently, someone thought it would be clever to proxy the admin interface through port 443, completely bypassing the expected security model.​

If someone accesses the server directly via its IP address, Plesk serves a default page on port 443, which includes a link pointing to https://[server_ip]/login_up.php.​

And that link? It exposes the full web admin interface — directly over port 443.​

This behavior completely bypasses the firewall rule, since Plesk is internally proxying traffic and unintentionally exposing the admin interface through the default virtual host on port 443.

So even with port 8443 and 8880 fully locked down to trusted IPs, anyone can still access the admin login page via HTTPS on port 443.

This design makes no sense.​

It forces administrators to:

• Manually configure “IP Access Restriction Management” (separate from the firewall), which is not clearly indicated as necessary.
• Understand that the firewall rules in Plesk do not actually restrict admin access, but only affect one specific port — 8443.

This violates all principles of secure-by-default design, and creates a dangerous false sense of security. The expectation is simple: if I restrict access to the admin interface via the firewall, it should be inaccessible from untrusted IPs — regardless of the port used to reach it.

Expected fix:

• Stop proxying the admin interface through web server ports (80/443). Use a single, well-defined port for admin access only!
• Unify all admin access restrictions into a single mechanism that applies globally, across all entry points.
• Or at the very least, display a clear warning in the UI that the firewall rules alone do not protect the admin interface from exposure via alternate paths (such as the default host on port 443).

This kind of behavior leads directly to unintended public exposure, and makes secure deployment of Plesk unnecessarily risky and confusing.

 

[Kaspar]

Whether or not Plesk is accessible via port 443 (rather than exclusively via 8443) depends on the chosen URL setting in Tools & Settings > Customize Plesk URL. If the option "No custom URLs." has been set, Plesk is only accessible via 8443 (even when browsing to the server's IP).

 

[zigzag]

To me continues to have no sense.

Plesk lets you set “Allow administrative access only from certain IPs” — but that only applies to port 8443.

Meanwhile, by default, the admin interface is also exposed on https://serverip/ via port 443, because in Tools > Customize Plesk URL, the setting is:

“All domains and subdomains that resolve to the server IP address but are not used for hosting.”

So basically:

You “restrict administrative access”, but the administrative interface is still available somewhere else.

That’s a clear contradiction: if it’s about admin access, then don’t leave alternative routes open by default.

 

[zigzag]

Whether or not Plesk is accessible via port 443 (rather than exclusively via 8443) depends on the chosen URL setting

By the way, Plesk documentation doesn’t mention that here

Ports Used by Plesk

For Plesk and its services to work correctly, certain ports must not be blocked.

docs.plesk.com

which makes the whole situation even more misleading.
It becomes kind of a joke when the docs don’t explain that “admin access” relies on specific ports — but then is, by default, also exposed through others.

 

[zigzag]

Of course this behavior didn’t exist years ago, back in the Onyx days or earlier. It has been introduced as a “feature” in some version of Obsidian, since I’ve seen that the default behavior of this setting actually changes depending on whether the server was upgraded or freshly installed. Customizing Plesk URL

Here’s the real flaw in the logic:

Yes, from an aesthetic perspective, it might look nicer to give customers a clean URL without the :8443 — although honestly, I don’t see how that’s such a major improvement. If you’re sending a link, you’re sending a link. You bookmark it, and you’re done.

But this should absolutely not be enabled by default, in no case.

Everyone coming from any hosting mindset expects a clear and consistent security model: default DENY rule, just like any proper firewall. Then, it’s up to the admin to explicitly open the gates — not the system doing it for them based on some "nice UX" logic.

And if this really has to be the default behavior (which it absolutely shouldn’t), then I expect it to be stated clearly and explicitly — in bold, capital letters, before any other — in the changelog and release notes.​

This is not a cosmetic detail. It directly affects security and completely alters the expected behavior of access control.​

 

[whsplesk]

@zigzag Apologies if I'm not understanding what you're describing, but for:

"If someone accesses the server directly via its IP address, Plesk serves a default page on port 443, which includes a link pointing to https://[server_ip]/login_up.php."

If you put your own .html file in the server's main htdocs directory, that gets displayed if someone visits the server's IP address, not the Plesk admin login page, or a link to it. (edited to add this last phrase)

 

[Kaspar]

If you put your own .html file in the server's main htdocs directory, that gets displayed if someone visits the server's IP address, not the Plesk admin login page, or a link to it. (edited to add this last phrase)

That won't (completely) prevent access to the Plesk login page. As any files on the server's main htdocs directory are only served on http (port 80) when accessing the server ip. However when acceding the server IP via HTTPS (port 443) you'll always been shown the Plesk login page. Unless the "No custom URLs." option has been set on the Customize Plesk URL settings page.

A better way to circumvent that would be to select a default website on the IP addresses setting page. That way the selected website gets served instead when visiting the server IP.

 

[zigzag]

The point is that it makes no sense for the firewall to let me set an IP restriction for accessing the "Plesk admin interface" if other settings still allow the interface to be exposed to any IPs. It's misleading — either you allow specific IPs to access the admin interface regardless of the port, or you clearly specify that the restriction only applies to 8443 and that there are other access paths (but a firewall and security should be centralized)