Kurz gesagt: Mit unattended-upgrades unter Debian und Ubuntu sowie dnf-automatic auf der RHEL-Familie spielen Linux-Server Sicherheitsupdates selbstständig ein. Damit ein Update auch wirkt, müssen betroffene Dienste wie PHP-FPM danach neu starten; prüfen Sie das mit needrestart oder den Prozess-Startzeiten. Drittquellen wie sury.org müssen ausdrücklich freigegeben werden, Container und Hauptversionswechsel deckt die Automatik nicht ab.
Vom Patch zum Server: Automatik spart Zeit
Als php.net am 21. Oktober 2026 um 16 Uhr deutscher Zeit die Patches gegen PHP2Shell veröffentlichte, begann für Administratoren ein Wettlauf. Laut Berichten lieferten Distributionen ihre Backports teils noch am selben Tag aus. Server mit automatischen Sicherheitsupdates konnten die neuen Pakete beim nächsten planmäßigen Lauf installieren, ohne dass jemand eingreifen musste.
Das ist die gute Nachricht. Die weniger gute: Installiert heißt nicht wirksam. Ein PHP-FPM-Dienst, der seit Wochen läuft, arbeitet mit dem alten Code im Speicher weiter, bis er neu gestartet wird. Und Pakete aus Drittquellen, Container oder Hosting-Panels mit eigener PHP-Verwaltung bleiben von der Automatik oft unberührt.
Dieser Beitrag zeigt, wie Sie automatische Sicherheitsupdates einrichten und so ergänzen, dass sie im Ernstfall wirklich schützen.
unattended-upgrades unter Debian und Ubuntu
Unter Ubuntu ist das Paket unattended-upgrades standardmäßig installiert und spielt Sicherheitsupdates ein. Unter Debian installieren Sie es bei Bedarf nach. Gesteuert wird es über zwei Dateien unter /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Die Datei 20auto-upgrades legt fest, ob und wie oft Paketlisten aktualisiert und Updates eingespielt werden. Der Wert ist die Anzahl der Tage, "1" bedeutet täglich:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
In 50unattended-upgrades steht, aus welchen Quellen Updates kommen dürfen, ob danach neu gestartet wird und wer eine Nachricht erhält. Standardmäßig sind nur die offiziellen Sicherheitsquellen der Distribution freigegeben. Laut Ubuntu-Dokumentation reicht es nicht, ein weiteres Repository einzubinden: Es muss zusätzlich in dieser Liste stehen, sonst wird es von der Automatik ignoriert. Das betrifft zum Beispiel das Drittanbieter-Repository sury.org, das laut Berichten PHP-Builds für alle Zweige von 5.6 bis 8.5 bereitgestellt hat. Hintergründe stehen im Beitrag Das sury.org-Repository.
Ob alles stimmt, zeigt ein Probelauf, der nichts verändert:
sudo unattended-upgrade -v --dry-run
# Protokolle der echten Läufe
ls -l /var/log/unattended-upgrades/
dnf-automatic auf RHEL, AlmaLinux und Rocky Linux
Auf der RHEL-Familie übernimmt dnf-automatic dieselbe Aufgabe. Die Konfiguration liegt in /etc/dnf/automatic.conf. Laut Dokumentation prüft upgrade_type = security nur Updates mit Sicherheitshinweis, und apply_updates ist standardmäßig ausgeschaltet.
# /etc/dnf/automatic.conf (Auszug)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'
Neben dnf-automatic.timer, der der Konfigurationsdatei folgt, gibt es Timer, die nur melden, nur herunterladen oder immer installieren. Für den Anfang ist der Timer mit Konfigurationsdatei am besten nachvollziehbar.
Der unterschätzte Teil: Dienste neu starten
Die Paketverwaltung ersetzt Dateien auf der Festplatte. Laufende Prozesse behalten den alten Code im Speicher. Bei PHP heißt das: Solange PHP-FPM oder Apache mit mod_php nicht neu gestartet sind, bleibt die Lücke offen.
| Werkzeug | System | Was es tut |
|---|---|---|
| needrestart | Debian, Ubuntu | erkennt Dienste mit veralteten Dateien; startet sie unter Ubuntu ab 24.04 standardmäßig automatisch neu |
dnf needs-restarting -s |
RHEL-Familie | listet Dienste, die neu gestartet werden sollten |
Automatic-Reboot |
unattended-upgrades | startet den Server neu, wenn ein Update es verlangt; standardmäßig aus |
reboot |
dnf-automatic | never, when-changed oder when-needed |
Laut Ubuntu-Dokumentation laufen Dienste, die von needrestart ausgenommen sind, bis zum manuellen Neustart mit alten Dateien weiter. Prüfen Sie deshalb nach jedem PHP-Update die Startzeit der Prozesse, wie unter PHP-FPM und alle Worker neu starten beschrieben.
Bei Backports bleibt die angezeigte PHP-Versionsnummer oft gleich. Den Patch belegen Sie über den Paket-Changelog mit den CVE-Nummern, etwa mit apt-get changelog oder rpm -q --changelog. Wie das im Detail geht, zeigt Debian und Ubuntu: Ist mein PHP-Paket gepatcht?.
Was die Automatik nicht abdeckt
Automatische Updates sind ein Baustein, kein vollständiges Patch-Management. Einige Bereiche brauchen eigene Abläufe:
- Container: PHP in Docker-Images wird durch Host-Updates nicht aktualisiert. Images neu bauen, Container neu erstellen.
- Hosting-Panels: Plesk, cPanel und ähnliche Panels verwalten PHP teils über eigene Pakete und Mechanismen.
- Hauptversionen: Der Wechsel etwa von PHP 8.2, das am 31.12.2026 das Ende der Unterstützung erreicht, auf eine neuere Version passiert nicht automatisch.
- Anwendungen: CMS, Plugins und Composer-Abhängigkeiten haben eigene Update-Wege.
- Kontrolle: Jemand muss Protokolle und Fehlermeldungen der Automatik lesen. Ein still fehlschlagender Lauf ist schlimmer als keiner, weil er Sicherheit vortäuscht.
Wie diese Teile zu einem Prozess zusammenwachsen, beschreibt Patch-Management als Prozess statt Feuerwehr.
Fazit: Automatik ja, blindes Vertrauen nein
Automatische Sicherheitsupdates gehören auf jeden Linux-Server, der aus dem Internet erreichbar ist. PHP2Shell hat gezeigt, wie knapp die Zeit werden kann: Laut Medienberichten wurde ein erster Angriffsversuch bereits am 17. Oktober beobachtet, vier Tage vor den Patches. Wer danach noch auf ein manuelles Wartungsfenster wartet, verliert wertvolle Zeit.
Die Automatik nimmt Ihnen aber nur das Einspielen ab. Neustart der Dienste, Nachweis des Patchstands, Container, Panels und der rechtzeitige Wechsel auf unterstützte Versionen bleiben Aufgaben, für die jemand zuständig sein muss. Legen Sie diese Zuständigkeit schriftlich fest, und prüfen Sie stichprobenartig, ob die Protokolle der Automatik tatsächlich gelesen werden. Erst die Kombination aus Automatik und Kontrolle macht Updates verlässlich.
Wie hilft PHP SOS konkret?
- Einrichten: Wir konfigurieren unattended-upgrades oder dnf-automatic passend zu Ihren Servern, einschließlich freigegebener Drittquellen.
- Neustarts absichern: Wir richten needrestart oder entsprechende Prüfungen ein und kontrollieren nach PHP-Updates die Prozess-Startzeiten.
- Lücken schließen: Container, Panels und Hauptversionswechsel nehmen wir in einen festen Wartungsablauf auf.
- Kontrollieren: Im Security-Wartungsvertrag prüfen wir Protokolle der Automatik und melden Auffälligkeiten.
Häufige Fragen
Sind automatische Updates auf Produktivservern nicht zu riskant?
Beschränkt auf Sicherheitsupdates der Distribution ist das Risiko meist kleiner als das einer offenen Lücke. Diese Updates sollen keine neuen Funktionen bringen, sondern Fehler beheben. Für kritische Systeme gehören Sicherungen, Überwachung und ein Testsystem dazu.
Startet unattended-upgrades PHP-FPM nach einem Update neu?
Nicht unbedingt selbst. Unter Ubuntu startet ab Version 24.04 das Werkzeug needrestart betroffene Dienste standardmäßig automatisch neu, ausgenommene Dienste laufen aber mit alten Dateien weiter. Prüfen Sie nach jedem PHP-Update die Startzeit aller PHP-Prozesse.
Werden Pakete aus sury.org oder anderen Drittquellen automatisch aktualisiert?
Nur wenn Sie die Quelle ausdrücklich freigeben. Laut Ubuntu-Dokumentation reicht es nicht, ein Repository hinzuzufügen; es muss zusätzlich in der Liste der erlaubten Herkünfte von unattended-upgrades stehen.
Hebt die Automatik auch PHP 8.2 auf 8.3 an?
Nein. Automatische Sicherheitsupdates bleiben innerhalb der installierten Paketversionen. Ein Wechsel der PHP-Hauptversion, etwa vor dem Ende der Unterstützung für PHP 8.2 am 31.12.2026, bleibt ein geplantes Projekt mit Tests.
Was ist mit Docker-Containern?
Updates auf dem Host aktualisieren die PHP-Version in Containern nicht. Container-Images müssen neu gebaut oder neu gezogen und die Container neu erstellt werden.