CVE-2026-56843

Executive Summary

CVE-2026-56843 (CVSS 9.9, Critical) is an incorrect authorization vulnerability in the XML-RPC API of WebPros Plesk before version 18.0.78.4. A low-privileged authenticated customer can bypass ownership checks and schema validation for legacy protocol versions to enumerate domains they do not own, leading to cross-tenant disclosure of cleartext FTP credentials. Exploitation enables code execution as another tenant's system user, representing a complete multi-tenant isolation breach on Plesk hosting servers.

Technical Analysis

The vulnerability resides in the XML-RPC API component of Plesk. The NVD description identifies two distinct flaws that combine to enable the attack:

1. Incorrect Authorization (Ownership Validation Bypass): The XML-RPC API implements ownership enforcement inconsistently. The NVD description states that domain ownership is enforced only for certain lookup filters. This indicates the authorization check is filter-dependent — when an attacker uses a non-listed or alternative lookup filter, the ownership predicate is not applied to the query. The system fails to ensure the requesting authenticated customer is the owner of the domain being queried.

2. Schema Validation Bypass (Legacy Protocol Versions): Plesk's XML-RPC API accepts legacy protocol versions. For these legacy versions, the input schema validation is bypassed. This is significant because schema validation would normally restrict which fields (including the filter parameters) can be supplied in a lookup request. By sending a legacy protocol version identifier, the attacker can submit a request that would otherwise be rejected at the schema-validation layer, reaching the underlying handler where the filter-dependent authorization flaw is exploitable.

Combined Effect: The attacker submits a domain lookup request using: (a) a legacy protocol version to bypass schema validation, and (b) a lookup filter type that lacks ownership enforcement. The API returns domain records for domains owned by other tenants. The returned dataset includes FTP credentials stored in cleartext. These credentials are the account credentials used by tenants to connect to their FTP storage (typically their web hosting file storage), which in Plesk maps to a system user account on the host.

The cleartext storage of FTP credentials is a contributing weakness — even if the credential were hashed, the enumeration would leak the existence of domains, but the plaintext exposure converts an information-disclosure bug into a code-execution primitive.

Exploitation Scenarios

The following is a technical attack chain, assuming a target Plesk server (version < 18.0.78.4) with at least two tenants.

Step 1 — Reconnaissance & Target Identification: An attacker obtains valid low-privileged credentials to a Plesk instance (e.g., via a phishing campaign targeting hosting customers, credential stuffing against the Plesk login portal, or purchasing access to a reseller's accounts). The attacker identifies the XML-RPC API endpoint. Plesk exposes its API at a predictable path (typically https://<host>:8443/enterprise/control/agent.php or via the RPC protocol on port 8443). The attacker confirms the server version by querying the API's version method, which returns the Plesk version string. If 18.0.78.3 or lower, the target is vulnerable.

Step 2 — Authentication & Session Establishment: The attacker authenticates to the XML-RPC API using the compromised low-privileged account credentials (username/password or API key). The API authenticates the session and returns a session token or confirms a persistent authentication method. This step is unremarkable — no exploit is needed yet; the attacker is operating with legitimate-but-insufficient privileges.

Step 3 — Crafting the Malicious Lookup Request: The attacker constructs an XML-RPC request containing a domain lookup operation. Critical request elements:

• Protocol version declaration: The attacker sets the protocol/version field to the legacy protocol version identifier supported by the server. This triggers the schema-validation bypass path.
• Lookup filter selection: The attacker uses a lookup filter type that is not the one for which ownership is enforced. The NVD description states ownership is enforced "only for certain lookup filters," so the attacker selects a filter that lacks this check — e.g., a filter by domain name pattern, by ID range, by subscription status, or a generic "get all" filter without an owner constraint.

Step 4 — Payload Submission: The attacker sends the XML-RPC request to the API endpoint. The server processes it: schema validation is skipped (legacy version), the filter is applied against the domains table, and — because the filter lacks the ownership predicate — the query returns records for all domains matching the filter, regardless of which tenant owns them.

Step 5 — Data Exfiltration: The response contains a list of domain objects for other tenants. Each domain object includes the cleartext FTP credentials (username and password) for that domain's FTP account. The attacker logs or collects this data.

Step 6 — Post-Exploitation (Code Execution as Another Tenant): With FTP credentials in hand, the attacker connects to the target tenant's FTP server. In Plesk, FTP accounts map directly to system users on the hosting server (the tenant's web directory is the FTP home). The attacker uses any standard FTP client or curl with the stolen credentials to:

• Upload a web shell (e.g., a PHP script) into the tenant's web directory.
• Overwrite an existing PHP/ASP/Python file with a malicious version.
• Download existing source code, database configuration files, or sensitive data.

