Lücke, Status, Maßnahme.

Seit dem 4. September werden Magento-Shops über eine Lücke angegriffen, für die es noch keinen Patch gibt. Sansec hat sie am 5. September unter dem Namen StyleSmuggler veröffentlicht, Adobe hat bislang weder Advisory noch CVE noch Fix nachgelegt. Betroffen sind alle aktuellen Versionen, auch vollständig gepatchte. Auf Accounts mit unserem 360°-Rundumschutz wurden die Angriffsversuche blockiert, bevor sie Magento erreicht haben. Für alle anderen Magento-Accounts empfehlen wir, den Schutz jetzt freischalten zu lassen.

Was ist passiert?

StyleSmuggler ist eine RCE-Lücke Remote Code Execution: ein Angreifer bringt den Server dazu, fremden Code auszuführen, ohne selbst Zugang zu haben. im Template-System von Magento. Der Angreifer braucht keinen Login. Er hinterlegt zuerst Schadcode in einer Datei, die Magento im normalen Betrieb selbst schreibt, und löst dann eine fehlgeschlagene Zahlung aus. Beim Erzeugen der Benachrichtigungs-Mail dazu führt Magento den Code aus. Der Angriff funktioniert auch, wenn die Mail nie ankommt. Danach läuft ein getarnter Hintergrundprozess, der auf Befehle von außen wartet.

Was wir getan haben

Der 360°-Rundumschutz hat die Angriffsmuster auf den geschützten Accounts abgefangen, und zwar schon vor der Veröffentlichung durch Sansec. Zusätzlich haben wir alle bekannten Angreifer-Adressen auf unseren Servern gesperrt. Das ist eine Momentaufnahme und kein Schutz, die Angreifer wechseln ihre Adressen laufend. Den Adobe-Patch, sobald er erscheint, und den Stand der Angriffe halten wir im Blick.

Was du tun musst

Wenn dein Magento-Account den Rundumschutz noch nicht hat: freischalten lassen, das geht ohne Änderung an deinem Shop. Prüfe außerdem, ob dein Shop bereits betroffen ist. Die Prüfbefehle, die Indikatoren und die möglichen Zwischenlösungen im Magento-Code stehen im Blog-Beitrag zu StyleSmuggler. Sobald Adobe einen offiziellen Patch liefert, gehört er in deinen Shop.

Die technische Analyse mit allen Indikatoren steht in der Sansec-Quelle unter diesem Eintrag.

Vier Wochen nach dem letzten Sicherheits-Update hat der Hersteller der ConfigServer Firewall eine weitere Lücke geschlossen, diesmal im Messenger-Dienst Optionale CSF-Funktion, die gesperrten Besuchern statt einer toten Verbindung eine Hinweis-Seite anzeigt. . Über ihn hätte ein Angreifer ohne Anmeldung Code ausführen und die höchste Rechtestufe auf dem Server erlangen können. Betroffen sind alle Fassungen bis einschließlich 16.30-1. Wir haben die Server am 3. September auf 16.31 gebracht. Der Messenger-Dienst war auf unseren Servern nie eingeschaltet, die Lücke war bei uns zu keinem Zeitpunkt ausnutzbar.

Was ist passiert?

Der Messenger-Dienst von CSF zeigt Besuchern, die von der Firewall gesperrt wurden, eine Hinweis-Seite statt einer toten Verbindung. Ein Fehler in dieser Komponente erlaubte es, ihr Befehle unterzuschieben, die mit den Rechten der Firewall ausgeführt werden, also mit Root-Rechten Die höchste Rechtestufe auf einem Linux-System. Wer sie hat, kontrolliert den gesamten Server. . Bei einer Standard-Installation ist der Dienst abgeschaltet; angreifbar sind nur Server, auf denen er bewusst aktiviert wurde.

Was wir getan haben

Wir haben zuerst auf jedem Server ausgelesen, ob der Messenger-Dienst aktiv ist. Er war es nirgends. Anschließend haben wir die Firewall am 3. September auf allen betroffenen Servern in Wellen auf 16.31 aktualisiert und den Stand erneut ausgelesen.

Was du tun musst

Nichts. Deine Firewall-Freigaben, Ports und Sperrlisten bleiben unverändert. Wenn du CSF auf einem eigenen Server außerhalb unserer Plattform betreibst und den Messenger-Dienst nutzt: sofort auf 16.31 aktualisieren oder den Dienst bis dahin abschalten.

Die Hersteller-Meldung mit den betroffenen Fassungen steht in der Quelle unter diesem Eintrag.

BigBlueButton hat am 2. September ein Advisory mit der höchsten Kritikalitätsstufe veröffentlicht: Über die Schnittstelle zum Beitreten von Konferenzen ließ sich die Zugangsprüfung umgehen. Ein Angreifer konnte damit ohne gültigen Zugang und an der Warteschleife für Gäste vorbei als Moderator in laufende Meetings gelangen. Der Fix steckt in der Version, die seit dem Update vom 24. August auf allen Managed-BBB-Servern läuft. Wir haben das am 2. September auf jedem Server nachgeprüft.

Was ist passiert?

Jeder Beitritt zu einer BigBlueButton-Konferenz wird über eine Prüfsumme Prüfwert aus den Anfrage-Daten und dem geheimen API-Schlüssel des Servers. Nur wer den Schlüssel kennt, kann gültige Anfragen erzeugen. abgesichert, die nur das angebundene Frontend erzeugen kann, etwa Greenlight oder Moodle. Durch einen Fehler in der Verarbeitung der Anfrage ließ sich diese Prüfung mit zusätzlichen Parametern aushebeln. Der Fehler wurde bereits im Juni mit Version 3.0.29 behoben, das Advisory dazu erschien erst jetzt. Einen Behelf gibt es nicht, nur das Update.

Was wir getan haben

Alle Managed-BigBlueButton-Server laufen seit dem Sicherheits-Update vom 24. August auf 3.0.35 und enthalten den Fix damit schon. Wir haben das am 2. September trotzdem auf jedem Server einzeln geprüft: Versionsstand ausgelesen und auf einem Testsystem nachgestellt, dass die präparierte Anfrage nicht mehr als Beitritt verarbeitet wird.

Was du tun musst

Nichts. Deine Räume, Aufzeichnungen und Einstellungen sind unverändert. Wenn du einen eigenen BigBlueButton-Server außerhalb unserer Plattform betreibst: auf 3.0.29 oder neuer aktualisieren, es gibt keinen anderen Schutz.

Die technischen Details stehen im BigBlueButton-Advisory unter diesem Eintrag.

Plesk hat am 2. September das dritte als „kritisch” eingestufte Sicherheits-Update innerhalb von zehn Tagen veröffentlicht, wie schon bei den beiden vorherigen zunächst ohne Angabe, worum es geht. Bei den Updates vom 24. und 27. August stellte sich später heraus, dass Kunden mit Shell-Zugang volle Administrator-Rechte auf dem Server erlangen konnten. Wir haben alle Plesk-Server am 2. September aktualisiert, rund anderthalb Stunden nachdem das Update verfügbar war.

Was ist passiert?

Was das Update genau schließt, hat Plesk bislang nicht veröffentlicht. Die Ankündigung ist wortgleich mit den beiden vorherigen kritischen Updates, deshalb behandeln wir es genauso: als Lücke, die im schlimmsten Fall aus einem normalen Hosting-Konto heraus ausnutzbar ist. Neben dem Panel selbst erneuert das Update auch die von Plesk mitgelieferten Mail-Dienste Postfix und Dovecot.

Was wir getan haben

Das Update lief zuerst auf einem Testsystem mit Funktionsprüfung von Panel, Mail-Versand und Mail-Abruf, danach in Wellen auf allen Plesk-Servern. Anschließend haben wir auf jedem Server den Versionsstand ausgelesen und die Erreichbarkeit des Panels geprüft. Eine vorsorgliche Sperre des Panels wie am 27. August war diesmal nicht nötig, weil das Update schnell genug flächendeckend eingespielt war.

