Sicherheitsupdates ohne Changelog: dein Login ändert sich

In den drei Wochen zwischen dem 1. und 20. Mai haben wir elf Sicherheitsupdates auf unsere Server ausgerollt. Kernel, Apache, Exim, cPanel, WHMCS, in dichter Folge und teils mehrere an einem Tag. Das war kein Ausreißer, sondern der neue Normalzustand. Und er hat einen Grund, über den die Branche gerade offen spricht: Der klassische Changelog, in dem ein Hersteller sauber auflistet, welches Update welche Sicherheitslücke schließt, verschwindet.

Dieser Beitrag erklärt, was dahintersteckt, welche Ereignisse hinter den vielen Update-Meldungen der letzten Wochen standen und welche zwei Konsequenzen wir daraus gezogen haben. Eine davon betrifft direkt deinen Zugang zu cPanel, Plesk und Roundcube.

Warum der Changelog stirbt

Früher war der Ablauf berechenbar. Ein Hersteller veröffentlichte eine neue Version, im Changelog stand „behebt eine Sicherheitslücke in Komponente X”, und Administratoren konnten anhand dieser Markierung entscheiden, wie dringend sie aktualisieren. Genau diese Markierung wird jetzt bewusst weggelassen.

Der Grund ist die Geschwindigkeit der Angreifer. Sobald ein Hersteller ein Update als sicherheitsrelevant kennzeichnet oder eine CVE-Nummer veröffentlicht, beginnt auf der Gegenseite die Arbeit: Der Patch wird mit der Vorgängerversion verglichen, die geschlossene Lücke daraus rekonstruiert und ein funktionierender n-day-Exploit Angriff auf eine bereits öffentliche, meist schon gepatchte Lücke. Gefährlich für jeden, der zu spät aktualisiert. gebaut. Aus dem öffentlichen Sicherheitshinweis wird ein Bauplan für den Angriff. CloudLinux beschreibt diesen Wandel als Abkehr vom sichtbaren Changelog: Hersteller verstecken sicherheitsrelevante Fixes bewusst im normalen Release-Rauschen, um den Angreifern den Vorsprung zu nehmen.

Für dich als Betreiber dreht sich damit eine Grundannahme um. Ein fehlendes Security-Label am Update bedeutet nicht mehr, dass kein Sicherheitsproblem dahintersteckt. Verschärft wird das durch Werkzeuge, die beide Seiten nutzen: Mit aktueller KI-Unterstützung finden Angreifer wie Verteidiger Schwachstellen schneller als je zuvor, und das Zeitfenster zwischen Veröffentlichung und einsatzbereitem Exploit schrumpft auf Stunden. Das ist kein vorübergehender Effekt, sondern die dauerhafte neue Ausgangslage.

Drei Wochen, in denen es laut wurde

Im Mai haben wir dieses Muster in Reinform erlebt. Was früher die Ausnahme war, eine ernste lokale Rechteausweitung im Linux-Kernel etwa einmal im Jahr, kam plötzlich im Wochentakt.

Den Anfang machte „Copy-Fail” (CVE-2026-31431), eine Kernel-Lücke, für die wir Updates und Neustarts eingeplant haben. Kurz darauf folgten die Kernel-Schwachstellen Dirty Frag und „Fragnesia”, bei denen wir die Angriffsfläche per Mitigation entschärft haben, bevor der offizielle Kernel-Patch überhaupt verfügbar war. Dazwischen kamen mehrere cPanel-Sicherheitsupdates, ein vorgezogener WHMCS-Patch und zuletzt „PinTheft” (CVE-2026-43494).

Same-Day-Patching ist bei uns Standard, kein Notfallmodus. Genau deshalb war diese Welle für uns Arbeit, aber kein Drama: Die Prozesse, um ohne langes Changelog-Studium schnell zu reagieren, hatten wir schon.