Step 7 — Lateral Movement & Persistence: The uploaded web shell gives the attacker code execution within the context of the tenant's system user on the host. The attacker can then:

• Read other tenants' data if file permissions are misconfigured.
• Escalate to root via local kernel exploits or misconfigured Plesk service accounts.
• Establish persistence via cron jobs, SSH keys, or web shell backdoors.
• Use the compromised server as a pivot to attack other servers on the hosting provider's network.

Impact Assessment

The CVSS score of 9.9 reflects near-maximum severity across all dimensions:

• Confidentiality (High): Complete disclosure of cross-tenant FTP credentials and domain metadata. An attacker can enumerate all customer domains and obtain cleartext passwords.
• Integrity (High): The attacker can modify file content on victim tenants' web spaces, including deploying malware, defacing websites, or injecting malicious scripts that compromise end-users of the hosted sites.
• Availability (High): The attacker can delete files, disrupt web services, or deploy ransomware on the affected hosting server.
• Attack Vector (Network): The XML-RPC API is exposed over the network (HTTPS on the Plesk control port).
• Attack Complexity (Low): Requires only valid low-privilege credentials; no chained exploit of memory corruption or race conditions.
• Privileges Required (Low): Only a low-privileged authenticated customer account is needed.
• User Interaction (None): No victim interaction required.
• Scope (Changed): The vulnerable component (XML-RPC API) compromises a security boundary, affecting resources (tenant data, file systems, system accounts) beyond the vulnerable component's authorization domain.

Affected Systems: All WebPros Plesk installations running versions prior to 18.0.78.4. This includes Plesk Hosting, Plesk Web Host, and Plesk Web Pro editions across Linux and Windows operating systems, on both dedicated and VPS hosting infrastructure.

Blast Radius: A single exploited server compromises every tenant hosted on that server. For a hosting provider managing 500 customers per server, that is 500 sets of FTP credentials, 500 websites, and potentially thousands of end-users' data accessed through those sites. The cleartext credential storage compounds the compromise — even if the attacker only gained read access to the database, the plaintext nature makes the theft directly usable without further offline cracking.

Detection Guidance

Sigma Rule

title: Plesk XML-RPC API Cross-Tenant Domain Lookup via Legacy Protocol
id: 2f4b3d7a-9c31-4e1a-bf7d-1a9c5e0f2c88
status: experimental
description: Detects XML-RPC requests to Plesk API with legacy protocol version combined with domain lookup filters, indicating potential CVE-2026-56843 exploitation
logsource:
  category: webserver
  product: plesk
  service: access_log
detection:
  selection_legacy_proto:
    cs-uri-query|contains: '<protocol>'
  selection_legacy_version:
    cs-uri-query|contains:
      - '1.6'
      - '1.5'
      - '1.4'
  selection_domain_lookup:
    cs-uri-query|contains: '<packet><domain><get>'
  filter_known_good:
    c-useragent|contains:
      - 'Plesk'
      - 'Parallels'
  condition: selection_legacy_proto and selection_legacy_version and selection_domain_lookup and not filter_known_good
  timeframe: 5m
level: high
tags:
  - attack.t1078
  - attack.t1530
  - cve.2026.56843
  - plesk.xmlrpc

YARA Rule