Was du tun musst

Nichts. Deine Zugänge, Websites, Postfächer und Einstellungen sind unverändert. Wenn du einen eigenen Plesk-Server außerhalb unserer Plattform betreibst: Die Plesk-Oberfläche zeigt solche Zwischen-Updates nicht als eigene Version an. Ob es eingespielt ist, siehst du auf der Kommandozeile mit plesk version, das Ergebnis muss 18.0.80 mit Update 6 oder höher sein.

Die Änderungsliste von Plesk steht in der Quelle unter diesem Eintrag.

Ubuntu hat am 1. September ein Update für libevent veröffentlicht, eine Bibliothek, mit der Server-Dienste Netzwerkverbindungen abwickeln. Fünf Lücken werden damit geschlossen. Die schwerste erlaubt es, einen betroffenen Dienst aus dem Internet zum Absturz zu bringen oder im ungünstigsten Fall fremden Code auszuführen. Wir haben das Update am 2. September auf allen Ubuntu-Servern eingespielt und die betroffenen Dienste ohne Neustart der Server durchgestartet.

Was ist passiert?

Betroffen ist nicht jeder Dienst, sondern nur Software, die libevent tatsächlich einbindet. Bei uns sind das vor allem der TURN-Dienst Vermittelt Audio- und Videoströme zwischen Teilnehmern, wenn keine direkte Verbindung möglich ist, etwa hinter Firmen-Firewalls. für Videokonferenzen auf den BigBlueButton- und Nextcloud-Servern, der aus dem Internet erreichbar ist, und die MySQL-Datenbank der Nextcloud-Server, die nur lokal angesprochen wird. Neben dem Absturz-Szenario lassen sich über die Lücken HTTP-Anfragen so präparieren, dass ein Dienst sie anders liest als vorgesehen und Sicherheitsprüfungen umgeht.

Was wir getan haben

Wie beim OpenSSL-Update Ende August reicht das Paket allein nicht: Ein laufender Dienst arbeitet weiter mit der alten Bibliothek im Speicher, bis er neu gestartet wird. Wir haben deshalb am 2. September auf allen Ubuntu-Servern das Paket aktualisiert und jeden Dienst durchgestartet, der die alte Version noch geladen hatte, zuerst auf einem Testsystem, dann auf den Managed-BigBlueButton-Servern, danach auf den Managed-Nextcloud- und übrigen Servern. Auf jedem Server haben wir anschließend geprüft, dass kein Prozess mehr mit der alten Bibliothek läuft.

Was du tun musst

Nichts. Der Neustart des TURN-Dienstes dauerte Sekunden; Teilnehmer in laufenden Konferenzen wurden dabei kurz neu verbunden. Wenn du eigene Ubuntu-Maschinen außerhalb unserer Plattform betreust: Nach dem libevent-Update die Dienste neu starten, die die Bibliothek nutzen, nicht nur das Paket aktualisieren.

Welche Lücke was genau betrifft, steht in der Ubuntu-Meldung unter diesem Eintrag.

Anfang August wurde eine Lücke im Linux-Kernel veröffentlicht, die seit 2007 in praktisch jedem Kernel steckt. Wer auf einem betroffenen Server ein normales Benutzerkonto hat, kann sich darüber volle Administrator-Rechte verschaffen. Ein fertiger Exploit ist seit dem 7. August öffentlich. Kernel-Updates der Hersteller liegen noch nicht für alle Systeme vor. Unsere betroffenen Server sind seit dem 1. September dagegen abgesichert, im laufenden Betrieb und ohne Unterbrechung.

Was ist passiert?

Die Lücke steckt im Kernel-Modul für SCTP Netzwerk-Protokoll neben TCP und UDP, vor allem in Telefonie- und Signalisierungs-Systemen im Einsatz. Auf Webservern praktisch ungenutzt. , einem Netzwerk-Protokoll, das auf Webservern so gut wie nie gebraucht wird. Beim Entfernen einer Adresse aus einer bestehenden Verbindung gibt der Kernel Speicher frei, den er anschließend weiter benutzt. Daraus lässt sich Schritt für Schritt eine Übernahme von Root-Rechten Die höchste Rechtestufe auf einem Linux-System. Wer sie hat, kontrolliert den gesamten Server. bauen. Aus dem Internet ist die Lücke nicht direkt ausnutzbar. Auf einem Hosting-Server reicht aber jede gehackte Website, weil deren PHP-Prozess als lokaler Benutzer läuft. Angreifbar ist ein Server nur, wenn sich das SCTP-Modul laden lässt.

Was wir getan haben

Unsere Server brauchen SCTP nicht. Wir haben deshalb am 1. September auf allen betroffenen Servern das Modul entladen und gegen erneutes Laden gesperrt, vorab auf Testsystemen aus jeder Server-Gruppe geprüft, dann flächendeckend. Auf jedem Server haben wir anschließend kontrolliert, dass sich das Modul nicht mehr laden lässt und ein Verbindungsaufbau über SCTP als normaler Benutzer fehlschlägt. Sobald die Kernel-Updates der Hersteller da sind, spielen wir sie regulär ein.

Was du tun musst

Nichts. Deine Anwendungen laufen unverändert weiter. Wenn du eigene Linux-Maschinen außerhalb unserer Plattform betreust: Wird dort kein SCTP gebraucht, das Modul sperren, wie im CloudLinux-Beitrag beschrieben. Die Einstellung, die SCTP-Adressänderungen abschaltet, schützt nicht, der Exploit aktiviert sie selbst wieder.

Wie die Lücke technisch funktioniert und welche Systeme betroffen sind, steht in der Quelle unter diesem Eintrag.

cPanel hat am 27. August eine Lücke in der Domain-Verwaltung gemeldet: Ein angemeldeter Kunde, der Parked- oder Addon-Domains anlegen darf, konnte darüber beliebige Dateien auf dem Server erzeugen und so Befehle mit Administrator-Rechten ausführen. Betroffen sind alle unterstützten cPanel-Versionen, einen Workaround nennt der Hersteller nicht. Wir haben alle cPanel-Server am 27. August auf die gepatchten Versionen gebracht.

Was ist passiert?

Das Anlegen zusätzlicher Domains gehört zu den Standardfunktionen jedes cPanel-Kontos. Durch einen Fehler in dieser Funktion konnte ein Kunde Dateien an Stellen ablegen, die ihm nicht gehören, und darüber Root-Rechte Die höchste Rechtestufe auf einem Linux-System. Wer sie hat, kontrolliert den gesamten Server. erlangen: Zugriff auf den gesamten Server samt aller anderen Konten, Websites und Datenbanken darauf. Voraussetzung ist ein bestehendes cPanel-Konto; aus dem Internet ist die Lücke ohne Anmeldung nicht ausnutzbar.

Was wir getan haben

Wir haben am 27. August den Versionsstand aller cPanel-Server erhoben, statt uns auf die automatische Aktualisierung zu verlassen. Der größte Teil hatte das Update über den cPanel-eigenen Mechanismus bereits bekommen, den Rest haben wir nachgezogen und anschließend jeden Server einzeln gegen die gepatchten Versionsnummern geprüft. Auf einzelnen Servern, deren Betriebssystem zu alt für die aktuelle cPanel-Version ist, haben wir stattdessen das Anlegen neuer Parked- und Addon-Domains abgeschaltet, bis diese Server ausgetauscht sind; bestehende Domains laufen dort unverändert.

Was du tun musst

Nichts. Deine Websites, Domains und Zugänge sind unverändert. Solltest du auf einem der genannten älteren Server keine neue Domain anlegen können, melde dich beim Support, wir kümmern uns darum.

Die technischen Details stehen im cPanel-Advisory unter diesem Eintrag.

