• We value your experience with Plesk during 2025
    Plesk strives to perform even better in 2026. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2025.
    Please take this short survey:

    https://survey.webpros.com/

Critical security issue fixed on 24–25 February 2026 (Plesk Obsidian 18.0.75 Update 1 / 18.0.76 Update 2) — request for vulnerability details

Hangover2

Regular Pleskian
Username:

TITLE


Critical security issue fixed on 24–25 February 2026 (Plesk Obsidian 18.0.75 Update 1 / 18.0.76 Update 2) — request for vulnerability details for NIS2 compliance

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.75 Update 1 and Plesk Obsidian 18.0.76 Update 2

PROBLEM DESCRIPTION

The changelogs for the following releases state that they “address a critical security issue” but provide no actionable information (e.g., CVE/vendor ID, affected components, severity, impact).

For operators subject to the EU NIS2 Directive (Directive (EU) 2022/2555), this lack of information makes it difficult to properly identify, assess, document, and (if applicable) report significant incidents within mandated timelines. In particular, the incident handling and reporting obligations require timely clarity on severity, impact, likely root cause, and potential indicators of compromise.

Additionally, NIS2 places explicit governance and oversight obligations on the management body; inadequate information from a critical vendor security update materially increases compliance risk for affected customers.

STEPS TO REPRODUCE

a) Open the Plesk changelog entries for:
- Plesk Obsidian 18.0.75 Update 1
- Plesk Obsidian 18.0.76 Update 2

b) Observe the generic statement:
- "This update addresses a critical security issue. We strongly recommend that you apply it as soon as possible."

ACTUAL RESULT

No details are provided about the security fix(es), preventing customers from assessing exposure, determining severity, checking for compromise, and preparing compliant documentation/reporting where required.

EXPECTED RESULT

For this specific “critical security issue,” please provide at least the following:

a) CVE identifier(s) and/or Plesk vendor vulnerability ID
b) Affected component(s) and affected versions / configurations
c) Impact description (what an attacker can do, under which prerequisites and context)
d) Severity rating (CVSS score/vector or equivalent)
e) Whether you are aware of active exploitation in the wild or targeted attacks
f) Discovery / disclosure timeline (approximate date of discovery)

If full details cannot be published immediately, a minimum interim advisory (IDs, scope, severity, and mitigation guidance) would already be helpful for compliance and risk management.

ANY ADDITIONAL INFORMATION

Customers subject to NIS2 (e.g., German operators reporting to the BSI, as applicable) may need to assess whether this constitutes a significant incident and document/report accordingly. Without basic vulnerability metadata and scope, it is not possible to perform this assessment reliably.

This is not only an organizational compliance issue: NIS2 places explicit accountability on the management body, and national implementations (e.g., Germany) can create financial risk through:
  • significant administrative fines for breaches of key obligations, and
  • potential personal civil liability exposure for management if required cybersecurity measures and oversight cannot be demonstrated, especially if delayed or insufficient action leads to damages.
For that reason, we urgently require the minimum vulnerability details listed above to perform a defensible risk assessment, determine reporting necessity, and document management decisions in line with NIS2 governance requirements.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Answer the question
 
Thank you for the input, @Hangover2 . I will consult with our team and get back to you with confirmation. Please note that it can take a few days to address that matter. Thank you in advance for your patience in the meantime.
 
While I wait for confirmation about the changelog I can at least provide some details here. The security issues addressed in Plesk Obsidian 18.0.75 Update 1 and Plesk Obsidian 18.0.76 Update 2 are related to security vulnerability discovered in search functionality of Plesk's APS Catalog allowing local privileges escalation (XPath Injection).

If you do not want to update Plesk as of the moment, you can add the following section into the /usr/local/psa/admin/conf/panel.ini file.

Code:
[aps]
enabled = off
 
@Sebahat.hadzhi We now require the requested details without further delay. We no longer have the option to wait, as we are already in an active process with the BSI.

Under NIS2, the incident reporting three-step scheme is triggered once you become aware of a significant security incident (“without undue delay” and then the mandatory deadlines below):
  • Early warning: within 24 hours of becoming aware.
  • Incident notification (detailed report): within 72 hours of becoming aware (updates the early warning and includes an initial assessment incl. severity/impact and, where available, IOCs).
  • Intermediate report: upon request by the CSIRT/competent authority (in Germany: BSI).
  • Final report: no later than 1 month after the 72-hour incident notification.
If the incident is still ongoing when the final report is due, a progress report must be submitted at that time, followed by the final report within 1 month after the incident is handled.
 
While I wait for confirmation about the changelog I can at least provide some details here. The security issues addressed in Plesk Obsidian 18.0.75 Update 1 and Plesk Obsidian 18.0.76 Update 2 are related to security vulnerability discovered in search functionality of Plesk's APS Catalog allowing local privileges escalation (XPath Injection).

If you do not want to update Plesk as of the moment, you can add the following section into the /usr/local/psa/admin/conf/panel.ini file.

Code:
[aps]
enabled = off

Thanks for the clarification. We do not use the APS Catalog on our Plesk servers, so we are not affected by this issue.

This also highlights the underlying problem: Plesk customers need timely and sufficiently detailed security information to assess impact and meet compliance requirements. Due to the lack of details in the changelog, we spent significant time on compliance and incident assessment unnecessarily.
 
Back
Top