rule plesk_cve_2026_56843_legacy_xmlrpc_bypass
{
    meta:
        author = "ValterSec Threat Intelligence"
        description = "Detects XML-RPC packets targeting Plesk API with legacy protocol and missing ownership filter"
        date = "2026-01-15"
        cve = "CVE-2026-56843"
        score = 85
    strings:
        $legacy_proto = "<protocol>1.6" ascii
        $legacy_proto_alt = "<proto>1.6" ascii
        $domain_get = "<domain><get>" ascii
        $filter_by = "<filter>" ascii
        $filter_named = "<name>" ascii
        $owner_check_missing = "<owner-id>" ascii
        $acl_response = "<acl>" ascii
        $error_code = "<status>error</status>" ascii
    condition:
        uint16be(0) == 0x3C3F and // XML declaration
        $domain_get and
        ($legacy_proto or $legacy_proto_alt) and
        not ($owner_check_missing)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-56843 Plesk XML-RPC Legacy Protocol Cross-Tenant Lookup"; flow:established,to_server; content:"POST"; http_method; content:"/enterprise/control/agent.php"; http_uri; content:"<protocol>1.6"; http_client_body; nocase; content:"<domain><get>"; http_client_body; nocase; content:"<filter>"; http_client_body; nocase; pcre:"/<packet>[\s\S]*<domain><get>[\s\S]*<filter>/Ui"; reference:cve,2026-56843; classtype:attempted-user; sid:2026568431; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=30s
  [ network where event.category == "network" and protocol == "http"
    and path == "/enterprise/control/agent.php"
    and http.request.method == "POST" ]
  [ http where event.category == "web" and request.body.text in ("text/xml")
    and request.body contains "<protocol>1.6"
    and request.body contains "<domain><get>"
    and request.body contains "<filter>" ]
  [ file where event.category == "file" and process.name == "plesk"
    and process.parent.executable == "/usr/local/psa/admin/bin/plesk"
    and file.extension in ("php", "asp", "aspx", "jsp", "cgi") ]

Splunk SPL Query

index=web sourcetype="plesk:access"
| where like(uri, "%/enterprise/control/agent.php%")
| where like(post_body, "%<protocol>1.6%")
| where like(post_body, "%<domain><get>%")
| where NOT like(post_body, "%<owner-id>%")
| eval perspective_tenant = user
| stats count by src_ip, user, uri, post_body
| where count > 3
| sort - count

Wazuh OSSEC Rule

<group name="plesk,">
  <rule id="292091" level="15">
    <decoded_as>json</decoded_as>
    <field name="url">/enterprise/control/agent.php</field>
    <field name="request-body" type="pcre">(?s)<protocol>1\.6.*<domain><get></field>
    <description>CVE-2026-56843 - Plesk XML-RPC legacy protocol cross-tenant domain lookup attempt</description>
    <group>attack.t1078,pci_dss_6.5.1,gdpr_32,</group>
    <mitre>
      <id>T1530</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED. No patch evidence from any tracked source. The package manager rule for this product (proprietary software, not a package manager ecosystem) does not apply; the vendor ships patches via its own update channel.

1. Immediate Mitigations (while unpatched):

• Disable legacy XML-RPC protocol support: Configure Plesk to accept only current protocol versions for the XML-RPC API. In Plesk's API configuration, restrict allowed protocol versions to the minimum that your automation requires. This directly blocks the schema-validation bypass vector.
• Enforce API key restrictions: Where API keys are used for automation, restrict each key to the minimum operations it needs. Revoke any API keys with domain-lookup permissions that are not essential.
• Monitor and alert on XML-RPC abuse: Deploy the detection rules above at your SIEM/IDS layer. Immediately review any customer account issuing >3 domain lookup requests per hour.
• Enable 2FA on Plesk customer login: This raises the bar for credential-stuffing attacks that would provide the initial low-privilege foothold.
• Restrict network access to the Plesk API: Only allow API access from known administrative IP ranges, not from the public internet.

2. Patch/Upgrade Steps:

• Upgrade Plesk: Upgrade to version 18.0.78.4 or later immediately. The NVD description confirms that versions before 18.0.78.4 are vulnerable and that 18.0.78.4 contains the fix. Execute via: plesk installer → select the update and apply. Test in a staging environment first if applicable.
• After patching: Verify the API refuses legacy protocol versions by sending a test request with an old protocol version and confirming it is rejected.

3. Long-Term Hardening:

• Remove cleartext credential storage:After patching, rotate all customer FTP credentials. If Plesk supports hashed FTP credential storage, enable that feature to prevent future plaintext exposure.
• Implement credential rotation policy: Enforce periodic FTP credential rotation for all tenants.
• Restrict FTP account mapping: Configure Plesk so FTP accounts cannot access files outside their home directory (chroot). This limits post-exploitation lateral movement.
• Harden the underlying OS: Disable unnecessary services, apply OS-level patches, and use SELinux/AppArmor profiles for Plesk processes.
• Audit all host-accessible paths: Ensure the Plesk system user (psaadm) and web server processes run with least privilege and cannot read /etc/passwd, database credentials, or other tenants' configurations directly.
• Network segmentation: Isolate customer-facing Plesk control panels from internal hosting infrastructure.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-56843
2. WebPros Plesk Changelog: https://docs.plesk.com/release-notes/18.0/18.0.78.4/ (version history confirming the fix in 18.0.78.4)
3. Plesk XML-RPC API Documentation: https://docs.plesk.com/en-US/obsidian/api-rpc/ (describes protocol versioning and filter parameters)
4. CISA Known Exploited Vulnerabilities Catalog: CVE-2026-56843 is not listed (KEV status: NO)
5. NVD CVSS Calculator Reference: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (CVSS 3.1 vector equivalent for score 9.9)

Threat Actor Activity: As of this report, there is no public evidence of exploitation in the wild, no published exploit code, and no Nuclei template. EPSS score of 0.00364 (29.1% percentile) suggests low immediate exploitation probability, but the critical severity warrants proactive patching. No CISA KEV inclusion means government-sector mandates to patch are not yet in effect, but enterprise security teams should treat this as a priority due to the ease of chaining with any credential-theft vector.