Zum zweiten Mal innerhalb weniger Tage hat Plesk ein als „kritisch” eingestuftes Update veröffentlicht, diesmal am Morgen des 27. August, wieder zunächst ohne Details. Am Nachmittag folgte die Erklärung: Ein Kunde oder Reseller mit Shell-Zugang konnte sich volle Administrator-Rechte auf dem Server verschaffen. Wir haben alle Plesk-Server am 27. August aktualisiert, noch bevor die Details öffentlich waren.

Was ist passiert?

Wer in Plesk für sein Hosting-Konto Shell-Zugang Zugang zur Kommandozeile des Servers, etwa per SSH. In Plesk pro Konto ein- oder ausschaltbar. hat oder ihn sich als Reseller selbst einräumen darf, konnte über einen Fehler in Plesk aus diesem eingeschränkten Zugang Root-Rechte Die höchste Rechtestufe auf einem Linux-System. Wer sie hat, kontrolliert den gesamten Server. machen. Betroffen sind fast alle Plesk-Versionen der letzten Jahre auf Linux. Aus dem Internet ist die Lücke ohne ein bestehendes Plesk-Konto nicht ausnutzbar.

Was wir getan haben

Weil Plesk das Update als kritisch ankündigte, ohne zu sagen, worum es geht, haben wir am Morgen des 27. August vorsorglich den Zugang zum Plesk-Panel für die Dauer des Updates eingeschränkt. In dieser Zeit war die Anmeldung am Panel und der Sprung aus dem Kundencenter ins Panel nicht möglich; Websites, E-Mail und Datenbanken liefen unverändert weiter. Das Update haben wir anschließend in Wellen auf allen Plesk-Servern eingespielt, den Versionsstand auf jedem Server geprüft und den Panel-Zugang noch am selben Tag wieder freigegeben.

Was du tun musst

Nichts. Falls du am 27. August vormittags nicht ins Plesk-Panel gekommen bist: Das war unsere vorsorgliche Sperre, kein Fehler an deinem Konto. Deine Zugänge und Einstellungen sind unverändert.

Die technischen Details stehen im Plesk-Advisory unter diesem Eintrag.

Ubuntu hat ein Sammel-Update für OpenSSL veröffentlicht, die Bibliothek, mit der praktisch jeder Dienst auf einem Linux-Server seine Verbindungen verschlüsselt. Zehn Lücken werden damit geschlossen, zwei davon wiegen schwer: Ein Angreifer könnte aus dem Internet einen Dienst zum Absturz bringen oder im ungünstigsten Fall die Prüfung verschlüsselter Daten aushebeln. Wir haben das Update am 26. August auf allen Ubuntu-Servern eingespielt und die betroffenen Dienste ohne Neustart der Server durchgestartet.

Was ist passiert?

OpenSSL steckt in Webservern, Mailservern, Datenbanken und Verwaltungsoberflächen. Die meisten der zehn Lücken erlauben es, einen Dienst mit präparierten Anfragen lahmzulegen. Zwei gehen weiter: Eine erlaubt das Überschreiben von Speicher beim Entpacken verschlüsselter Schlüssel, eine andere lässt sich nutzen, um die Integritätsprüfung Prüfsumme, mit der der Empfänger erkennt, ob verschlüsselte Daten unterwegs verändert wurden. bestimmter Verschlüsselungsverfahren zu umgehen. Beide sind aus dem Internet erreichbar, sobald ein Dienst mit der alten Bibliothek verschlüsselte Verbindungen annimmt.

Was wir getan haben

Bei einer Bibliothek wie OpenSSL reicht das Paket-Update allein nicht: Ein laufender Dienst arbeitet weiter mit der alten Version im Speicher, bis er neu gestartet wird. Genau das war auf einem Teil der Server der Fall, weil die automatischen Ubuntu-Updates das Paket zwar eingespielt, aber nicht alle Dienste neu gestartet hatten. Wir haben deshalb am 26. August auf allen Ubuntu-Servern gezielt jeden Dienst durchgestartet, der noch die alte Bibliothek geladen hatte, ohne die Server selbst neu zu starten. Danach haben wir auf jedem Server geprüft, dass kein Prozess mehr mit der alten Version läuft. Das betrifft unter anderem die Managed-Nextcloud-, OpenSearch-, BigBlueButton- und Mailserver.

Was du tun musst

Nichts. Die Neustarts der Dienste dauerten jeweils nur Sekunden; laufende Verbindungen wurden dabei neu aufgebaut, ohne dass Daten verloren gingen. Wenn du eigene Ubuntu-Maschinen außerhalb unserer Plattform betreust: Nach dem OpenSSL-Update alle Dienste neu starten, die verschlüsselte Verbindungen annehmen, nicht nur das Paket aktualisieren.

Welche Lücke welches Verfahren betrifft, steht in der Ubuntu-Meldung unter diesem Eintrag.

CloudLinux hat am 24. August eine Lücke in AccelerateWP offengelegt, dem WordPress-Beschleuniger auf CloudLinux-Servern. Beim Einschalten einer bestimmten Cache-Funktion legte das Werkzeug eine Kopie der wp-config.php offen im Webverzeichnis ab, samt Datenbank-Zugangsdaten. Behoben ist das seit Dezember 2025, die Veröffentlichung folgte erst jetzt. Unsere Server waren zu keinem Zeitpunkt betroffen.

Was ist passiert?

Die wp-config.php ist die zentrale Konfigurationsdatei einer WordPress-Installation. Sie enthält die Zugangsdaten zur Datenbank und die Schlüssel, mit denen WordPress Anmeldungen absichert. AccelerateWP legte beim Aktivieren des Object-Cache eine Sicherungskopie dieser Datei unter dem Namen wp-config.php.backup ab, und zwar im öffentlich erreichbaren Teil der Website. Wer den Dateinamen kannte, konnte sie ohne Anmeldung herunterladen.

Was wir getan haben

Wir haben am 24. August alle CloudLinux-Server geprüft. Ergebnis: AccelerateWP ist überall auf einem Stand, der die Lücke nicht mehr hat, nirgends liegt eine solche Sicherungskopie, und die betroffene Cache-Funktion war bei uns nie für Kunden freigeschaltet. Damit gab es auch in der Vergangenheit keinen Zeitraum, in dem eine solche Datei hätte abgerufen werden können. Ein Wechsel von Datenbank-Passwörtern ist deshalb nicht nötig.

Was du tun musst

Nichts. Wenn du WordPress auf einem Server außerhalb unserer Plattform betreibst, auf dem AccelerateWP läuft, prüfe dort, ob eine wp-config.php.backup im Webverzeichnis liegt. Falls ja: Datei löschen, Datenbank-Passwort und die Sicherheitsschlüssel in der wp-config.php neu setzen.

Die Details zur Lücke stehen im verlinkten CloudLinux-Beitrag unter diesem Eintrag.

BigBlueButton hat eine Sicherheitslücke in der Komponente für geteilte Notizen veröffentlicht, die mit der höchsten Kritikalitätsstufe bewertet ist: Ohne Anmeldung ließen sich darüber beliebige Dateien vom Server lesen. Das Advisory vom 13. August war über die üblichen Kanäle zunächst nicht sichtbar und hat uns erst am 24. August erreicht. Wir haben alle BigBlueButton-Server noch am selben Tag auf die gepatchte Version gebracht.

Was ist passiert?

Die geteilten Notizen in einer BigBlueButton-Konferenz laufen über ein eingebautes Etherpad. Durch einen Fehler in dessen Anbindung an den Webserver konnte jeder, der die Adresse des Servers kannte, über einen präparierten Aufruf Dateien außerhalb des vorgesehenen Verzeichnisses abrufen, darunter auch Konfigurationsdateien mit dem API-Secret Geheimer Schlüssel, mit dem Frontends wie Greenlight oder Moodle Konferenzen auf dem BBB-Server anlegen dürfen. des Servers. Eine Anmeldung oder ein laufendes Meeting war dafür nicht nötig.

