Kritische PHP-Schwachstellen: Das Update darf nicht warten

Am 21. Oktober 2026 hat das PHP-Team außerplanmäßige Updates veröffentlicht, und die europäische Stelle für die Reaktion auf Cybervorfälle CERT-EU hat eine Dringlichkeitswarnung herausgegeben. Der Grund: zwei Schwachstellen mit der Gefährdungsbewertung 9,2 von 10, die es Angreifern erlauben, eigenen Code auf Ihrem Server auszuführen. Ohne Benutzernamen, ohne Passwort und ohne eine einzige Handlung Ihrer Mitarbeitenden.

PHP ist die Sprache, in der der größte Teil des Webs geschrieben ist: WordPress, Joomla, OpenCart, Bitrix, Laravel und hunderte selbst geschriebene Skripte, die eine Website mit CRM, E-Mail oder der Warenwirtschaft verbinden. Läuft Ihre Website nicht auf PHP, können Sie diesen Artikel schließen. Wissen Sie nicht, worauf sie läuft, ist schon das ein Anlass, die betreuende Stelle zu fragen.

Was genau gefunden wurde

Es sind zwei Schwachstellen, beide mit 9,2 Punkten bewertet, und beide führen zum gleichen Ergebnis: Ausführung fremden Codes auf dem Server ohne Anmeldung.

CVE-2026-109618 — Abbruch bei Speichermangel

PHP kennt die Einstellung memory_limit: Eine Anfrage, die zu viel Speicher verbraucht hat, wird zwangsweise abgebrochen. Das Problem liegt darin, wie sie abgebrochen wird. PHP kann in einem Augenblick abbrechen, in dem die internen Daten der Anfrage nur halb gefüllt sind — etwa während eine über ein Upload-Formular geschickte Datei verarbeitet wird. Die Aufräumarbeit nach so einer Anfrage hält die halbfertigen Daten für echt und versucht Speicher freizugeben, den es nie gab. Und in diesem Speicher kann liegen, was Angreifer mit früheren Anfragen dort abgelegt haben.

CVE-2026-109619 — Reste der vorigen Anfrage

Die zweite Lücke besagt, dass der Server den vorigen Besucher nicht ganz „vergisst“. Interner Zustand, der zu einer Anfrage gehörte, überlebt die Speicherfreigabe mitunter — etwa nach einem fatalen Fehler. Die nächste Anfrage, die in denselben Arbeitsprozess gerät, kann diese Reste nutzen, noch bevor die gewöhnliche Initialisierung sie auf Null setzt.

Gefährdet ist jede PHP-Installation, die Webanfragen bedient: PHP-FPM, Apache mit dem Modul mod_php, php-cgi, FrankenPHP, LiteSpeed. Als riskanteste Kombination nennt das PHP-Team genau Apache mit mod_php — und sie ist bei vielen günstigen Hostings bis heute Standard.

Der Demonstrations-Exploit greift mit einer einzigen nicht angemeldeten Anfrage — noch bevor der Code der Website selbst zu laufen beginnt. Das heißt: Sicherheits-Plugins, komplizierte Passwörter und Zwei-Faktor-Anmeldung helfen hier nicht, der Angriff findet eine Ebene tiefer statt.

Welche Versionen betroffen sind

Alles unterhalb dieser Versionen ist angreifbar:

PHP-Reihe	Sichere Version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 und älter	kein Support mehr

Eine eigene Risikokategorie sind kommerzielle und offene Produkte mit eingebettetem PHP, das von außen nicht zu sehen ist: Verwaltungsoberflächen, Netzwerkgeräte, Videoüberwachungssysteme, Unternehmensportale. Eine Liste solcher Software wird im Repository des niederländischen NCSC geführt.

Warum „wir haben eine kleine Website“ hier nicht gilt

Niemand sucht Ihre Website gezielt. Sobald Beispiele für die Ausnutzung öffentlich sind — und sie sind es schon —, starten innerhalb von Stunden automatische Scanner, die das gesamte Internet der Reihe nach durchprobieren. Ihnen ist gleich, ob es die Seite eines Werks oder die eines Friseursalons ist: Es zählt nur, ob der Server mit einer angreifbaren Version antwortet.

