Kurz gefasst
Wenn dein Hosting-Panel die Schlüssel zu allen Kundenwebseiten hält, ist es das erste Ziel, das Angreifer suchen. Genau darum lohnt ein Blick auf die aktuelle Warnung zu Froxlor. Das CERT-Bund führt sie im Warn- und Informationsdienst unter der Kennung WID-SEC-2026-3629.
- Das CERT-Bund hat unter der Kennung WID-SEC-2026-3629 eine Warnung zu Froxlor veröffentlicht.
- Betroffen ist, wer Froxlor selbst auf einem Rootserver betreibt. Die Wartung liegt bei dir, nicht beim Anbieter.
- Vier Dinge gehören auf deine Liste: Version klären, Panel aus dem offenen Netz nehmen, Update einspielen, Spuren prüfen.
Einordnung vorab: Wir nennen in diesem Beitrag bewusst keine CVE-Nummern, betroffenen Versionen oder Angriffsdetails. Die verbindlichen Angaben stehen im Advisory selbst und in den Release-Hinweisen des Froxlor-Projekts. Lies sie, bevor du entscheidest, ob deine Installation betroffen ist. Was wir hier liefern, ist die Prüfreihenfolge, die in jedem Fall sinnvoll ist.
---
## Warum ein Hosting-Panel ein besonders lohnendes Ziel ist
Froxlor verwaltet Domains, Datenbanken, FTP-Konten, Mail-Adressen und Webserver-Konfigurationen an einer Stelle. Damit hat das Panel weitreichende Rechte auf dem Server. Wer das Panel übernimmt, kommt oft an mehr heran als an eine einzelne Webseite.
Das Muster kennst du von anderen Verwaltungsoberflächen. Wir haben es bei Webmin beschrieben und bei Virtualizor. Die Software ist im Kern gut gepflegt, aber die Oberfläche hängt im Internet, und ein einziger Fehler in der Anmeldung oder im Rechtesystem reicht.
Ein Panel, das jeder aus dem Internet erreicht, wird gefunden, meist schneller, als man ein Update einspielt.## Wen die Warnung betrifft Die Antwort hängt davon ab, wer die Software pflegt:
| Situation | Wer aktualisiert? | Handlungsbedarf |
|---|---|---|
| Froxlor auf eigenem Rootserver | Du | Hoch: sofort prüfen |
| Froxlor auf einem Server, den du für Kunden betreibst | Du | Hoch: auch Kundendaten sind betroffen |
| Verwaltetes Webhosting ohne eigenes Panel | Der Anbieter | Keiner, nur nachfragen |
| Froxlor-Testinstallation | Du | Mittel: abschalten oder aktualisieren |
- Version feststellen. Melde dich im Panel an und lies die installierte Version ab. Vergleiche sie mit den im Advisory und in den Release-Hinweisen genannten Ständen. Ist die Version dort als betroffen aufgeführt, gehst du sofort zu Schritt 3.
- Systempakete prüfen. Zeige an, welche Updates auf dem Server offen sind:
Ein Panel-Update ersetzt keine Betriebssystem-Updates. PHP, Webserver und Datenbank müssen ebenfalls aktuell sein.sudo apt update apt list --upgradable - Zugriff einschränken. Bis das Update durch ist, sperrst du die Panel-Oberfläche für alle außer dir. Mit ufw erlaubst du zum Beispiel nur deine feste IP auf dem HTTPS-Port (Adresse und Port an deine Installation anpassen):
Läuft das Panel auf demselben Port wie deine Kundenwebseiten, sperrst du stattdessen im Webserver den Pfad des Panels. Eine ufw-Regel auf Port 443 würde sonst alle Webseiten aussperren.sudo ufw allow from 203.0.113.10 to any port 443 proto tcp sudo ufw status numbered - Backup ziehen. Sichere Panel-Datenbank und Konfiguration, bevor du aktualisierst. Ein Update, das mitten drin abbricht, ist ohne Sicherung ein Problem.
- Update einspielen. Nutze den vom Froxlor-Projekt dokumentierten Weg für deine Installationsart. Lade Pakete nur von den offiziellen Quellen des Projekts.
- Spuren suchen. Sieh nach, ob in der Zwischenzeit jemand am System gearbeitet hat (siehe nächster Abschnitt).
- Ergebnis kontrollieren. Prüfe die Version erneut und teste von einer fremden IP, ob das Panel wirklich nicht mehr offen erreichbar ist.
Achtung: Wenn dein Panel bereits vor dem Bekanntwerden der Lücke offen im Internet stand, reicht ein Update nicht. Ein Update schließt die Lücke, entfernt aber nichts, was ein Angreifer schon hinterlegt hat. Prüfe deshalb unbedingt auch Schritt 6.
## Auf Spuren einer Übernahme prüfen
Du suchst nach Dingen, die du nicht selbst angelegt hast. Drei Stellen genügen für einen ersten Überblick:
* **Anmeldungen:** Prüfe, wer sich am Server angemeldet hat, und vergleiche mit deinen eigenen Zeiten.
* **Neue Dateien:** Suche im Web-Verzeichnis nach kürzlich geänderten PHP-Dateien.
* **Neue Konten:** Schau in der Benutzerverwaltung des Panels nach Administratoren oder Kunden, die du nicht kennst.
Die passenden Befehle:
last -a | head -20
sudo find /var/www -name '*.php' -mtime -14 -ls
sudo awk -F: '$3 == 0 {print $1}' /etc/passwdDafür: Panel nur aus dem Verwaltungsnetz erreichbar
- Scanner aus dem Internet finden die Anmeldeseite nicht mehr.
- Eine neue Lücke wird zum Problem für Wochen statt für Stunden.
- Kundenwebseiten laufen unverändert weiter.
Dagegen
- Du brauchst eine feste IP oder ein VPN, um selbst ans Panel zu kommen.
- Jemand aus dem Team, der unterwegs ist, muss sich erst verbinden.
- Die Regel muss dokumentiert sein, sonst wundert sich später jemand.
Praxistipp: Trag dir einen festen Termin ein, zum Beispiel den ersten Montag im Monat, an dem du Panel-Version und offene Systemupdates abgleichst. Zehn Minuten im Kalender sind billiger als eine Nacht mit einem übernommenen Server.
## Häufige Fehler nach so einer Warnung
* **Nur das Panel aktualisieren:** PHP und Webserver bleiben alt, obwohl sie im selben Angriffsweg liegen.
* **Kein Backup vor dem Update:** Geht etwas schief, gibt es keinen Rückweg.
* **Alte Test-Installation vergessen:** Ein zweites, ungepflegtes Panel auf einem anderen Port ist genauso angreifbar.
* **Passwörter nach einem Verdacht nicht getauscht:** Wer einmal im System war, kennt oft auch Datenbankpasswörter und Schlüssel.
* **Erst lesen, dann handeln:** Lies das Advisory, aber schränke den Zugriff auf das Panel schon vorher ein. Das dauert zwei Minuten.
## So erkennst du, dass es geklappt hat
Du bist fertig, wenn alle vier Punkte stimmen:
1. Die Panel-Version entspricht dem im Advisory oder in den Release-Hinweisen genannten fehlerbereinigten Stand oder ist neuer.
2. `apt list --upgradable` zeigt keine offenen Sicherheitsupdates mehr.
3. Von einem fremden Netz, etwa deinem Handy im Mobilfunk, kommt die Panel-Anmeldeseite nicht mehr an.
4. Die Suche nach neuen Dateien, Konten und Anmeldungen hat nichts ergeben, was du nicht kennst.
Wenn du ein DNS-Panel oder einen Nameserver auf demselben Server betreibst, wirf auch einen Blick in unseren Beitrag zu den BIND-Sicherheitslücken. Er beschreibt eine ähnliche Prüfreihenfolge.
Häufige Fragen
Bin ich von der Froxlor-Warnung betroffen, wenn ich nur Webhosting bei einem Anbieter gebucht habe?
Nur, wenn dein Anbieter Froxlor einsetzt. Dann liegt das Update bei ihm, nicht bei dir. Du kannst nachfragen, ob und wann aktualisiert wird. Betreibst du dagegen selbst einen Rootserver mit Froxlor, musst du selbst aktualisieren.
Wo finde ich die genauen betroffenen Versionen?
Im Advisory des CERT-Bund unter der Kennung WID-SEC-2026-3629 und in den Release-Hinweisen des Froxlor-Projekts. Dort stehen die verbindlichen Angaben. Vergleiche sie mit der Version, die dein Panel nach der Anmeldung anzeigt.
Reicht es, das Panel per Firewall zu sperren, statt zu aktualisieren?
Als Sofortmaßnahme ja, als Dauerlösung nein. Die Sperre verkleinert die Angriffsfläche, die Lücke bleibt aber in der Software. Aktualisiere, sobald ein fehlerbereinigter Stand vorliegt, und lass den Zugriff trotzdem eingeschränkt.
Woran merke ich, dass jemand mein Panel schon ausgenutzt hat?
Typische Hinweise sind unbekannte Administrator- oder Kundenkonten, kürzlich geänderte PHP-Dateien im Web-Verzeichnis, fremde Anmeldungen in der Ausgabe von last und zusätzliche Konten mit Root-Rechten. Findest du so etwas, setze den Server am besten neu auf und ändere alle Zugangsdaten.