Was wir getan haben

Wir haben das Update zuerst auf zwei Testsystemen durchgespielt, einem älteren und einem frisch aufgesetzten, und danach am 24. August auf allen Managed-BigBlueButton-Servern eingespielt. Die Aktualisierung lief in Gruppen, damit nicht alle Server gleichzeitig kurz nicht erreichbar sind. Nach dem Update haben wir den Versionsstand und die Dienste jedes Servers einzeln geprüft.

Was du tun musst

Nichts. Deine Räume, Aufzeichnungen und Einstellungen sind unverändert. Wenn du einen eigenen BigBlueButton-Server außerhalb unserer Plattform betreibst: auf 3.0.35 aktualisieren und anschließend das API-Secret neu setzen, wie im Advisory beschrieben.

Die technischen Details stehen im verlinkten BigBlueButton-Advisory unter diesem Eintrag.

Plesk hat am 24. August ein Sicherheitsupdate veröffentlicht, das zunächst nur als „kritisch” angekündigt war. Die Details kamen einen Tag später: drei Lücken, über die ein Kunde mit Plesk-Zugang Dateien vom Server lesen, auf fremde Datenbanken zugreifen oder sich volle Administrator-Rechte verschaffen konnte. Wir haben alle Plesk-Server am 24. August aktualisiert, die betroffenen Extensions folgten automatisch bis zum 26. August.

Was ist passiert?

Die erste Lücke steckt in der DNS-Verwaltung: Wer die DNS-Einträge seiner Domain in Plesk bearbeiten darf, konnte darüber beliebige Dateien vom Server lesen, darunter auch die Zugangsdaten des Panels selbst. Die zweite betrifft das Datenbank-Management, wo ein angemeldeter Nutzer Lese- und Schreibzugriff auf Datenbanken anderer Kunden auf demselben Server bekommen konnte. Die dritte liegt in den Extensions „Site Import” und „Plesk Migrator”, mit denen sich Websites umziehen lassen: Ein normales Hosting-Konto konnte darüber Befehle mit Root-Rechten Die höchste Rechtestufe auf einem Linux-System. Wer sie hat, kontrolliert den gesamten Server. ausführen.

Alle drei Lücken setzen einen bestehenden Plesk-Zugang voraus. Aus dem Internet sind sie ohne einen solchen Zugang nicht ausnutzbar.

Was wir getan haben

Wir haben am 24. August alle Plesk-Server auf die gepatchte Version gebracht und dabei auch die Systempakete auf den aktuellen Stand gezogen. Die beiden Extensions aktualisiert Plesk über seinen eigenen Mechanismus; das war in der Nacht zum 26. August auf allen Servern abgeschlossen. Am 26. August haben wir den Versionsstand von Panel und Extensions auf jedem Server einzeln kontrolliert.

Was du tun musst

Nichts. Deine Websites, Datenbanken und DNS-Einträge laufen unverändert weiter, an deinen Zugängen ändert sich nichts.

Die technischen Details stehen in den drei Plesk-Advisories unter diesem Eintrag.

Mitte August wurde eine weitere Sicherheitslücke in neueren Linux-Kerneln bekannt. Wer auf einem betroffenen Server ein normales Benutzerkonto hat, könnte sich darüber volle Administrator-Rechte verschaffen. Die Lücke braucht allerdings das Zusammenspiel zweier Kernel-Funktionen, von denen eine auf Webservern praktisch nie genutzt wird. Die endgültigen Kernel-Updates der Hersteller liegen noch nicht für alle Systeme vor. Unsere betroffenen Server sind seit dem 20. August dagegen abgesichert.

Was ist passiert?

Die Lücke steckt in dem Teil des Kernels, über den virtuelle Maschinen mit dem darunterliegenden Server Daten austauschen. Durch einen Fehler im Zusammenspiel mit einer schnellen Ein-/Ausgabe-Schnittstelle greift der Kernel auf bereits freigegebenen Speicher zu — ein bekannter Ausgangspunkt für die Übernahme von Root-Rechten Die höchste Rechtestufe auf einem Linux-System. Wer sie hat, kontrolliert den gesamten Server. . Angreifbar ist ein Server nur, wenn beide Funktionen zur Verfügung stehen. CloudLinux und AlmaLinux 9 und 10 haben die Ein-/Ausgabe-Schnittstelle ab Werk abgeschaltet und sind damit nicht betroffen. Unmittelbar betroffen waren Systeme mit Ubuntu 24.04 und Debian 13.

Was wir getan haben

Unsere Server brauchen den Datenaustausch mit virtuellen Maschinen nicht. Wir haben das zuständige Kernel-Modul Nachladbarer Baustein des Linux-Kernels, der eine bestimmte Funktion bereitstellt — lässt sich einzeln deaktivieren. samt seiner Transport-Varianten deshalb am 20. August auf allen Servern mit einem neueren Kernel entladen und gegen erneutes Laden gesperrt — vorsorglich auch auf den AlmaLinux-10-Systemen, die nach der Analyse ohnehin nicht angreifbar wären. Das geschah im laufenden Betrieb, ohne Neustart und ohne Unterbrechung. Jeden Server haben wir danach einzeln kontrolliert.

Was du tun musst

Nichts. Deine Anwendungen laufen unverändert weiter, es gab keine Unterbrechung. Wenn du eigene Linux-Maschinen mit Ubuntu 24.04, Debian 13 oder einem anderen Kernel ab Version 6.5 außerhalb unserer Plattform betreust und dort keine virtuellen Maschinen betreibst, steht die Abschaltung als Ein-Zeilen-Lösung im unten verlinkten CloudLinux-Beitrag. Wo der Datenaustausch mit virtuellen Maschinen gebraucht wird, hilft nur das Kernel-Update des jeweiligen Herstellers.

Wie die Lücke technisch funktioniert und welche Systeme betroffen sind, steht in der Quelle unter diesem Eintrag.

Mailcow, die Software hinter unseren Mailservern, hat ein zweites Sicherheits-Release in Folge veröffentlicht. Es benennt keine einzelne Lücke, sondern hebt gleich drei mitgelieferte Bausteine auf neue Fassungen, die nach Angaben der jeweiligen Projekte mehrere Sicherheitsprobleme beheben, und härtet obendrein die Web-Oberfläche. Mailserver stehen offen im Internet, deshalb spielen wir solche Updates mit Vorrang ein. Alle unsere Mailserver-Instanzen sind seit dem 19. August auf dem neuen Stand.

Was ist passiert?

Das Release erneuert den Zwischenspeicher, den Viren-Scanner und die Groupware-Komponente, über die Kalender und Kontakte laufen — alle drei mit dem ausdrücklichen Hinweis auf behobene Sicherheitsprobleme. Dazu kommen Härtungen an der Web-Oberfläche und an der Konfiguration des Webservers sowie aktualisierte Regeln, mit denen der Mailserver unerwünschte einliefernde Gegenstellen abweist. Die Lücke im Webserver selbst, die das vorherige Release geschlossen hatte, war auf unseren Instanzen bereits am 5. August eingespielt.

Was wir getan haben

Wir haben alle Mailcow-Instanzen am 19. August auf die neue Fassung aktualisiert und danach jede einzelne kontrolliert, ob alle Dienste sauber laufen. Versand und Empfang liefen während des Updates weiter.

Was du tun musst

Nichts. Postfächer, Weiterleitungen und Filter sind unverändert, deine Mail-Programme müssen nicht neu eingerichtet werden.

Welche Bestandteile das Release im Einzelnen erneuert, steht in der Quelle unter diesem Eintrag.

Nextcloud hat eine Sicherheitslücke in der Rechteprüfung von Freigabe-Links gemeldet. In bestimmten Konstellationen bekamen Empfänger eines Links volle Schreibrechte, obwohl die Freigabe eigentlich nur zum Lesen gedacht war. Betroffen sind drei eng begrenzte Versionsstände der aktuellen Nextcloud-Linien. Die von uns betriebenen Nextcloud-Instanzen laufen auf Versionen, in denen der Fehler bereits behoben ist.

