Kurzfassung
Für Plesk liegt mit CVE-2026-64637 eine kritische Schwachstelle vor. Betroffen ist die XML-RPC-API in Versionen vor 18.0.80. Ein authentifizierter Reseller kann darüber eine administrative Sitzung für den Root-Account erhalten. Das ist kein Komfortproblem, sondern ein klarer Privilegienbruch mit hohem Schadenspotenzial.
Wer Plesk produktiv betreibt, sollte die eingesetzte Version jetzt prüfen. Besonders heikel wird es dort, wo Reseller-Accounts sauber getrennt sind, aber mit weitreichenden Rechten arbeiten. Genau diese Trennung hebelt der Fehler aus.
Was ist passiert?
Die Schwachstelle sitzt im Berechtigungsmodell der XML-RPC-Schnittstelle von Plesk. Nach den vorliegenden Angaben kann ein bereits angemeldeter Reseller seine Rechte so ausweiten, dass er eine Sitzung mit Root-Privilegien erhält. Damit verliert die Instanz die saubere Trennung zwischen delegierter Verwaltung und Vollzugriff.
Das Problem betrifft also keine anonyme Angriffsfläche aus dem Internet, sondern eine Authentifizierungsschwelle. Trotzdem bleibt das Risiko hoch. In Hosting-Umgebungen, bei Agenturen oder Providern mit Reseller-Modell reicht ein kompromittiertes Reseller-Konto aus, um die gesamte Instanz zu gefährden.
Technische Details
Die Schwachstelle trägt die Kennung CVE-2026-64637 und ist als kritisch eingestuft. Die Ursache liegt laut Beschreibung in einem fehlerhaften Privilegienmanagement in der XML-RPC-API. Plesk-Versionen vor 18.0.80 sind betroffen.
Der Angriffspfad setzt einen authentifizierten Reseller voraus. Gelingt der Missbrauch, kann der Angreifer eine administrative Sitzung für den Root-Benutzer erlangen. Für Admins heißt das praktisch: Aus einem eingeschränkten Konto wird ein Vollzugriff auf die Verwaltungsoberfläche, mit allen Folgen für Konfiguration, Domains, Hosting-Konten und potenziell verbundene Dienste.
Wer ist betroffen?
Betroffen sind Plesk-Installationen vor Version 18.0.80. Das betrifft vor allem Betreiber von Webhosting- und Server-Umgebungen, die Reseller-Funktionen nutzen. Für Unternehmen im DACH-Raum ist das besonders relevant, wenn Plesk als zentrale Verwaltungsplattform für Kundenprojekte, Agentur-Hosting oder interne Anwendungen läuft.
Ob auch spezielle Editionen, ältere Build-Zweige oder zusätzliche Komponenten betroffen sind, geht aus der vorliegenden Quelle nicht hervor. Ebenfalls offen bleibt, ob bereits aktive Ausnutzung beobachtet wurde. Nach dem aktuellen Stand liegt nur die technische Schwachstellenbeschreibung vor.
Empfohlene Maßnahmen
Die Priorität ist klar: Plesk auf 18.0.80 oder eine neuere Version bringen. Wer die Plattform selbst verwaltet, sollte das zeitnah einplanen und nicht auf den nächsten regulären Wartungstermin schieben. Bei exponierten Systemen gehört das in die Sofortmaßnahmen.
Vor dem Update empfiehlt sich ein kurzer Blick auf die Reseller-Konten. Prüfen Sie, welche Konten aktiv sind, ob sie noch gebraucht werden und ob Rechte unnötig breit vergeben wurden. Nach dem Patch sollten Admins die Sitzungen und Protokolle kontrollieren, um verdächtige Anmeldungen oder ungewöhnliche Verwaltungsaktionen zu erkennen.
Wenn Plesk nur als Nebenkomponente läuft, wird die Lücke oft übersehen. Genau dort entstehen Probleme. Wer mehrere Kundeninstanzen oder getrennte Verantwortlichkeiten auf einem System bündelt, sollte zusätzlich die Trennung der Konten und den Zugriff auf die XML-RPC-API prüfen.
Einschätzung von CyberSecurity-News.de
Die Schwachstelle ist ernst. Nicht wegen eines exotischen Angriffsvektors, sondern weil sie die Schutzgrenze zwischen Reseller und Root aufhebt. Das ist in Hosting-Setups ein harter Einschnitt. Ein einzelnes kompromittiertes Konto kann dann mehr anrichten, als die Berechtigung eigentlich zulässt.
Die Informationslage bleibt allerdings knapp. Die Quelle nennt Schweregrad, Ursache, betroffene Versionsgrenze und den Grundmechanismus, aber keine Details zu Ausnutzung im Feld. Das ist für die Einordnung sauberer als aufgeblähte Panikmeldungen, hilft dem Betriebsteam aber nur begrenzt bei der Risikobewertung. Für Admins zählt deshalb vor allem eines: patchen, Konten prüfen, Logs sichern.
Fazit
CVE-2026-64637 ist für Betreiber von Plesk keine Randnotiz. Wer Versionen vor 18.0.80 einsetzt und Reseller-Zugänge nutzt, hat ein echtes Privilegienproblem im Haus. Die Lücke gehört zügig geschlossen.
Für die meisten Endnutzer ist das Thema irrelevant. Für Hosting-Betreiber, Agenturen und interne Plattformteams dagegen ist es ein klarer Handlungsauftrag.
Quellenangabe
Weiterführende Quelle: NVD-Eintrag zu CVE-2026-64637