Konsequenz 1: Wir stufen Updates nicht mehr nach Changelog ein

Wenn ein Hersteller nicht mehr zuverlässig sagt, welches Update kritisch ist, dann ist die einzig vernünftige Annahme: Jedes Update kann kritisch sein. Wir lesen Changelogs nicht mehr, um zu entscheiden, ob sich ein Update lohnt. Wir spielen es ein und prüfen es danach. Bei sicherheitsrelevanten Paketen passiert das am Tag des Vendor-Releases, bei Kernel-Lücken oft schon vorher per Mitigation.

Ehrlich bleibt dabei der Reboot. Manche Kernel-Updates brauchen einen Neustart, und den kündigen wir als Wartungsfenster an, statt so zu tun, als wäre er unsichtbar. Lieber ein angekündigter Neustart als ein Server, der mit einer bekannten Lücke weiterläuft.

Konsequenz 2: cPanel, Plesk und Roundcube nur noch nach Kundencenter-Login

Die zweite Konsequenz betrifft deinen Zugang. Die Login-Seite eines Hosting-Panels oder eines Webmailers ist eines der am häufigsten angegriffenen Ziele im ganzen Stack. Sie ist öffentlich erreichbar, jeder weiß, wie sie aussieht, und sie wird rund um die Uhr mit gestohlenen Zugangsdaten und Brute-Force-Versuchen bombardiert. Mit der neuen Lage kommen Exploits gegen den Login-Code der Software selbst dazu.

Deshalb haben wir die betroffenen Web-Oberflächen hinter das Kundencenter gelegt. Der Weg in dein cPanel, Plesk oder Roundcube-Webmail führt ab sofort über einen angemeldeten Kundencenter-Login: Du meldest dich einmal zentral an und springst von dort in die jeweilige Oberfläche. Die offene, direkt aus dem Internet erreichbare Login-Seite ist nicht mehr die Vordertür.

Das bringt drei Dinge auf einmal. Die exponierte Panel-Anmeldung fällt als primäres Angriffsziel weg. Die Authentifizierung läuft über einen einzigen, gehärteten Login statt über je eine Anmeldemaske pro Server. Und ein geleaktes Panel-Passwort allein reicht nicht mehr, weil davor die Kundencenter-Anmeldung steht, die du mit Zwei-Faktor-Authentifizierung absichern kannst. Der Preis ist ein zusätzlicher Schritt beim Login. Den halten wir für vertretbar.

Was sich für dich ändert

Konkret meldest du dich künftig zuerst im Kundencenter an und öffnest cPanel, Plesk oder dein Roundcube-Webmail von dort aus. Alte Lesezeichen, die direkt auf eine dieser Login-Seiten zeigen, solltest du durch den Weg übers Kundencenter ersetzen.

Betroffen ist der Browser-Login zu cPanel, Plesk und Roundcube. Wie du dich per FTP, SSH oder mit einem E-Mail-Programm über IMAP und SMTP anmeldest, ändert sich nicht. Falls du Automatisierungen betreibst, die sich bisher direkt an einer dieser Oberflächen angemeldet haben, melde dich kurz bei uns, dann finden wir den passenden Weg. Und wenn du im Kundencenter noch keine Zwei-Faktor-Authentifizierung aktiv hast: Jetzt ist der richtige Moment.

Wie tief unsere Absicherung darunter ansetzt, von der vorgelagerten Hardware-Firewall mit IPS/IDS bis zur Account-Isolation, zeigen wir auf der Seite zu unseren Servern.

Kurz gesagt

Der Changelog wird leiser, unsere Updates werden es nicht. Wir behandeln jedes Update als sicherheitsrelevant und haben den Login zu cPanel, Plesk und Roundcube abgesichert, weil die Login-Seite das ist, was Angreifer zuerst sehen. Fragen zur Umstellung beantwortet dir unser Team direkt über ein Ticket im Kundencenter oder das Kontaktformular.