Was ist passiert?

Der Fehler betrifft Freigabe-Links auf Inhalte, die nicht im persönlichen Speicher eines Benutzers liegen, sondern zum Beispiel in Gruppenordnern Gemeinsame Ordner für Teams oder Abteilungen, die Administratoren zentral anlegen und berechtigen. oder auf eingebundenem externem Speicher. Für solche Links wurden die am Share eingestellten Berechtigungen ignoriert: Wer den Link hatte, konnte Dateien ändern oder löschen, auch wenn die Freigabe nur lesend sein sollte. Ein Angreifer braucht dafür lediglich einen gültigen Link. Nextcloud hat die Lücke Anfang August veröffentlicht und mit den Versionen 32.0.12, 33.0.6 und 34.0.1 geschlossen.

Was wir getan haben

Wir haben am 19. August die Versionsstände aller Managed-Nextcloud-Instanzen geprüft. Keine davon läuft auf einem der betroffenen Versionsstände — die eingesetzten Versionen liegen bereits auf dem korrigierten Stand. Eine Maßnahme war deshalb nicht nötig.

Was du tun musst

Nichts, wenn deine Nextcloud bei uns läuft. Betreibst du eine eigene Nextcloud außerhalb unserer Plattform, prüfe die Version: Liegt sie bei 32.0.10, 32.0.11, 33.0.4, 33.0.5 oder 34.0.0, spiele das Update ein. Bis dahin lohnt ein Blick auf bestehende Freigabe-Links aus Gruppenordnern oder externem Speicher — sie könnten mehr erlauben, als eingestellt ist.

Die genauen Versionsangaben und die Einschätzung des Herstellers stehen in der Quelle unter diesem Eintrag.

Mitte August wurde eine Sicherheitslücke in neueren Linux-Kerneln bekannt, für die bereits eine fertige Angriffs-Anleitung kursiert. Wer auf einem betroffenen Server ein normales Benutzerkonto hat, könnte sich darüber volle Administrator-Rechte verschaffen — auch aus einem Container heraus. Anders als bei vielen Kernel-Lücken der letzten Wochen gibt es diesmal keinen Behelf im laufenden Betrieb: Nur ein neuer Kernel schließt sie, und der braucht einen Neustart. Alle betroffenen Server laufen seit dem 20. August auf dem gepatchten Kernel.

Was ist passiert?

Die Lücke steckt in der Speicherverwaltung des Kernels, genauer in dem Teil, der nicht mehr benötigte Verbindungen zwischen Programmen aufräumt. Durch einen Fehler dort lässt sich der Kernel dazu bringen, auf bereits freigegebenen Speicher zuzugreifen — ein klassischer Ausgangspunkt, um Root-Rechte Die höchste Rechtestufe auf einem Linux-System. Wer sie hat, kontrolliert den gesamten Server. zu übernehmen. Betroffen sind nur vergleichsweise neue Kernel-Linien, also etwa CloudLinux 10, AlmaLinux 10 und Debian 13. Die älteren 8er- und 9er-Linien sind nicht betroffen. Aus dem Internet ist die Lücke ohne ein lokales Benutzerkonto nicht ausnutzbar.

Was wir getan haben

Den gepatchten Kernel haben wir am 18. August zuerst auf den geteilten Hosting-Servern eingespielt und diese neu gestartet — dort ist das Risiko am höchsten, weil viele Kunden nebeneinander auf demselben System arbeiten. Die übrigen betroffenen Systeme folgten am 20. August in mehreren Neustart-Wellen. Ein Livepatch, der den Neustart erspart hätte, stand für diese Lücke nicht rechtzeitig zur Verfügung; die Neustarts waren deshalb notwendig und sind abgeschlossen.

Was du tun musst

Nichts. Deine Anwendungen laufen auf dem gepatchten Kernel weiter; der Neustart deines Servers war kurz und ist vorbei. Wenn du eigene Linux-Maschinen mit einem Kernel ab Version 6.9 außerhalb unserer Plattform betreust, spiele dort das Kernel-Update ein und starte neu — einen anderen Weg gibt es bei dieser Lücke nicht.

Welche Kernel-Versionen die Lücke schließen, steht in der Quelle unter diesem Eintrag.

Am 18. August hat CloudLinux eine Sicherheitslücke im Linux-Kernel veröffentlicht, über die ein gewöhnliches Benutzerkonto den ganzen Server zum Absturz bringen kann. Auf geteilten Hosting-Servern hieße das: Eine einzelne gehackte Website könnte alle anderen Websites auf demselben System mit in den Ausfall reißen. Die endgültigen Kernel-Updates sind für einen Teil der Systeme noch in Arbeit. Unsere Server sind seit dem 18. August dagegen abgesichert.

Was ist passiert?

Die Lücke steckt in dem Kernel-Bereich, der Netzwerkverkehr auf einem Server priorisiert und begrenzt. Über eine Race-Condition Fehler, bei dem zwei gleichzeitige Vorgänge sich in die Quere kommen und einen unerwarteten Zustand hinterlassen. lässt sich dort Speicher doppelt freigeben, was den Kernel beschädigt und das System zum Stillstand bringt. Voraussetzung ist, dass ein normaler Benutzer einen eigenen Benutzer-Namensraum Abgeschotteter Bereich im Kernel, in dem ein Benutzer eigene, isolierte Netzwerk- und Rechte-Einstellungen anlegen darf. anlegen darf. Auf CloudLinux 9 und 10 ist das ab Werk unterbunden, auf den älteren Linien 7h und 8 dagegen erlaubt — dort war die Lücke unmittelbar ausnutzbar.

Was wir getan haben

Wir haben am 18. August auf allen Servern geprüft, ob ein normaler Benutzer dort einen eigenen Namensraum anlegen kann, und diese Möglichkeit anschließend auf allen betroffenen Servern abgeschaltet. Das geschah per Konfigurationsänderung im laufenden Betrieb, ohne Neustart und ohne Unterbrechung. Jeden Server haben wir danach einzeln kontrolliert.

Was du tun musst

Nichts. Deine Anwendungen laufen unverändert weiter. Einzige Ausnahme: Wenn du auf einem Managed Server selbst Software betreibst, die Benutzer-Namensräume braucht — typischerweise Container-Werkzeuge ohne Administrator-Rechte — und dir nach dem 18. August etwas auffällt, melde dich kurz bei uns: +49 (0)2102 305 84 30. Wer eigene Linux-Maschinen außerhalb unserer Plattform betreut, findet die Ein-Zeilen-Mitigation im unten verlinkten CloudLinux-Beitrag.

Die technische Analyse und der Stand der Kernel-Updates stehen in der Quelle unter diesem Eintrag.

Plesk und cPanel haben am 14. August fast zeitgleich vor derselben Lücke gewarnt: Im Anwendungs-Server Phusion Passenger Anwendungs-Server, der Ruby-, Node.js- und Python-Anwendungen hinter dem Webserver betreibt. kann ein lokaler Angreifer über eine interne Kontroll-Schnittstelle Root-Rechte erlangen. Betroffen sind nur Server, auf denen Passenger installiert ist; das ist bei uns die Ausnahme, nicht der Standard. Wir haben die Lücke am 14. August auf allen betroffenen Servern geschlossen.

Was ist passiert?

Passenger bringt einen Überwachungs-Prozess mit, den Watchdog, der die laufenden Anwendungen im Blick behält und bei Bedarf neu startet. Über dessen Kontroll-Schnittstelle kann jemand, der bereits ein Benutzerkonto auf dem Server hat oder eine dort gehostete Website übernommen hat, Befehle mit Root-Rechten ausführen und damit den ganzen Server übernehmen. Aus dem Internet ist die Lücke ohne einen solchen Zugang nicht direkt ausnutzbar.

