Plesk REST API Is Installed by Default and Hidden: CVE-2026-68492 Is Authenticated Root

The Situation

Plesk published CVE-2026-68492 as authenticated code execution as root through the Plesk RESTful API extension, on Plesk for Linux only.[1]

Two facts from that advisory matter more than the CVE ID:

The extension is installed by default and hidden in the Plesk interface. Not seeing it in Extensions is not evidence it is absent.[1]
You are only in the vulnerable set when both an affected Plesk build and an affected extension version are present at the same time. Patching one and leaving the other is not the fix Plesk described.[1]

NVD records this as CWE-426 Untrusted Search Path, CVSS 4.0 8.7 HIGH (AV:N/AC:L/AT:N/PR:L/UI:N, vuln CIA all High), published 23 September 2026.[2] GitHub's unreviewed advisory mirrors the same range.[3] CISA's coordinator SSVC on 24 September 2026 scored exploitation none, automatable no, technical impact total.[2] As of CISA KEV catalog 2026.10.04 (released 2026-10-04T18:52:56Z, 1734 entries) this CVE is not listed. That is a catalog snapshot, not a promise nobody is trying it.

Plesk credits Ali Mustafa (rz1027) for the report.[1]

What's Affected

Vendor matrix, verbatim in meaning from the 23 September advisory (KB updated ~9 days before this post):[1]

Component	Affected	First patched / not affected
Plesk for Linux	18.0.34 through 18.0.80.7, and 18.0.81.0	18.0.80.8, 18.0.81.1
Plesk for Windows	Not affected	n/a
Plesk RESTful API extension (`rest-api`)	2.4.2 through 2.4.6	2.4.7
Plesk before 18.0.34, or rest-api before 2.4.2	Not affected	n/a

A box on 18.0.80.8 with rest-api still at 2.4.6 is still in the AND. A box on 18.0.80.7 with rest-api already at 2.4.7 is out. Confirm both.[1]

Plesk says a remote authenticated user can execute arbitrary code as root via that extension. The public KB does not name the minimum role (admin vs reseller vs customer), does not name the search-path target, and does not claim in-the-wild use. Do not fill those gaps from a blog post - including this one.

Why This Matters for Hosts

This is a panel bug, not a tenant PHP site. Root on Plesk is every subscription on the box: vhosts, mail, databases, backups, the license, the next customer's WordPress.

The hidden-default install is the operational trap. Fleet scripts that grep the Extensions page, or that only parse plesk version, will green-light servers that still have rest-api 2.4.x. Plesk says the extension normally auto-updates; they still tell you to confirm 2.4.7 and force the catalog install if it has not.[1]

Shared and reseller Plesk is the worst case: you already issue authenticated sessions to people who are not you. Whether that session is enough is exactly the detail Plesk did not publish. Treat every Linux Obsidian host in the 18.0.34-18.0.81.0 window as need-to-verify, not as "only if we enabled REST."

Windows Plesk is out of scope per the vendor. Do not skip Linux VPS images, "one-click Plesk" cloud images, or forgotten staging panels because they are not in the public Extensions list.

What to Do Now

1. Inventory both numbers

SSH as root. Plesk's own version article is Tools & Settings → About Plesk, or CLI.[5] The CVE article's extension check is the one that catches the hidden component:[1]

plesk version
plesk bin extension --get-xml-info rest-api

The XML must show 2.4.7 or later. Plesk's example of a good reading:[1]

<?xml version="1.0"?>
<module fullVersion="2.4.7-18178" status="true"/>

Triage:

Plesk 18.0.80.8+ or 18.0.81.1+ and rest-api 2.4.7+ → this CVE is closed. Still keep both numbers in the CMDB.
Either side still in the affected range → patch that side. If both are in range, patch both.
get-xml-info rest-api fails or the module is missing → you still need an explicit answer, not an assumption. Re-run after plesk bin extension --install rest-api only if you intend to have the component; if it was never in the 2.4.2-2.4.6 window, this CVE does not apply.[1]

