Plesk CVE-2026-67394: a shell-enabled tenant can escalate to root

CVE-2026-67394 is a critical local privilege-escalation flaw in Plesk for Linux. A customer or reseller with shell access—or permission to change their own shell-access setting—can use OS command injection to obtain root control of the server. The affected ranges are Plesk Obsidian 18.0.34–18.0.79.8 and 18.0.80–18.0.80.4. Fixed builds are 18.0.79.9 and 18.0.80.5, respectively.

Plesk for Windows is not affected. Today’s NVD record scores the issue 9.0 Critical under CVSS 4.0. The vendor updated its advisory on 27 August, so operators following primary notices could patch earlier. NVD publication now makes the flaw more visible to automated scanners and vulnerability-management workflows.

This is not unauthenticated internet RCE. An attacker needs a customer or reseller position and shell access or the ability to enable it. In shared hosting, that condition is not exotic: shell may be a service-plan feature, deployment tool or tenant-controlled option. Crossing from a tenant account to root breaks the server’s fundamental isolation assumption.

Why a local flaw is critical on a hosting panel

A panel such as Plesk manages many domains, PHP processes, databases, certificates, DNS, mail and backups. A customer receives a controlled portion of that surface. The operating system and panel must prevent one subscription from changing another’s files and stop a reseller from capturing operator infrastructure.

Root sits beyond that model. After escalation, an attacker can read configuration and secrets across tenants, alter binaries and services, disable monitoring, compromise backups and persist outside their own domain directory. Even where applications use separate PHP pools or containers, host root can commonly observe their files, processes and traffic.

The local-account requirement therefore does not make the weakness minor. In multi-tenant hosting, a customer is part of the threat model rather than a trusted administrator. Stolen SFTP or SSH credentials, an abused test account or a deliberately purchased low-cost plan can provide the required foothold.

What the sources establish

NVD classifies the issue as local escalation through OS command injection. Plesk says it applies to a customer or reseller with shell access or permission to alter their own shell setting. The vendor does not publish a detailed exploitation sequence, a reasonable choice for a root-impact flaw.

Operators should not narrow “shell access” to interactive public SSH without evidence. In Plesk, shell access is a hosting setting affecting the account’s execution model and available facilities. Review active sessions, service plans, reseller exceptions and the right to change the setting.

The vendor is equally clear about mitigation. If shell is required, there is no full workaround replacing the update. Where it is unnecessary, operators can temporarily set it to Forbidden and remove the customer or reseller’s ability to change the option. This is a conditional barrier, not a patch.

Inventory beyond the dashboard number

Establish the version on every managed host, including less visible migration systems, staging, disaster-recovery machines and images used for rapid restoration. A central management cluster does not prove that every node received the same microupdate.

Then export a map of:

• customers and resellers with active shell access;
• accounts allowed to change their shell type;
• service plans inheriting that right;
• system accounts, UIDs, home directories and recent logins;
• manually created exceptions outside standard plans;
• API integrations automating provisioning.

A corrected system is at least 18.0.79.9 on the maintained 18.0.79 branch or 18.0.80.5 on 18.0.80. Prefer the newest supported microupdate accepted by the operator, since later releases may contain additional corrections.

Updating without losing evidence

Before changing state, retain baseline investigation data: authentication logs, Plesk journals, service-change history, auditd or EDR events, process and connection lists, accounts and filesystem metadata. Do not delay the patch for days to achieve perfect acquisition, but avoid destroying all context through automated log cleanup.

Rollout should cover:

1. disabling or constraining shell for accounts without a justified need;
2. updating Plesk to a fixed or later release;
3. confirming the version on the host, not only a central dashboard;
4. testing login, hosting, mail, DNS, backup and jobs afterward;
5. rebuilding the list of accounts that retain shell;
6. hunting for activity predating the update.

For a fleet, deploy in waves but keep the gap short. The final unpatched host remains an easy target for someone holding a legitimate tenant account.

Emergency mitigation

When an immediate update is impossible, Plesk recommends setting shell access to Forbidden for subscriptions and resellers that do not need it, then ensuring the service plan does not let them re-enable it. Check inheritance effects: changing a plan without synchronising existing subscriptions may leave current state unchanged.

Do not replace this with a public firewall block on port 22. A user may reach another local path, panel console, job facility or hosting mechanism. The CVE prerequisite is shell access in Plesk’s model, not a particular SSH source address.

Nor is removing shell from one suspicious account sufficient. Cover the entire account population and permission to change the setting. If shell is part of the service, the vendor offers no complete workaround; the microupdate remains the priority.

Hunting for escalation evidence

Look for customer or reseller sessions preceding root-owned processes, unexpected UID or GID changes, SUID files, sudoers modifications, systemd units, root cron entries, SSH keys and libraries loaded by services. Correlate panel events with auth.log or journal, auditd and EDR telemetry.

Examine persistence outside obvious locations too: web-server configuration, PHP wrappers, backup tasks, package repositories and Plesk hooks. Root can alter local logs, so compare them with remote copies and hypervisor or cloud evidence.

If a credible tenant-to-root chain exists, in-place cleanup should not be the sole response. Rebuild from a trusted image, restore verified data and rotate secrets for every tenant root could access. Investigate backups and images produced after the suspicious timestamp.

Reducing panel blast radius

The patch removes this bug but does not change the panel’s role as a highly privileged control plane. Separate higher-risk customers, limit tenant density per host, centralise logs off-server and isolate backup credentials from panel credentials.

Customer accounts should use MFA where possible, while shell should use separate keys, short lifetimes and alerts. Reseller access deserves a privileged-account-style review. Consider distinct pools or hosts for plans requiring shell when the rest of the service can operate without it.

Safe validation

Do not reproduce command injection in production. Confirm package and file versions, microupdate status and post-restart service behaviour. On an isolated clone, verify that an ordinary customer retains required shell functions but cannot change settings outside their scope. A test need not obtain root to prove the patched version and access controls.

Monitor process failures and tenant reports after rollout, but do not automatically revert the fix after the first incompatibility. Determine whether the issue comes from cache, an unsynchronised plan or a particular extension.

Source facts and Breachroad conclusions

Affected ranges, the shell-access prerequisite, Windows exclusion, fixed versions and Forbidden mitigation come from the Plesk advisory and NVD. Multi-tenant threat modelling, hunting and rebuild guidance are Breachroad’s conclusions. The sources do not report confirmed active exploitation of CVE-2026-67394.

Primary sources

• Plesk advisory for CVE-2026-67394
• Plesk Obsidian update guidance
• NVD: CVE-2026-67394

Tenant-to-root escalation tests the entire multi-tenancy model, not one command. Our cybersecurity training teaches teams to connect a vulnerability with identity, configuration and blast radius. An independent IT security audit can assess the control plane, accounts, logging and hosting rebuild procedure.