Die Informationslage ist ungewöhnlich dünn: Eine CVE-Nummer gibt es bisher nicht, technische Details halten beide Hersteller knapp. Klar ist aber: Standard-Installationen von Plesk und cPanel sind nicht betroffen, Passenger muss aktiv installiert sein.

Was wir getan haben

Wir haben am 14. August die gesamte Flotte daraufhin geprüft, auf welchen Servern Passenger installiert ist, und die Lücke noch am selben Tag geschlossen. Die Plesk-Server haben den von Plesk bereitgestellten Hotfix erhalten; dabei wird der Webserver einmal kurz neu gestartet. Auf den betroffenen cPanel-Servern haben wir die Passenger-Pakete auf die gepatchten Versionen aktualisiert und den neuen Stand anschließend paketweise verifiziert. Auf einzelnen Servern ließ sich das Update nicht installieren; dort haben wir Passenger stattdessen entfernt, womit die Lücke ebenfalls geschlossen ist.

Was du tun musst

Nichts, wenn deine Anwendungen auf PHP laufen, wie bei den meisten unserer Kunden: Dann ist Passenger auf deinem Server entweder gar nicht installiert oder inzwischen gepatcht. Betreibst du außerhalb unserer Plattform eigene Server mit Passenger, spiele das Panel-Update ein (Plesk 18.0.80.3 bzw. 18.0.79.7, bei cPanel die aktualisierten Passenger-Pakete) oder deinstalliere Passenger, falls er nicht gebraucht wird.

Welche Paketversionen die Lücke schließen und was die Hersteller sonst noch empfehlen, steht in den Quellen unter diesem Eintrag.

Plesk hat eine Sicherheitslücke in der Datenbank-Verwaltung gemeldet: Wer in Plesk eine Datenbank klonen oder kopieren darf, konnte sich darüber Administrator-Rechte auf dem Datenbank-Server verschaffen. Betroffen sind nahezu alle Plesk-Versionen der letzten Jahre. Wir haben alle Plesk-Server am 12. August auf die gepatchte Version aktualisiert.

Was ist passiert?

Das Klonen einer Datenbank ist eine normale Funktion im Plesk-Panel, etwa um eine Test-Kopie einer Website mit eigener Datenbank aufzusetzen. Durch einen Fehler in der Rechteprüfung konnte ein Kunde mit Zugriff auf diese Funktion dabei mehr Rechte erlangen, als ihm zustehen: volle Administrator-Rechte auf dem Datenbank-Server. Damit wäre auch der Zugriff auf Datenbanken anderer Kunden auf demselben Server möglich gewesen.

Voraussetzung ist ein bestehender Plesk-Zugang auf dem Server. Aus dem Internet ist die Lücke ohne einen solchen Zugang nicht ausnutzbar.

Was wir getan haben

Wir haben das von Plesk bereitgestellte Update am 12. August auf allen Plesk-Servern eingespielt und den Versionsstand anschließend geprüft. Die Rechteprüfung beim Klonen ist damit korrigiert, die Lücke ist geschlossen.

Was du tun musst

Nichts. Deine Datenbanken und Websites laufen unverändert weiter, an deinen Zugängen ändert sich nichts.

Die technischen Details zur Lücke stehen im verlinkten Plesk-Advisory unter diesem Eintrag.

Am 6. August wurde eine Sicherheitslücke im Linux-Kernel veröffentlicht, zusammen mit einer funktionierenden Anleitung zum Ausnutzen. Sie steckt in der Virtualisierungs-Technik, die in jedem modernen Linux mitläuft — auch auf Servern, die überhaupt keine virtuellen Maschinen betreiben. Wer auf einem betroffenen Server ein normales Benutzerkonto besitzt oder eine Website übernommen hat, hätte sich darüber volle Administrator-Rechte verschaffen können. Wir haben die betroffene Technik am 7. August auf allen Servern abgeschaltet.

Was ist passiert?

Die Lücke steckt in KVM Virtualisierungs-Unterbau des Linux-Kernels. Er erlaubt es, auf einem Server weitere virtuelle Maschinen zu betreiben. , einem festen Bestandteil des Linux-Kernels. Durch einen Fehler in der Speicherverwaltung lässt sich der Kernel gezielt aus dem Tritt bringen. Dorthin führen zwei Wege: Auf Servern, die virtuelle Maschinen betreiben, kann jemand aus seiner eigenen Maschine ausbrechen und den darunterliegenden Server übernehmen. Auf geteilten Servern ohne Virtualisierung genügt ein gewöhnliches Benutzerkonto — auf mehreren Linux-Varianten steht die zugehörige Schnittstelle allen Nutzern offen, sodass auch eine gehackte Website den Angriff starten kann.

Betroffen sind nur Server, bei denen mehrere Bedingungen zusammenkommen: aktive verschachtelte Virtualisierung und ein AMD-Prozessor oder ein neuerer Intel-Prozessor. Nach diesen Kriterien haben wir unsere gesamte Flotte durchsucht.

Was wir getan haben

Der Flotten-Scan brachte einen Befund, der die Entscheidung leicht gemacht hat: Auf unseren Hosting-Servern läuft keine einzige virtuelle Maschine. Die angegriffene Technik wird dort also gar nicht gebraucht.

Wir haben sie deshalb am 7. August vollständig entladen und dauerhaft gegen erneutes Laden gesperrt — auf allen Servern, ausdrücklich auch auf denen, die nach der Analyse ohnehin nicht angreifbar waren. Beide Angriffswege sind damit geschlossen. Das geschah im laufenden Betrieb, ohne Neustart und ohne Unterbrechung. Auch die Backups laufen unverändert weiter: Der Dienst, der sie auf dem Server auslöst, nutzt diese Technik nicht.

Die endgültigen Kernel-Updates der Hersteller liegen erst für einen Teil der Systeme fertig vor. Wir spielen sie im regulären Wartungszyklus nach — solange die Technik abgeschaltet ist, läuft ein Angriff ins Leere.

Was du tun musst

Nichts. Deine Anwendungen laufen unverändert weiter, es gab keine Unterbrechung.

Wenn du eigene Linux-Maschinen außerhalb unserer Plattform betreust, lohnt dort die Prüfung, ob die Virtualisierung überhaupt gebraucht wird. Falls nicht, steht die Abschaltung als Ein-Zeilen-Lösung im unten verlinkten CloudLinux-Beitrag. Wo tatsächlich virtuelle Maschinen laufen, hilft nur das Kernel-Update des jeweiligen Herstellers.

Wie die Lücke technisch funktioniert und welche Kernel-Versionen sie schließen, steht in der Quelle unter diesem Eintrag.

In der ConfigServer Firewall — der Firewall, die auf einem Teil unserer Server den Zugang von außen regelt — wurden mehrere Schwachstellen gefunden. Über sie hätte ein Angreifer die höchste Rechtestufe auf dem Server erlangen können. Betroffen sind alle Fassungen bis einschließlich 16.20-1; einen Behelf gibt es laut Hersteller nicht, nur das Update. Wir haben die betroffenen Server am 6. August auf die fehlerbereinigte Fassung gebracht.

Was ist passiert?

Die Firewall entscheidet, welche Verbindungen einen Server überhaupt erreichen, und läuft dafür mit weitreichenden Rechten. Genau das macht Fehler an dieser Stelle heikel: Wer sie ausnutzt, steht nicht vor der Tür, sondern hat den Schlüssel zum ganzen System. Der Hersteller hat die Einzelheiten bewusst nicht veröffentlicht und keine CVE-Nummern vergeben — die Meldung beschränkt sich auf die Aufforderung, umgehend zu aktualisieren.

Was wir getan haben

Wir haben zuerst erhoben, welche Fassung auf welchem Server tatsächlich installiert ist, statt uns auf die automatische Aktualisierung zu verlassen. Auf dieser Grundlage haben wir die Server am 6. August auf die fehlerbereinigte Fassung 16.30-1 gebracht und den Stand anschließend erneut ausgelesen.