Do not triage from the marketing version (Obsidian 18) without the build (.80.7 vs .80.8).

2. Force the extension, then the panel

Plesk's call to action, in order:[1]

# If rest-api is older than 2.4.7:
plesk bin extension --install rest-api

# Then take Plesk itself to current (official updater; sites stay up, panel may blip):
plesk installer --select-release-latest --upgrade-installed-components

The installer command is from Plesk's Obsidian update article, not from the CVE page. That article also documents Tools & Settings → Updates → Install or Update Product, and notes installer port 8447.[4]

After both finish, re-run the two version commands. Stop when Plesk reports ≥ 18.0.80.8 on the 80 line or ≥ 18.0.81.1 on the 81 line, and rest-api reports 2.4.7+.[1]

If installer dies, fix the installer error - do not declare the CVE closed because one of the two commands printed "success."

3. After the floor, look once

Plesk did not publish IOCs. Closing the hole does not tell you whether an authenticated session used it last week. If a host sat in the AND-window with panel or REST reachable from untrusted networks, a one-pass integrity look is cheap:

# accounts / API keys you did not create
plesk bin user --list 2>/dev/null
# recent privileged file noise (adjust paths to your layout)
find /usr/local/psa /opt/psa /root /etc/cron.d /etc/systemd/system \
  -mtime -30 \( -type f -o -type l \) 2>/dev/null | head

Unexpected root SSH keys, new scheduled tasks, and panel users you cannot name are the usual next hop after a root RCE - that is generic IR, not a Plesk signature. If you cannot establish integrity, rebuild from known-good and rotate credentials off-box.

Restricting 8443/8880 to admin IPs is hygiene. It is not a substitute for 2.4.7 + 18.0.80.8/18.0.81.1, because the authenticated user may already be inside.

Honesty / What We Could Not Verify

Exploitation status: Plesk's KB does not claim in-the-wild use. NVD/CISA SSVC on 24 Sep 2026 is exploitation: none. Not in KEV as of catalog 2026.10.04. Absence from KEV is not "nobody will exploit this."
Who can pull the trigger: vendor text is "remote authenticated users." We do not know whether a customer, reseller, or only an admin/API token is enough. Do not write your access model as a mitigator until Plesk says so.
Mechanism: CWE-426 is NVD/HackerOne's class, not a root-cause write-up. We did not identify which binary the search path hits and we did not reproduce the bug.
CVSS: 8.7 is NVD CVSS 4.0. Plesk's public KB in front of us did not print a vendor score. Do not mix that with a 3.1 vector you invented.
Auto-update: "normally updated automatically" is Plesk's sentence.[1] Measure fullVersion, do not trust the sentence.
This lab: we did not run these commands against a live Plesk box for this post. Copy-paste from the vendor pages cited below.

Sources

Plesk, "Vulnerability CVE-2026-68492: Arbitrary code execution as root in Plesk via the Plesk RESTful API extension" - https://support.plesk.com/hc/en-us/articles/43644058632983
NVD, CVE-2026-68492 (CVSS 4.0 8.7, CWE-426, CISA SSVC 2026-09-24) - https://nvd.nist.gov/vuln/detail/CVE-2026-68492
GitHub Advisory Database, GHSA-9584-9pgw-4m7q - https://github.com/advisories/GHSA-9584-9pgw-4m7q
Plesk, "How to update Plesk Obsidian to the latest build" (plesk installer --select-release-latest --upgrade-installed-components) - https://support.plesk.com/hc/en-us/articles/12377055926551
Plesk, "How to find version of Plesk installed on server" - https://support.plesk.com/hc/en-us/articles/12377716359319
CISA Known Exploited Vulnerabilities catalog JSON, catalogVersion 2026.10.04, dateReleased 2026-10-04T18:52:56.0635Z - https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json