PHP-Sicherheitsupdate Oktober 2026: So prüfst du deine Version und updatest
Du hast unter meinem Video PHP kommentiert? Dann ist das hier deine Checkliste. Am 21. Oktober 2026 hat das PHP-Team ein kritisches Sicherheitsupdate veröffentlicht. Es schließt zwei Lücken, über die Angreifer ohne Login eigenen Code auf deinem Webserver ausführen können. Betroffen ist so gut wie jede Website, die mit PHP läuft, also auch jede WordPress-Seite. Mit dieser Checkliste findest du heraus, welche PHP-Version du hast und wie du das Update auf den üblichen Setups einspielst. Ich habe meinen eigenen Webserver genau so aktualisiert.
Kurz erklärt
- Es geht um zwei Lücken, CVE-2026-109618 und CVE-2026-109619. Beide hat das PHP-Team mit 9,2 von 10 bewertet (CVSS v4.0, eine Standard-Skala für den Schweregrad).
- Behoben sind sie in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Alles darunter ist betroffen, egal ob PHP-FPM, Apache mit mod_php oder ein anderes Setup.
- Am höchsten ist das Risiko laut PHP bei Apache mit mod_php. Dafür gibt es schon einen vorgeführten Exploit (also funktionierenden Angriffscode).
- PHP 8.1 und älter bekommen vom PHP-Projekt keine Updates mehr. PHP 8.2 ist am 31. Dezember 2026 am Ende.
Was du brauchst
- Einen Admin-Login für WordPress oder für das Panel deines Hosters.
- Bei einem eigenen Server: ein Terminal per SSH (verschlüsselter Fernzugriff auf die Kommandozeile) und sudo-Rechte.
- Ein aktuelles Backup, bevor du etwas aktualisierst.
Schritt 1: PHP-Version herausfinden
Am einfachsten geht es in WordPress: Werkzeuge → Website-Zustand, dann oben den Reiter Bericht (englisch Info) und dort den Abschnitt Server aufklappen. Da steht die PHP-Version. Bei Shared Hosting (du teilst dir einen Server mit anderen Kunden und hast nur ein Webpanel) findest du die Version auch im Kundenbereich deines Hosters.
Hast du einen eigenen Server, geht es im Terminal:
php -v
php-fpm8.3 -vphp -v zeigt nur die Kommandozeilen-Version. Deine Websites laufen meist über PHP-FPM (der Dienst, der PHP für den Webserver ausführt), und das ist ein eigenes Paket. Unter Debian und Ubuntu heißt der Befehl php-fpm8.3 mit deiner Versionsnummer (welche du hast, zeigt ls /usr/sbin/php-fpm*), unter RHEL und AlmaLinux einfach php-fpm -v. Eine phpinfo()-Datei zeigt es auch, aber lösch sie direkt danach wieder, weil sie Fremden viel über deinen Server verrät.
Schritt 2: Updaten
Debian und Ubuntu mit den Paketen der Distribution: Die Security-Teams bauen den Fix in ihre eigene Version ein (das nennt man Backport). Die Versionsnummer sieht dann älter aus als die von php.net, obwohl die Lücke zu ist. Vergleich also nicht mit den Nummern von php.net. Schau stattdessen im Debian Security Tracker oder in der CVE-Datenbank von Ubuntu nach den beiden CVE-Nummern, oder im Changelog des Pakets. Der zweite Befehl unten sucht genau danach. Kommt eine Zeile mit einer der beiden CVE-Nummern, ist der Fix drin. Das Update selbst:
sudo apt update && sudo apt upgrade
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'Debian und Ubuntu mit dem Repository von Ondřej Surý (packages.sury.org oder das PPA ondrej/php, beliebt für neuere PHP-Versionen): Hier folgen die Nummern denen von php.net. Nach apt upgrade sollte also 8.3.36 oder die passende Nummer für deine Version dastehen.
RHEL und AlmaLinux: Mit den PHP-Paketen der Distribution läuft es wie bei Debian über sudo dnf upgrade und Backports. Nutzt du das Remi-Repository (rpms.remirepo.net), lies genau: Das PHP-Team schreibt, dass Remi am Tag der Veröffentlichung noch keine Updates hatte, und rät, auf Pakete der Distribution umzusteigen oder selbst zu bauen. Prüf mit php-fpm -v, ob die neue Nummer wirklich angekommen ist.
Docker mit den offiziellen php-Images: Ein Tag wie 8.3-fpm zeigt auf die neue Version, sobald das offizielle Image neu gebaut ist. Nutzt du das Image direkt, reicht docker compose pull und danach docker compose up -d. Hast du ein eigenes Dockerfile mit FROM php:…, baust du mit docker compose build --pull neu und startest dann mit docker compose up -d. Prüf danach im Container mit docker compose exec app php -v (app ersetzt du durch den Namen deines PHP-Services).
Shared Hosting und Managed WordPress: Hier spielt der Hoster das Update ein. Schau im Panel nach der genauen Version oder frag beim Support nach, ob die Fixes vom 21. Oktober drauf sind.
Plesk: Unter Tools & Einstellungen → Updates startest du den Plesk Installer und aktualisierst die installierten Komponenten, dazu gehören auch die PHP-Versionen von Plesk. Auf einem Server mit dnf kann es dabei gerade zu „GPG check FAILED“ kommen, dazu mehr unten bei den Problemen.
Schritt 3: Neu starten und prüfen
Ein Update auf der Platte nützt nichts, solange die alten PHP-Prozesse weiterlaufen. Starte PHP-FPM neu, bei mod_php den Apache:
sudo systemctl restart php8.3-fpm # Debian/Ubuntu, Nummer anpassen
sudo systemctl restart php-fpm # RHEL/AlmaLinux
sudo systemctl restart apache2 # mod_php unter Debian/Ubuntu (RHEL: httpd)
sudo systemctl restart 'plesk-php*-fpm*' # Plesk unter LinuxDanach prüfst du die Version noch einmal wie in Schritt 1, am besten in WordPress unter Website-Zustand, weil du da siehst, was die Website wirklich benutzt. Dann öffnest du deine Seiten einmal im Browser und klickst dich kurz durch.
Wenn du auf PHP 8.1 oder älter bist
Für 8.1 und älter gibt es vom PHP-Projekt kein Update. Manche Distributionen und LTS-Anbieter liefern Backports, frag also zuerst bei deinem Anbieter. Der saubere Weg ist ein Upgrade auf eine unterstützte Version, aktuell 8.3 oder neuer, weil 8.2 Ende 2026 ausläuft. Mach vorher ein Backup, teste in einer Staging-Kopie (eine Testkopie deiner Seite) und aktualisiere Theme und Plugins zuerst.
Die Notlösungen aus dem Advisory wie memory_limit=-1 oder session.upload_progress.enabled=0 verkleinern nur einzelne Angriffswege. Laut PHP machen sie eine Installation nicht sicher. Sie sind höchstens eine Brücke für die Stunden bis zum Update.
So sah das bei mir aus
Auf meinem Webserver laufen rund 30 Websites mit PHP 8.2 und 8.3, verwaltet mit Plesk. Automatische Updates waren an, trotzdem war nichts aktualisiert. Das Update ist bei mir zuerst mit dem GPG-Fehler abgebrochen, weil Plesk einen neuen Signaturschlüssel benutzt. Nachdem ich den offiziellen Schlüssel importiert hatte, ging es durch: 8.2.34 auf 8.2.35 und 8.3.35 auf 8.3.36. Die Seiten waren nach ein paar Sekunden wieder da, und ich habe danach alle einmal aufgerufen. Automatische Updates eingeschaltet heißt eben nicht, dass auch alles aktuell ist.
Häufige Probleme
„GPG check FAILED“ unter Plesk mit dnf: dnf kennt den Schlüssel nicht, mit dem die neuen Plesk-Pakete signiert sind (die Signatur beweist, dass ein Paket wirklich von Plesk stammt). Eine offizielle Ankündigung dazu habe ich bei Plesk nicht gefunden, deshalb hier mein Weg. Plesk veröffentlicht alle Schlüssel in der Datei plesk.gpg. Ich habe mir die Datei erst angesehen, geprüft, dass der neue Schlüssel mit der ID 5B6AB2160B50DB96 vom 18. August 2026 als „Plesk Team“ drinsteht, und ihn erst dann importiert:
curl -s https://autoinstall.plesk.com/plesk.gpg | gpg --show-keys
sudo rpm --import https://autoinstall.plesk.com/plesk.gpgDer erste Befehl zeigt nur an und ändert nichts. Der Fingerabdruck des neuen Schlüssels muss auf 5B6AB2160B50DB96 enden. Stimmt das nicht, importier nichts und frag beim Plesk-Support nach. Danach startest du das Update einfach noch einmal.
Die Version ist nach dem Update noch alt: Meist läuft der alte PHP-FPM-Prozess noch. Neu starten wie in Schritt 3. Bei Debian und Ubuntu mit Distributionspaketen kann die Nummer auch korrekt alt aussehen, dann zählt der Eintrag im Security Tracker.
Fazit
Version prüfen, updaten, PHP-FPM oder Apache neu starten, Version noch einmal prüfen und die Seiten aufrufen. Du hast auch einen Plex-Server? Dann schau dir meine Checkliste zu Plex2Shell an. Neue Guides und Sicherheitswarnungen wie diese bekommst du über meinen Newsletter.
Hat dir der Guide geholfen? Dann spendier mir gern einen Kaffee auf Ko-fi. Damit bleibt MappleBox werbefrei.