Danach folgt das übliche Drehbuch: Eine Web-Shell landet auf dem Server, die Website verteilt Spam oder Seiten fremder Werbung, die Domain gerät auf Sperrlisten, und E-Mails von ihr kommen nicht mehr an. Den Schaden rechnet dabei nicht die angreifende Seite aus, sondern die, die die Website zum Arbeiten braucht.

Was zu tun ist — Schritt für Schritt

1. Finden Sie Ihre Version heraus. In der Hosting-Verwaltung ist das der Bereich „PHP-Version“ oder „PHP Selector“; auf dem eigenen Server der Befehl php -v. Wichtig ist, die Version zu prüfen, mit der die Website arbeitet, nicht die auf der Kommandozeile: Sie unterscheiden sich häufig.
2. Aktualisieren Sie innerhalb Ihrer Reihe. Der Schritt von 8.2.29 auf 8.2.35 ist eine Korrektur innerhalb einer Reihe: Die Kompatibilität bleibt, die Website bricht davon nicht. Verwechseln Sie das nicht mit dem Schritt von 8.2 auf 8.4 — der will geprüft werden.
3. Läuft bei Ihnen 8.1 oder älter, gibt es für diese Reihen keinen Support. Wegen der Schwere der Lage hat das PHP-Sicherheitsteam minimale Korrekturen auch für 7.4, 8.0 und 8.1 veröffentlicht, und manche Hoster pflegen eigene Builds. Die richtige Entscheidung ist jedoch der Umzug auf eine unterstützte Reihe — besser jetzt geplant als beim nächsten Mal.
4. Starten Sie die Handler neu. Ohne Neustart von php-fpm oder Apache laufen die Arbeitsprozesse weiter mit dem alten Code, und das Update wirkt faktisch nicht.
5. Prüfen Sie das Ergebnis. Am einfachsten über eine vorübergehende Seite mit phpinfo(), die unmittelbar nach der Prüfung zu löschen ist, oder über den Bereich „PHP-Version“ in der Verwaltung nach dem Neuladen.

Hosting-Kunden müssen meist nichts von Hand tun: Die großen Anbieter haben die Korrekturen vorab erhalten und aktualisieren ihre Maschinen selbst. Es lohnt, dem Support eine Zeile zu schreiben — „Ist PHP auf die Versionen vom 21. Oktober 2026 aktualisiert?“ — und die Antwort schriftlich zu bekommen.

Wenn sich jetzt nicht aktualisieren lässt

Manchmal ist die Website alt und das Update braucht Vorbereitung. Dann gibt es befristete Maßnahmen, die das Angriffsfenster verengen:

• Speicherüberlauf als Einstiegspunkt verbieten: memory_limit=-1 so gesetzt, dass die Anwendung es nicht überschreiben kann, plus die Prüfung, dass kein Pool und kein Verzeichnis das Limit wieder einführt;
• post_max_size verkleinern — 8M für Websites ohne Datei-Uploads, 32M, wenn Uploads nötig sind — und upload_max_filesize darunter halten;
• session.upload_progress.enabled abschalten und alle Arbeitsprozesse neu starten;
• unter PHP 8.5 zusätzlich fatal_error_backtraces abschalten;
• Größe und Komplexität der Anfragen auf Ebene des Webservers oder Proxys begrenzen.

Keine dieser Maßnahmen macht eine Installation sicher. Sie versperren nur die bekannten Wege — vollständig löst das Problem allein das Update.

Ist auch das unmöglich, rät CERT-EU zur einfachen und unbeliebten Lösung: den angreifbaren Dienst aus dem öffentlichen Internet nehmen, bis die Korrektur installiert und geprüft ist.

Woher diese Angaben stammen

• CERT-EU, Security Advisory 2026-018 „Critical Vulnerabilities in PHP“
• Die Ankündigung der Updates auf php.net
• Die technische Beschreibung von CVE-2026-109618 und CVE-2026-109619

---

Sie wissen nicht, welche PHP-Version auf Ihrer Website läuft und wer sie aktualisieren muss? Schreiben Sie uns — wir prüfen Ihre Systeme und sagen Ihnen offen, ob eine Gefahr besteht und was damit zu tun ist.