Was du tun musst

Nichts. Deine Firewall-Freigaben, Ports und Sperrlisten bleiben unverändert; das Update tauscht nur die Software selbst aus.

Die Hersteller-Meldung mit den betroffenen Fassungen findest du in der Quelle unter diesem Eintrag.

Mailcow, die Software hinter unseren Mailservern, hat Ende Juli ein ausdrückliches Sicherheits-Release veröffentlicht. Es schließt eine Lücke im mitgelieferten Webserver und härtet mehrere Wege in die Web-Oberfläche ab. Mailserver stehen naturgemäß offen im Internet, deshalb behandeln wir Updates an dieser Stelle mit Vorrang. Alle unsere Mailserver-Instanzen sind seit dem 5. August aktualisiert.

Was ist passiert?

Der Hersteller nennt als wichtigsten Punkt eine Schwachstelle im Webserver, über den die Mailcow-Oberfläche und die Weboberfläche für dein Postfach ausgeliefert werden. Daneben wurde der Spam-Filter auf eine neue Fassung gehoben und die Prüfung abgesichert, welche fremden Websites Anfragen an die Oberfläche stellen dürfen.

Was wir getan haben

Wir haben alle Mailcow-Instanzen am 5. August auf die neue Fassung aktualisiert und anschließend jede einzelne durchgesehen, ob alle Dienste sauber hochgekommen sind. Der Versand und Empfang lief während des Updates weiter.

Was du tun musst

Nichts. Deine Postfächer, Weiterleitungen und Filter sind unverändert, und deine Mail-Programme müssen nicht neu eingerichtet werden.

Welche Bestandteile das Release im Einzelnen erneuert, steht in der Quelle unter diesem Eintrag.

Plesk hat Anfang August mehrere Sicherheitsupdates veröffentlicht: ein größeres Release, kurz darauf zwei nachgeschobene Kleinst-Updates und eine neue Fassung der Erweiterung für die Zwei-Faktor-Anmeldung. Konkret benannt ist davon nur eine Lücke — sie betrifft die Echtheitsprüfung von E-Mails und ermöglichte Phishing zwischen Kunden desselben Servers. Alle Plesk-Server sind seit dem 5. August auf dem neuen Stand.

Was ist passiert?

Der eine dokumentierte Fehler steckte in DKIM Verfahren, das ausgehende E-Mails digital signiert. Empfänger können damit prüfen, ob eine Mail wirklich von der angegebenen Domain stammt. , dem Signatur-Verfahren für ausgehende E-Mails. Wer auf demselben Server einen Zugang hatte, konnte eine fremde Absenderadresse eintragen und bekam darauf trotzdem eine gültige Signatur. Eine so verschickte Mail sah für den Empfänger echt aus, obwohl sie es nicht war.

Die übrigen Updates deklariert Plesk lediglich als „Security improvements”, ohne Details und ohne CVE-Nummern. Wir behandeln solche Updates grundsätzlich als dringend: Das Plesk-Panel ist über seinen eigenen Port direkt aus dem Internet erreichbar, und bei der Erweiterung für die Zwei-Faktor-Anmeldung geht es um die Anmeldung selbst. Warum wir uns auf Hersteller-Changelogs nicht mehr verlassen, haben wir im Beitrag Sicherheitsupdates ohne Changelog beschrieben.

Was wir getan haben

Wir haben die Plesk-Server am 4. und 5. August auf die aktuelle Fassung gebracht — je nach Server auf 18.0.80 mit dem nachgereichten Update oder auf den gepflegten Stand des Vorgänger-Zweigs. Die Erweiterung für die Zwei-Faktor-Anmeldung haben wir ebenfalls aktualisiert. Mit dem großen Release sind zusätzlich veraltete Verschlüsselungs-Verfahren für signierte DNS-Zonen entfernt sowie die Web-Application-Firewall und der FTP-Dienst erneuert worden.

Was du tun musst

Nichts. Bestehende signierte DNS-Zonen laufen unverändert weiter, deine E-Mail-Einstellungen bleiben wie sie sind.

Wenn du dich bisher ohne zweiten Faktor in Plesk anmeldest, ist das ein guter Zeitpunkt, das zu ändern. Sprich uns an, dann richten wir die Zwei-Faktor-Anmeldung für deinen Zugang ein: +49 (0)2102 305 84 30.

Die vollständigen Änderungslisten der einzelnen Versionen findest du in den Quellen unter diesem Eintrag.

Das PHP-Projekt hat Ende Juli vier Sicherheitslücken geschlossen und für alle aktuellen Versionen neue Ausgaben veröffentlicht. Zwei davon sind aus ganz normalem Anwendungs-Code heraus erreichbar — also aus dem Shop, dem Redaktionssystem oder dem Plugin, das auf deinem Webspace läuft. Auf geteilten Servern ist das unmittelbar relevant. Wir haben die neuen PHP-Versionen am 3. August auf allen Servern eingespielt.

Was ist passiert?

Die schwerwiegendste der vier Lücken steckt in einer Rechenfunktion für sehr große Zahlen: Bei einem ungünstigen Aufruf schreibt PHP über den vorgesehenen Speicherbereich hinaus. Die zweite betrifft die Anbindung an PostgreSQL-Datenbanken — über eine besondere Schreibweise für Textwerte ließ sich aus der Zeichenkette ausbrechen und damit eine SQL-Injection Angriff, bei dem eigene Datenbank-Befehle in eine Anfrage eingeschleust werden. unterbringen. Beide setzen keinen besonderen Zugang voraus, sondern nur Code, der die betroffene Funktion benutzt.

Was wir getan haben

Wir haben die PHP-Versionen 8.2 bis 8.5 am 3. August auf den jeweils aktuellen Stand gebracht und die laufenden Prozesse anschließend neu gestartet, damit die neuen Versionen auch tatsächlich greifen. Deine Websites waren davon nicht spürbar betroffen.

Was du tun musst

Nichts, solange deine Anwendung auf PHP 8.2 oder neuer läuft — das ist bei den allermeisten Installationen der Fall.

Anders sieht es aus, wenn du noch PHP 7.4, 8.0 oder 8.1 einsetzt: Diese Versionen bekommen vom PHP-Projekt keine Sicherheitsupdates mehr, die oben genannten Lücken bleiben dort also offen. Wir halten sie aus Kompatibilitätsgründen weiterhin bereit, empfehlen aber den Wechsel. Die PHP-Version lässt sich in Plesk pro Domain umstellen; wenn du dabei Unterstützung brauchst, melde dich unter +49 (0)2102 305 84 30.

Welche Funktionen im Einzelnen betroffen sind, steht in der Quelle unter diesem Eintrag.

Am 28. Juli wurde eine neue Sicherheitslücke im Linux-Kernel veröffentlicht, zusammen mit einer funktionierenden Anleitung zum Ausnutzen. Wer auf einem betroffenen Server ein normales Benutzerkonto hat, könnte sich darüber volle Administrator-Rechte verschaffen. Die endgültigen Kernel-Updates der Hersteller sind noch in Arbeit. Unsere Server sind trotzdem bereits dagegen abgesichert.

Was ist passiert?

Die Lücke steckt in Open vSwitch Netzwerk-Modul im Linux-Kernel, das virtuelle Netzwerke zwischen Servern verbindet. Auf Webservern normalerweise ungenutzt. , einem Kernel-Modul, das in fast jedem aktuellen Linux enthalten ist. Das Tückische: Das Modul muss gar nicht in Benutzung sein, seine bloße Anwesenheit reicht für einen Angriff. Deshalb sind praktisch alle gängigen Linux-Systeme betroffen, von AlmaLinux über CloudLinux bis Ubuntu.

Was wir getan haben

