Plesk CVE-2026-44962 Puts Shared Hosts on Patch Alert

The Plesk CVE-2026-44962 vulnerability affects Plesk, WebPros International GmbH’s hosting control panel, through a critical XML Path Language (XPath, a query language for Extensible Markup Language data) injection bug in the Application Packaging Standard (APS, the legacy app catalog framework) Catalog on Linux, according to the National Vulnerability Database record. It can let a low-privileged authenticated user escalate privileges and run operating-system commands, so administrators should patch fixed builds or disable the catalog as a stopgap.

The fixed-build advisory from Plesk says versions 18.0.76.2 and 18.0.75.1 were published on Feb. 24 and Feb. 25, 2026. That timing puts shared hosts in an uncomfortable lane: the public identifier is fresh in June, but safe builds have been available since late February.

Why a Low-Privilege Bug Hits Shared Hosts Hard

Control-panel flaws hit differently on shared infrastructure. A normal app bug may affect one customer site. A panel bug sits above subscriptions, databases, mailboxes and installers that many customers touch through the same administrative surface.

The government record describes the attacker as authenticated and low-privileged, which sounds like a limit. On a shared host, that user can be a reseller, a customer account, a developer login or a compromised account bought cheaply after a phishing run. The changed-scope flag in the Common Vulnerability Scoring System (CVSS, a 0 to 10 severity scale) is the warning sign for operators.

• 9.9 CVSS: HackerOne, the vulnerability disclosure platform credited in the NVD entry, rates the flaw critical with network attack vector, low complexity, low privileges, no user interaction and high impact to confidentiality, integrity and availability.
• Two fixed builds: Plesk published 18.0.76.2 on Feb. 24 and 18.0.75.1 on Feb. 25, matching the security note and the Plesk Obsidian change log.
• One workaround: Plesk tells admins who cannot upgrade at once to add an [aps] section to /usr/local/psa/admin/conf/panel.ini and set enabled = off.

Taken together, the numbers point to priority, not panic. A multi-tenant control plane deserves a faster patch queue than a single-tenant web app, even when the bug requires login.

Patch Status and Exposure Checks

The action split is version-specific. The GitHub Advisory Database severity record, GitHub’s vulnerability advisory index, lists the affected and patched versions as unknown, so the vendor advisory carries the operational detail admins need.

If a fleet already runs 18.0.77 or later, the catalog question changes because Plesk says the feature was removed in that release line. That does not clear older images, forgotten virtual private servers or customer-managed panels that stopped taking automatic updates.

APS Was Already on the Exit Ramp

The component at the center of the advisory was already being retired. Plesk’s feature deprecation plan says the catalog was scheduled for deprecation and removal in 18.0.77, with already installed applications continuing to work but without support for APS applications.

That matters because removal plans often live in product-management calendars, while exposure lives in old server builds. Hosting firms tend to have a clean main fleet and a messy tail: legacy nodes, customer-specific templates, stale snapshots, demo panels and appliances that only receive updates when something breaks.

The old installer path also sat close to customer action. It handled application packages, metadata and search, which made it useful for self-service hosting. A search flaw in that area is not just a broken filter; it is a bug in a place where ordinary users were expected to send input.

Georgii Shutiaev, the security researcher credited by Plesk, reported the flaw through responsible disclosure, according to the company. The patch arrived before the broad public write-up, which is the best sequence defenders can get; the remaining question is whether every exposed server followed the same sequence.

The Injection Path in Plain English

At a code level, the issue is direct. MITRE’s Common Weakness Enumeration entry for XPath injection describes a product that builds an XML query from external input without neutralizing that input, letting an attacker control query structure.

In Plesk’s case, the search function took user input into an XML query path. If a malicious string can change that path, the application may retrieve or trigger something outside the developer’s intent. The published advisory says the final impact can be local privilege escalation and command execution on the server.

• Authenticated user: The attacker needs a login, but not an administrator account.
• Low complexity: The advisory score says exploitation does not require unusual conditions.
• Changed scope: A vulnerable component can affect resources beyond its own security boundary.
• High impact: Confidentiality, integrity and availability all sit at the top impact level in the score.

The uncomfortable bit is the chain. A tenant account can be a foothold; command execution can be a server event. That gap is why the flaw deserves attention even without an unauthenticated path.

Admin Response, From Fastest Win to Deeper Audit

The fastest response is boring, which is good. Confirm the build, update through the interface or command line, and then check the panel configuration only if a maintenance window blocks patching. Plesk’s update installation guide notes that the panel may go offline for several minutes during an update, while websites stay online unless a service component restarts.

1. Check the installed build from Home > System Overview or run plesk version from a shell.
2. If the build is behind the fixed lines, update Plesk before changing customer permissions.
3. If updating is blocked, add [aps] and enabled = off to /usr/local/psa/admin/conf/panel.ini, then schedule the vendor patch.
4. Record which servers had the workaround, because a temporary config change can survive longer than intended.

For larger hosts, the governance point is patch first, isolate second. Turning off a component reduces exposure, but it does not replace the vendor fix and it does not answer whether a vulnerable build has already been probed.

Customer-facing support teams also need a plain answer ready. If a reseller asks whether their sites were affected, the truthful response depends on build evidence, panel access logs and whether the catalog was enabled, not on the global severity score alone.

Signals That Deserve a Log Review

Admins should not wait for a public proof of concept before looking at logs. The vulnerability description points to a search path, and the impact points to command execution, so the review should cover both the panel layer and the host layer.

• Panel requests tied to catalog search, especially unusual characters, nested predicates or repeated failed searches from one account.
• New or unexpected privileged processes spawned near panel activity.
• Changes to customer, reseller or subscription permissions after a suspicious login.
• New files in temporary directories or application-cache locations used by the installer path.

Hardening also fits this incident. Reduce the number of panel users with elevated rights, review reseller permissions, restrict remote programmatic access, require multi-factor authentication and keep system packages current. Those steps do not erase this bug, but they shrink the set of accounts and paths an attacker can use.

The GitHub record’s Exploit Prediction Scoring System (EPSS, a 30-day exploitation probability model from the Forum of Incident Response and Security Teams) sits at 0.047 percent. Treat that as triage context, not comfort. A low short-term probability can still be the wrong bet for a server that hosts dozens or hundreds of unrelated customers.

The Control Panel Lesson

This episode lands in a familiar weak spot for hosting-control software. The panel sits between small businesses and the Linux servers that run their sites, so even an authenticated flaw can have a bigger operational footprint than a typical plugin bug.

The pattern is familiar: old feature, high privilege boundary, broad customer access. Security teams often chase the flashiest unauthenticated remote code execution bug first, but shared control panels have a different threat model because the attacker may already be a valid customer.

The practical lesson is control-panel bugs travel sideways. They cross from one account model into a host model, from an application catalog into a shell, from a routine customer login into an incident-response ticket.

By June 2, the fix path is public, the workaround is simple and the component has a retirement notice. Remaining exposure now points to inventory, not disclosure.