CVE-2026-58046: blind SQLi exposes full panel DB

CISO Take

This CVE is a blind SQL injection in Plesk's XML-RPC API that lets any authenticated low-privileged user read arbitrary data from the Plesk database, up to full compromise of the control panel — CVSS 3.1 rates it 9.9 (network vector, low complexity, low privileges, no user interaction, scope changed). Despite the internal AI-category tag "ml_ui" on this record, nothing in the CVE description, references, or affected-products data ties Plesk to an AI/ML package, model-serving stack, or ML web UI; this looks like a categorization artifact rather than a genuine AI-relevant finding, and should be flagged for scraper/classifier review. There is no EPSS score, no CISA KEV listing, no public exploit, and no Nuclei template on record, so exploitation likelihood cannot be quantified from available signals — treat the 9.9 CVSS as the primary urgency driver given how common low-privilege reseller/customer accounts are on shared Plesk installations. Patch per the vendor advisory (support.plesk.com) as soon as it's available for your Plesk version, and in the meantime audit which low-privilege accounts have XML-RPC API access and review Plesk database logs for anomalous or high-volume XML-RPC query patterns from non-admin accounts.

Sources: NVD support.plesk.com

What is the risk?

CVSS 9.9 (Critical) reflects a severe technical risk: network-reachable, low attack complexity, no user interaction, and full confidentiality/integrity/availability impact with a scope change. However, exploitation requires an authenticated low-privileged account, which meaningfully narrows the exposure to environments where such accounts are provisioned (e.g., shared hosting resellers, customer panel users). No EPSS, KEV, or public-exploit evidence exists to corroborate active or imminent exploitation, so real-world risk should be assessed as high-severity-but-unconfirmed-exploitation rather than an active threat. This is a general infrastructure/hosting-panel vulnerability, not an AI/ML-specific one.

How does the attack unfold?

Initial Access

Adversary obtains or already holds a low-privileged authenticated Plesk account.

Exploitation

Adversary sends crafted requests to the Plesk XML-RPC API to trigger blind SQL injection.

Impact

Adversary incrementally extracts arbitrary data from the Plesk database, leading to full panel compromise.

Initial Access

Adversary obtains or already holds a low-privileged authenticated Plesk account.

Exploitation

Adversary sends crafted requests to the Plesk XML-RPC API to trigger blind SQL injection.

Impact

Adversary incrementally extracts arbitrary data from the Plesk database, leading to full panel compromise.

How severe is it?

CVSS 3.1

9.9 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 29% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I High

A High

What should I do?

1 step

1) Apply the Plesk patch referenced in the vendor advisory (support.plesk.com/hc/en-us/articles/42139500580119) as soon as it is available for your Plesk version. 2) Until patched, restrict or audit XML-RPC API access for low-privileged accounts; disable XML-RPC access for accounts that don't require it. 3) Review Plesk database and web server logs for anomalous XML-RPC requests containing SQL metacharacters or unusual query timing patterns (indicative of blind SQLi probing). 4) Rotate credentials stored in the Plesk database (admin, reseller, and customer account passwords, API tokens) after patching, since blind SQLi could have exfiltrated them prior to remediation. 5) Flag this record internally for AI-category reclassification since it does not appear to be a genuine AI/ML vulnerability.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Extraction Privacy Violation API

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-58046?

This CVE is a blind SQL injection in Plesk's XML-RPC API that lets any authenticated low-privileged user read arbitrary data from the Plesk database, up to full compromise of the control panel — CVSS 3.1 rates it 9.9 (network vector, low complexity, low privileges, no user interaction, scope changed). Despite the internal AI-category tag "ml_ui" on this record, nothing in the CVE description, references, or affected-products data ties Plesk to an AI/ML package, model-serving stack, or ML web UI; this looks like a categorization artifact rather than a genuine AI-relevant finding, and should be flagged for scraper/classifier review. There is no EPSS score, no CISA KEV listing, no public exploit, and no Nuclei template on record, so exploitation likelihood cannot be quantified from available signals — treat the 9.9 CVSS as the primary urgency driver given how common low-privilege reseller/customer accounts are on shared Plesk installations. Patch per the vendor advisory (support.plesk.com) as soon as it's available for your Plesk version, and in the meantime audit which low-privilege accounts have XML-RPC API access and review Plesk database logs for anomalous or high-volume XML-RPC query patterns from non-admin accounts.

Is CVE-2026-58046 actively exploited?

No confirmed active exploitation of CVE-2026-58046 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-58046?

1) Apply the Plesk patch referenced in the vendor advisory (support.plesk.com/hc/en-us/articles/42139500580119) as soon as it is available for your Plesk version. 2) Until patched, restrict or audit XML-RPC API access for low-privileged accounts; disable XML-RPC access for accounts that don't require it. 3) Review Plesk database and web server logs for anomalous XML-RPC requests containing SQL metacharacters or unusual query timing patterns (indicative of blind SQLi probing). 4) Rotate credentials stored in the Plesk database (admin, reseller, and customer account passwords, API tokens) after patching, since blind SQLi could have exfiltrated them prior to remediation. 5) Flag this record internally for AI-category reclassification since it does not appear to be a genuine AI/ML vulnerability.

What is the CVSS score for CVE-2026-58046?

CVE-2026-58046 has a CVSS v3.1 base score of 9.9 (CRITICAL). The EPSS exploitation probability is 0.35%.

What are the technical details?

Original Advisory

Improper neutralization in the Plesk XML-RPC API allows a remote authenticated low-privileged user to perform SQL injection and read arbitrary data from the Plesk database, leading to full compromise of the panel.

Exploitation Scenario

An adversary who has obtained or purchased a low-privileged Plesk account (e.g., a reseller or customer-tier account on a shared hosting provider) sends crafted XML-RPC API requests containing SQL injection payloads. Because input is not properly neutralized, the attacker can perform blind SQL injection to incrementally extract data from the Plesk database — including credentials, configuration, and potentially data belonging to other tenants on the same panel — culminating in full compromise of the hosting panel itself.

Weaknesses (CWE)

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
[Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]

Source: MITRE CWE corpus.