Input Provide detailed security information and a dedicated security mailing list

[Maarten]

When Plesk sends a notification about a “critical security update”, the only information we receive is the short message shown on the changelog. There is no CVE, no affected component, and no severity score.

Looking at the inf3 files in the autoinstall directory, it’s difficult to determine which specific change addresses the reported security issue. The files often cover many package updates at once, making it unclear what the actual security fix is.

For a professional control panel in this price range, this level of detail feels insufficient. Server administrators need this information to:

• Understand the actual risk
• Plan maintenance properly
• Decide how urgent an update really is
• Check whether existing security measures already cover the issue

Most software vendors and control panel providers share basic security details, such as:

• CVE identifiers
• Affected components
• CVSS scores
• A short description of the impact

Possible improvements:

1. Publish a short security bulletin for each critical update
2. Offer a dedicated mailing list for security announcements
3. Add at least CVE references and affected components to the release notes

Right now, administrators either have to apply updates without knowing what’s being fixed, or manually inspect inf3 files. Neither is ideal for managing production systems.

A security mailing list would help all administrators, regardless of how their license was purchased, and would make security notifications easier to follow.
This would be a simple but meaningful improvement.

 

[Sebahat.hadzhi]

Hi, Maarten. Thank you for your input. At this point, I cannot provide any definitive answer. That will be further discussed internally.

 

[Hangover2]

Hi @Sebahat.hadzhi ,

thank you for the feedback. Let me explain why more detailed information about “critical security updates” is not just “nice to have” but a compliance requirement on our side.

We operate infrastructure that falls under the scope of the EU NIS-2 Directive (Directive (EU) 2022/2555). Under Article 23 we must be able to identify, assess, and report significant security incidents, including their severity, impact, likely root cause and indicators of compromise, within strict timelines (early warning within 24 hours, incident notification within 72 hours, and a final report within one month).

If Plesk only provides a generic “critical security update” message without at least:

• CVE identifier(s) or vendor vulnerability ID
• affected component(s) and versions
• a short description of impact (e.g. auth bypass, RCE, privilege escalation, data exposure, etc.)
• a severity rating (CVSS or equivalent)
• information on whether exploitation is known or suspected in the wild

then we cannot:

• Determine whether this constitutes a “significant incident” or “near miss” that must be reported under NIS-2.
• Check whether the issue may already have been used against us (because we do not know what attack pattern, log traces, or indicators of compromise to search for).
• Assess whether existing safeguards (WAF rules, hardening, network segmentation, monitoring, etc.) already mitigated the issue.
• Properly document the incident in our internal NIS-2 records (root cause, mitigation, impact, timeline), as required by our national implementation.

In practice, without this information we are forced to treat every “critical security update” as a potential significant incident, which inflates reporting and makes meaningful risk assessment very difficult.

Concrete requests:

For the specific recent “critical security update”, please provide:

• CVE(s) or internal vulnerability ID(s)
• affected component(s) and versions
• impact description (what an attacker can achieve, in which context)
• whether you are aware of active exploitation or targeted attacks
• the approximate discovery and fix timeline

For future updates, please consider adopting at least the following minimum practice for all security-relevant releases:

• For future updates, please consider adopting at least the following minimum practice for all security-relevant releases:
• CVE / vendor ID
• affected components and version ranges
• CVSS base score or comparable severity rating
• short impact description and any known exploitation status
• publication via a dedicated security page and/or mailing list

Plesk is a central component in our service delivery. As long as NIS-2 obligations apply to us, your level of transparency on security fixes directly affects our legal compliance and our ability to operate the platform safely.

Can you please escalate this internally to the security/product teams and let us know:

• the details for this specific critical update, and
• what the planned process will be for security advisories going forward?

Thank you in advance for a more concrete answer.

 

[Sebahat.hadzhi]

Thank you, @Hangover2 . I think your points are valid and they will also be taken into account.

 

[Kaspar]

Fortunately these type of security patches for Plesk are rare. But that does mean, in my opinion, that when a serious security issue like this does get discovered, details about the security issue are easily to find. Aside from a security mailing list (which I would welcome too), I think there is room for improvement on how this has been communicated on the change log. I really would have liked if the change log notes linked to the knowledge base articles for additional information.

I do understand that it isn't always possible to disclose details at same time the patch get released. In that case a note on the change log stating when (and where) additional information will be disclosed later, would go a long way.