ISPConfig 3.3.2: Sicherheitsupdate mit wichtigen Änderungen
ISPConfig 3.3.2 ist seit dem 18. September 2026 verfügbar und bringt deutlich mehr als ein paar kleine Bugfixes: zwei sicherheitsrelevante Lücken, Ubuntu-26.04-Unterstützung, erzwingbares DMARC und eine getrennte Absenderadresse für Systemmails. Wir setzen ISPConfig seit Jahren als Control Panel für unsere Kunden ein und haben uns das Release genau angesehen.
Backup → Update → p1 → Testen
SICHERHEIT
Zwei sicherheitsrelevante Probleme wurden behoben
ISPConfig nennt in den Release Notes zwei Sicherheitslücken ausdrücklich. Bei einem Control Panel, über das Kunden Websites, Mailboxen, DNS-Zonen und Datenbanken verwalten, schauen wir bei so einem Release zuerst auf die Angriffsfläche, nicht auf neue Funktionen.
Rechteausweitung über Fetchmail
Über manipulierte Werte in einem Fetchmail-Konto ließen sich zusätzliche Konfigurationsabschnitte in die getmail-Konfiguration einschleusen, weil die Eingaben nicht ausreichend geprüft wurden. ISPConfig entfernt jetzt Zeilenumbrüche und Nullbytes, prüft das Ziel auf eine gültige E-Mail-Adresse und verhindert, dass die getmail-Konfiguration über Symlinks außerhalb des vorgesehenen Verzeichnisses geschrieben oder gelöscht wird. Gemeldet von Arvin Shivram (Brutecat Security).
Für ein Hosting-Panel ist das keine Kleinigkeit: Hier geht es um die Grenze zwischen Kundendaten und den vom Server ausgeführten Mail-Tools.
SQL Injection in der Remote API — CVE-2026-61518
In der Remote API wurde die primary_id bei Update- und Delete-Funktionen ohne Integer-Prüfung und ohne Parameter-Platzhalter direkt in die SQL-Abfrage übernommen. Ein authentifizierter API-Nutzer mit irgendeiner, auch geringen API-Berechtigung konnte dadurch Datensätze außerhalb seines eigentlichen Bereichs verändern oder löschen und Daten aus anderen Tabellen auslesen. ISPConfig hat die betroffenen Abfragen auf Integer-Prüfung und Parameter-Platzhalter umgestellt. Gemeldet von Nguyen Chi Quang (MBBank).
Die Lücke ist als CVE-2026-61518 veröffentlicht, CVSS 3.1: 8.8 (High). Voraussetzung bleibt eine authentifizierte Remote-API-Nutzung, aber schon eine einzelne, geringe Berechtigung reichte laut Analyse aus, weil der eingebaute SQL-Injection-Scanner der API bestimmte Payloads nicht blockiert. Das ist kein Zugriff ohne Anmeldung, sollte bei einem Hosting-Panel mit Remote-API-Zugängen aber keinesfalls unterschätzt werden.
WICHTIG
Patch 3.3.2p1: unbedingt mit einspielen
Am 21. September 2026, drei Tage nach 3.3.2, ist der Patch 3.3.2p1 erschienen. Er behebt unter anderem ein Problem, das bei frisch aktualisierten Servern die Mailzustellung stören kann.
rspamd startete nicht mehr
Das Update benennt die nicht mehr benötigte users.conf um, hat den zugehörigen Include in rspamd.conf aber nur entfernt, wenn die Zeile mit einem Zeilenumbruch endete. Ältere ISPConfig-Versionen hängten die Zeile ohne Umbruch an, deshalb blieb sie auf den meisten Servern stehen und zeigte auf eine nicht mehr existierende Datei. rspamd startete danach nicht mehr. Betroffene Server werden durch das Update repariert.
Quota-Überwachung
Bei überschrittenem Soft-Limit las die Datenträger-Überwachung die falsche Spalte der repquota-Ausgabe und konnte den kompletten ISPConfig-Cron-Lauf auf PHP 8 abbrechen.
Weitere Fixes
Fehlende Spalte in sys_cron auf älteren MySQL/MariaDB-Versionen, Datenbank-Benutzer wurden dort teils nicht angelegt, und Mailboxen, Aliase und Weiterleitungen konnten bei gleichnamigen Maildomains auf mehreren Mailservern auf dem falschen Server landen.
Kurz gesagt: Wer bereits auf 3.3.2 aktualisiert hat, sollte zeitnah auch den Patch p1 einspielen. Bei einer Neuinstallation oder einem noch ausstehenden Update empfehlen wir, gleich auf den aktuellen Stand zu gehen.
WEITERE FIXES
Passwort-Reset-Link und Code-Audit
Neben den beiden benannten Lücken enthält 3.3.2 eine Reihe weiterer sicherheitsrelevanter Änderungen, unter anderem aus einem Code-Audit von siteguardian.io.
Passwort-Reset-Link zeigte auf falschen Host
Der Link in der Passwort-Reset-Mail wurde bisher aus dem HTTP-Host-Header der Anfrage gebaut. Unter Umständen hätte ein Angreifer damit einen Reset-Link erzeugen können, der auf einen fremden Host zeigt. In 3.3.2 wird stattdessen interface_base_url verwendet, sofern gesetzt, andernfalls der Hostname des Servers. Ist das Panel unter einem anderen Hostnamen erreichbar als der Servername, sollten wir interface_base_url kontrollieren.
CSRF und Sessions
CSRF-Schutz ergänzt für Backup-Aktionen, DNS-Zonen-Import, Extension-Verwaltung und den vpopmail-Import. Die Session-ID wird beim Login neu erzeugt, CSRF-Token-Timeouts werden konsequent geprüft.
Downloads und Pfade
TLS-Zertifikatsprüfung beim Download von Extensions und APS-Paketen ist wieder aktiv, Pfad-Traversal bei APS-Paketen wird verhindert.
Eingaben und Vergleiche
Shell-Argumente in PowerDNS-DNSSEC-, certbot- und PostgreSQL-Größenbefehlen werden escaped, unserialize() lässt keine Objekte mehr zu, E-Mail-Header sind gegen CRLF-Injection geschützt, Passwort-Hashes und CSRF-Token werden mit Constant-Time-Vergleichen geprüft, und Whitelist- sowie HTML-Field-Berechtigungen werden jetzt nach Benutzertyp durchgesetzt.
NEUERUNGEN
Was für den Hosting-Alltag interessant ist
Ubuntu 26.04
ISPConfig 3.3.2 unterstützt Ubuntu 26.04 LTS inklusive der geänderten Dovecot-2.4-Konfigurationssyntax. Das ist kein Freibrief für ein Distributions-Upgrade bestehender Server: Betriebssystem-Upgrade und ISPConfig-Update bleiben zwei getrennte Wartungsarbeiten.
DMARC serverseitig erzwingen
Rspamd kann jetzt die eingehende DMARC-Policy einer Absenderdomain durchsetzen und Mails ablehnen oder in Quarantäne stellen. Wir würden das nicht blind für jede bestehende Installation aktivieren, sondern vorher auf die bisherige Rspamd- und SPF/DKIM-Konfiguration der Kunden-Domains schauen.
Getrennte Absenderadresse
Bisher diente eine Adresse als Empfänger und Absender für Systemmails. Jetzt gibt es admin_mail (Empfänger, Reply-Adresse) und server_sender_mail (tatsächlicher Absender), zum Beispiel für Quota-, Traffic- und Reset-Mails. Beim Update wird die neue Adresse zunächst mit der bisherigen Administratoradresse befüllt, bestehende Installationen verhalten sich also zunächst unverändert.
Backups ohne Table Locks
mysqldump kann jetzt mit --single-transaction laufen. Im Standard „Automatic“ prüft ISPConfig die Storage Engines: Sind alle Tabellen transaktional (InnoDB), entfällt der Table Lock. Bei MyISAM oder MEMORY bleibt es beim bisherigen Verfahren, weil ein lockfreier Dump dort nicht konsistent wäre.
Neue Websites ohne eigene Error Pages
Custom Error Pages sind bei neu angelegten Websites jetzt standardmäßig deaktiviert. Bestehende Websites ändert das Update nicht.
Sonstiges
Extensions können jetzt eigene Client- und Reseller-Limits registrieren, ohne Core-Dateien zu patchen, und die Liste der CAA-Zertifizierungsstellen wurde aktualisiert.
AUCH BEHOBEN
Eine Reihe weiterer Fixes
Daneben wurde eine Reihe von Fehlern korrigiert, die im Hosting-Alltag durchaus auffallen können:
- Bei einem Formularfehler konnte ein Reseller versehentlich einen fremden Kunden übernehmen (Auswahlfeld sprang auf den ersten Eintrag der Liste zurück).
- BIND konnte unter Ubuntu 24.04 mit AppArmor keine Zonendateien für sekundäre DNS-Zonen schreiben.
- Änderungen am Rspamd-Greylisting wurden teils erst nach einem Resync aktiv.
- Ein Traffic-Limit von 0 ließ sich umgehen und hebelte damit die automatische Deaktivierung bei Überschreitung aus.
- Ein DivisionByZeroError in den Traffic-Statistiken unter PHP 8.x.
- PHP-FPM wurde beim Löschen einer Website teils nicht korrekt neu geladen.
- Das Datenbankfeld für SSH-Keys war bei langen Kommentaren zu klein.
- .htaccess-Dateien konnten beim Ändern des Verzeichnisschutzes root:root gehören statt dem Website-Benutzer.
- Mailrouting konnte in Multiserver-Installationen mit gleichnamiger Maildomain auf mehreren Servern auf den falschen Server geraten.
FÜR DEN BETRIEB
Was das für einen laufenden Hostingbetrieb bedeutet
Für eine einzelne private Installation würden wir das Update unkompliziert einspielen. Bei einer Hostingplattform mit vielen Kunden gehen wir strukturierter vor.
Vor dem Update
Aktuelle Version prüfen, Backup von Datenbank und Konfiguration sicherstellen, Remote-API-Nutzer und deren Rechte prüfen, kontrollieren ob Fetchmail genutzt wird, interface_base_url kontrollieren, bestehende Mail- und Rspamd-Konfiguration und eigene Anpassungen berücksichtigen.
Bei Multiserver-Installationen
Laut ISPConfig-Dokumentation zuerst den Master aktualisieren, danach die Slave-Server, und dabei den Maintenance Mode entsprechend berücksichtigen.
Danach testen
Login als Admin und als Kunde, Website anlegen und PHP-Version wechseln, Datenbank anlegen, DNS-Zone bearbeiten, Mailbox anlegen, Passwort zurücksetzen, Fetchmail (falls genutzt), Let’s Encrypt, Backup und Restore, Cronjobs, Remote API, Reseller-Funktionen, Rspamd und Mailzustellung, Master-Slave-Synchronisation.
UPDATE
ISPConfig aktualisieren
Für produktive Hostingserver bevorzugen wir den normalen ISPConfig-Updater, mit vorherigem Backup und Wartungsplan. Als root auf dem Server:
Update auf 3.3.2 (und p1)
cd /tmp
wget https://www.ispconfig.org/downloads/ISPConfig-3.3.2.tar.gz
tar xvfz ISPConfig-3.3.2.tar.gz
cd ispconfig3_install/install
php -q update.phpAlternativ steht ispconfig_update.sh zur Verfügung. Da der Patch p1 wichtige Nachbesserungen enthält (siehe oben), sollte man nach dem Update prüfen, ob p1 bereits enthalten ist, und andernfalls zeitnah nachziehen. Der vollständige Changelog steht im ISPConfig-Git.
Unterstützte Distributionen: Debian 11–13 und Debian Testing, Ubuntu 22.04–26.04 LTS, AlmaLinux 8–10, Rocky Linux 8–10, CentOS 8.
FAZIT
Erst Security- und Stabilitätsrelease, dann Feature-Update
Ubuntu 26.04, DMARC Enforcement und die neue Absenderadresse für Systemmails sind die sichtbaren Neuerungen. Im Hintergrund wurden aber gerade an den Stellen viele Änderungen vorgenommen, die für einen Hostingbetrieb entscheidend sind: Remote API, Fetchmail, Passwort-Reset, CSRF, Sessions, Paketdownloads, Pfadvalidierung und verschiedene Rechteprüfungen.
Besonders die SQL Injection in der Remote API und die Rechteausweitung über Fetchmail sind für einen ISPConfig-Server mit mehreren Kunden relevant. Die Kombination aus Kundenzugängen, Resellern und API-Integrationen macht ein Control Panel zu einer sensiblen Komponente der gesamten Hosting-Infrastruktur.
Unser Vorgehen: 3.3.2 gehört auf die normale Wartungsliste und sollte zeitnah eingespielt werden, inklusive Patch p1, mit Backup und einem kurzen Funktionstest danach. Ein Control Panel, über das viele Kunden ihre Websites und Mailkonten verwalten, ist kein Tool, das man einmal installiert und dann vergisst — es ist Teil der Sicherheitsgrenze des gesamten Servers.
Control Panel sicher betreiben?
Ob ISPConfig-Update, Backup oder Absicherung Ihres Hostingservers: Nutzen Sie unsere IT-Leistungen.