Unsere Server brauchen dieses Modul nicht. Wir haben es deshalb noch am Tag der Veröffentlichung auf allen Systemen deaktiviert, ohne Neustart und ohne Unterbrechung. Damit läuft der Angriff ins Leere, bevor die Hersteller ihre endgültigen Kernel-Updates fertig haben.

Was du tun musst

Nichts. Deine Anwendungen laufen unverändert weiter, es gab keine Unterbrechung. Wenn du eigene Linux-Maschinen außerhalb unserer Plattform betreust, solltest du dort handeln: Die Ein-Zeilen-Mitigation zum Deaktivieren des Moduls steht im unten verlinkten CloudLinux-Beitrag.

Die vollständige technische Analyse findest du in den Quellen unter diesem Eintrag.

Am 22. Juli wurde eine Sicherheitslücke im Linux-Kernel veröffentlicht, die dort seit neun Jahren unentdeckt geschlummert hat. Wer auf einem betroffenen Server ein normales Benutzerkonto hat, könnte darüber geschützte Systemdateien überschreiben und volle Administrator-Rechte übernehmen. Besonders unangenehm: Die Manipulation übersteht Neustarts und ist in den System-Protokollen praktisch unsichtbar. Unsere Server sind seit dem 24. Juli gepatcht.

Was ist passiert?

Die Lücke steckt im XFS-Dateisystem Dateisystem, das viele Linux-Server zum Ablegen und Verwalten von Dateien nutzen. und existiert seit 2017 in praktisch jedem Linux-Kernel. Über eine Race-Condition Fehler, bei dem zwei gleichzeitige Vorgänge sich in die Quere kommen und einen unerwarteten Zustand hinterlassen. beim gleichzeitigen Schreiben kann ein Angreifer mit normalem Benutzerkonto jede lesbare Datei im Dateisystem verändern, auch solche, die das System eigentlich schützt. Damit lassen sich Root-Rechte übernehmen, selbst wenn zusätzliche Sicherheits-Schichten wie SELinux aktiv sind.

Was wir getan haben

Wir haben die Kernel-Fixes am 24. Juli ausgerollt, zwei Tage nach der Veröffentlichung. Auf Servern mit aktivem Livepatching kam der Fix ohne Neustart und ohne Unterbrechung; die übrigen Systeme haben wir in einem koordinierten Wartungsfenster neu gestartet. Den Verlauf haben wir über die Status-Seite begleitet.

Was du tun musst

Nichts. Der Rollout ist abgeschlossen, deine Anwendungen laufen unverändert weiter. Wenn du eigene Linux-Maschinen außerhalb unserer Plattform betreust, gilt dort: nicht nur das Kernel-Update einspielen, sondern bei Verdacht auch prüfen, ob wichtige Systemdateien unverändert sind, denn die Manipulation übersteht Neustarts. Unabhängig davon sichern unsere täglichen Plattform-Backups den Stand vor dem Veröffentlichungs-Datum, falls eine Wiederherstellung nötig würde.

Die vollständige technische Analyse mit allen Kernel-Details findest du in den Quellen unter diesem Eintrag.

Mitte Juli wurden zwei schwerwiegende Lücken im Kern von WordPress bekannt. Über eine Schnittstelle, die jede WordPress-Installation von Haus aus mitbringt, lässt sich fremder Programmcode ausführen — ganz ohne Anmeldung, ohne Passwort, ohne Benutzerkonto. Die Lücke wurde von Angreifern sofort in großem Stil ausgenutzt. Wir haben den Angriffsweg am 20. Juli auf allen Servern blockiert.

Was ist passiert?

Betroffen ist die REST-Schnittstelle Schnittstelle, über die WordPress Daten an andere Programme ausliefert und entgegennimmt — etwa für Apps oder gekoppelte Systeme. von WordPress, genauer ein Bereich, der mehrere Anweisungen in einer einzigen Anfrage bündelt. Über ihn ließ sich einerseits die Datenbank auslesen und andererseits eigener Code auf dem Server ausführen. Weil dafür kein Zugang nötig war, genügte für einen Angriff das bloße Wissen um die Adresse der Website.

Genau das macht die Lücke für geteiltes Hosting so unangenehm: Auf einem Server liegen viele WordPress-Installationen, die von unterschiedlichen Agenturen und Betreibern gepflegt werden — und eben nicht alle gleich schnell.

Was wir getan haben

Wir haben am 20. Juli eine Sperre auf Serverebene aktiviert, die Anfragen an den betroffenen Bereich abfängt, bevor sie WordPress überhaupt erreichen. Sie wirkt unabhängig davon, ob die jeweilige Installation schon aktualisiert wurde, und schützt damit auch Websites, deren Betreuung gerade im Urlaub ist.

Diese Sperre ersetzt das Update aber nicht. Sie schließt den bekannten Angriffsweg, und sie schützt nur dort, wo unsere Server davorstehen.

Was du tun musst

Aktualisiere deine WordPress-Installation auf Version 7.0.2 oder neuer. Wenn du die automatischen Updates für den WordPress-Kern aktiviert hast, ist das mit hoher Wahrscheinlichkeit bereits geschehen — ein Blick ins Dashboard schafft Klarheit.

Wichtig ist das aus zwei Gründen: Das Update ist die eigentliche Behebung, und es wirkt auch dort, wo unsere Sperre nicht greift — auf deinem Testsystem, in der lokalen Entwicklungsumgebung oder auf Installationen, die woanders liegen. Bist du dir bei einer deiner Websites unsicher, ruf uns an: +49 (0)2102 305 84 30.

Welche Anfragen im Einzelnen betroffen sind, steht in der Quelle unter diesem Eintrag.

Im Juli sind kurz hintereinander vier Sicherheitslücken im Linux-Kernel bekannt geworden, die alle auf dasselbe hinauslaufen: Aus einem normalen Benutzerkonto lassen sich volle Administrator-Rechte machen. Für die bekannteste, „GhostLock”, kursierte schon zur Veröffentlichung eine fertige Angriffs-Anleitung. Ein einziges Kernel-Update schließt alle vier Lücken auf einmal. Unsere Server laufen seit dem 9. Juli mit dem abgesicherten Kernel, die Neustarts sind abgeschlossen.

Was ist passiert?

Die vier Lücken (GhostLock, Bad Epoll, pedit COW, DirtyClone) stecken in unterschiedlichen Teilen des Kernels, GhostLock zum Beispiel seit rund 15 Jahren. Für Multi-Tenant-Umgebungen Server, auf denen mehrere Kunden nebeneinander laufen, wie beim geteilten Webhosting. ist diese Art Lücke die kritischste Kategorie: Als Einstiegspunkt reicht ein gekapertes CMS-Plugin in einem einzelnen Kunden-Account, danach stünde der ganze Server offen.

Was wir getan haben

Wir haben das Kernel-Update am 9. Juli auf allen Servern eingespielt, wenige Stunden nach der Veröffentlichung. Weil die Fixes im Kernel sitzen, brauchte es Neustarts; die haben wir noch am selben Tag koordiniert durchgeführt. Ganz glatt lief es nicht: Auf einem Teil der Systeme wurde das Update zunächst unvollständig installiert, einige Webseiten zeigten vorübergehend Fehler. Zwei Nachkorrekturen später lief alles sauber, den Verlauf haben wir live auf der Status-Seite dokumentiert.

Was du tun musst

Nichts. Deine Anwendung läuft auf dem gepatchten Kernel weiter. Zwischen Veröffentlichung und Neustart lag ein kurzes Zeitfenster, in dem die Lücken theoretisch ausnutzbar waren; Hinweise auf eine Ausnutzung auf unseren Systemen haben wir nicht. Auf Managed Servern und Clustern haben ohnehin nur du und unser Team Shell-Zugriff. Eigene Linux-Maschinen außerhalb unserer Plattform: Kernel-Update einspielen und neu starten.

Die technischen Details stehen in den verlinkten CloudLinux-Beiträgen unter diesem Eintrag.