Kritische PHP-Schwachstellen: prüfen Sie die Website Ihres Betriebs oder Ihrer Initiative

Viele Veteranen gründen nach dem Dienst ein eigenes Geschäft, nehmen ein gemeinnütziges Projekt in Angriff oder starten eine Bildungsinitiative – und fast immer entsteht irgendwann eine Website. Gemacht wurde sie meist mit WordPress: schnell, günstig, oft von einem Bekannten oder einem Freelancer, mit dem man längst keinen Kontakt mehr hat.

Am 21. Oktober 2026 hat das PHP-Team außerplanmäßige Updates veröffentlicht, und das europäische Team für die Reaktion auf Cybervorfälle CERT-EU gab eine Notfallwarnung heraus. Der Grund sind zwei Schwachstellen mit der Gefahrenbewertung 9,2 von 10, die einem Angreifer erlauben, eigenen Code auf Ihrem Server auszuführen. Ohne Login, ohne Passwort, ohne jede Handlung Ihrerseits.

Im Folgenden ohne überflüssige Fachsprache: was passiert ist, warum es selbst die kleinste Website betrifft und welche drei Sätze man seinem Hoster schon heute schreiben sollte.

Was genau gefunden wurde

Es sind zwei Schwachstellen, beide mit 9,2 Punkten bewertet, und beide führen zum selben Ergebnis: fremder Code wird ohne Anmeldung auf dem Server ausgeführt.

CVE-2026-109618 — Abbruch bei Speichermangel

In PHP gibt es die Einstellung memory_limit: Eine Anfrage, die zu viel Speicher verbraucht hat, wird zwangsweise abgebrochen. Das Problem ist, wie genau sie abgebrochen wird. PHP kann in dem Moment abbrechen, in dem die internen Daten der Anfrage nur zur Hälfte gefüllt sind — zum Beispiel während eine über ein Upload-Formular gesendete Datei verarbeitet wird. Das Aufräumen nach einer solchen Anfrage hält die unfertigen Daten für echte und versucht Speicher freizugeben, den es nie gegeben hat. Und in diesem Speicher kann genau das liegen, was ein Angreifer mit früheren Anfragen dort abgelegt hat.

CVE-2026-109619 — Reste der vorherigen Anfrage

Die zweite Lücke besagt, dass der Server den vorherigen Besucher nicht vollständig „vergisst“. Ein interner Zustand, der zu einer Anfrage gehörte, übersteht manchmal die Freigabe des Speichers — etwa nach einem fatalen Fehler. Die nächste Anfrage, die in denselben Arbeitsprozess gerät, kann diese Reste noch nutzen, bevor die normale Initialisierung sie auf Null setzt.

Betroffen ist jede PHP-Installation, die Webanfragen bedient: PHP-FPM, Apache mit dem Modul mod_php, php-cgi, FrankenPHP, LiteSpeed. Als riskanteste Variante nennt das PHP-Team gerade die Kombination von Apache mit mod_php — sie ist bei vielen billigen Hostern bis heute Standard.

Der Demonstrations-Exploit funktioniert mit einer einzigen nicht authentifizierten Anfrage — noch bevor der Code der Website selbst ausgeführt wird. Das heißt: Weder Sicherheits-Plugins noch komplizierte Passwörter noch Zwei-Faktor-Authentifizierung helfen hier, denn der Angriff findet eine Ebene tiefer statt.

Welche Versionen betroffen sind

Alles, was unter diesen Versionen liegt, ist angreifbar:

PHP-Zweig	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

Eine eigene Risikokategorie sind kommerzielle und offene Produkte, in denen PHP eingebaut ist, ohne dass man es von außen sieht: Verwaltungsoberflächen, Netzwerkgeräte, Videoüberwachungssysteme, Firmenportale. Eine Liste solcher Software führt das Repository des niederländischen NCSC.

Warum „ich habe eine kleine Website“ hier nicht hilft

Niemand sucht Ihre Website gezielt. Sobald Beispiele für den Einbruch öffentlich werden – und sie sind bereits öffentlich –, starten innerhalb weniger Stunden automatische Scanner, die das gesamte Internet der Reihe nach durchgehen. Ihnen ist es gleich, ob es die Website eines großen Unternehmens oder die Seite einer Werkstatt mit fünf Leistungen ist: es zählt nur, ob der Server mit einer anfälligen Version antwortet.

Danach läuft es typisch ab: fremder Code wird auf den Server geladen, die Website verteilt Spam oder Seiten mit fremder Werbung, die Domain landet auf schwarzen Listen und die E-Mails von ihr kommen bei den Kunden nicht mehr an. Für ein kleines Geschäft ist das doppelt schmerzhaft: die Website ist oft das einzige Schaufenster, und die Wiederherstellung kostet Wochen und Geld, das nicht eingeplant war.

Gesondert warnen wir vor dem, was üblicherweise danach kommt. Nach solchen Nachrichten werden „Fachleute“ aktiv, die Websitebesitzer selbst anschreiben: „Sie haben eine Schwachstelle, geben Sie dringend die Zugänge heraus.“ Zugänge zur Website und zum Hosting geben Sie nur an jemanden weiter, den Sie kennen und den Sie für die Betreuung bezahlen.

Was zu tun ist — Schritt für Schritt

1. Finden Sie Ihre Version heraus. In der Hosting-Oberfläche ist das der Bereich „PHP-Version“ oder „PHP Selector“; auf einem eigenen Server der Befehl php -v. Wichtig ist, die Version zu prüfen, mit der die Website tatsächlich läuft, und nicht die in der Kommandozeile: sie unterscheiden sich oft.
2. Aktualisieren Sie innerhalb Ihres Zweigs. Der Wechsel von 8.2.29 auf 8.2.35 ist eine Korrektur innerhalb eines Zweigs: die Kompatibilität bleibt erhalten, die Website geht davon nicht kaputt. Verwechseln Sie das nicht mit dem Wechsel von 8.2 auf 8.4 — der muss sehr wohl geprüft werden.
3. Wenn Sie 8.1 oder älter haben — diese Zweige haben keinen Support. Wegen des Ernsts der Lage hat das PHP-Sicherheitsteam minimale Korrekturen auch für 7.4, 8.0 und 8.1 veröffentlicht, und ein Teil der Hoster pflegt eigene Builds. Die richtige Entscheidung ist jedoch der Umzug auf einen unterstützten Zweig, und besser plant man ihn jetzt als beim nächsten Mal.
4. Starten Sie die Handler neu. Ohne einen 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 ist eine temporäre Seite mit phpinfo(), die man gleich nach der Prüfung löschen muss, oder der Bereich „PHP-Version“ in der Oberfläche nach dem Neustart.

Hosting-Kunden müssen meist nichts selbst erledigen: Große Anbieter haben die Korrekturen im Voraus erhalten und aktualisieren ihre Maschinen selbst. Es lohnt sich, dem Support eine Zeile zu schreiben — „ist PHP auf die Versionen vom 21. Oktober 2026 aktualisiert“ — und die Antwort schriftlich zu bekommen.

Wenn ein Update jetzt nicht möglich ist

Es kommt vor, dass eine Website alt ist und das Update Vorbereitung verlangt. Dann gibt es vorübergehende Maßnahmen, die das Fenster für einen Angriff verengen:

• Schließen Sie den Speicherüberlauf als Einstiegspunkt aus: memory_limit=-1, so gesetzt, dass die Anwendung es nicht überschreiben kann, und prüfen Sie, dass kein Pool und kein Verzeichnis das Limit wieder zurückstellt;
• Verringern Sie post_max_size — 8M für Websites ohne Datei-Uploads, 32M wenn Uploads nötig sind, und upload_max_filesize noch niedriger halten;
• Deaktivieren Sie session.upload_progress.enabled und starten Sie alle Arbeitsprozesse neu;
• Deaktivieren Sie bei PHP 8.5 zusätzlich fatal_error_backtraces;
• Begrenzen Sie Größe und Komplexität der Anfragen auf der Ebene des Webservers oder des Proxys.

Keine dieser Maßnahmen macht die Installation sicher. Sie schließen nur bekannte Wege — vollständig behebt das Problem allein das Update.

Wenn auch das nicht möglich ist, empfiehlt CERT-EU eine einfache und unpopuläre Lösung: den angreifbaren Dienst aus dem öffentlichen Internet nehmen, bis die Korrektur installiert und überprüft ist.

Woher diese Angaben stammen

• CERT-EU, Security Advisory 2026-018 „Critical Vulnerabilities in PHP“
• Ankündigung der Update-Veröffentlichung auf php.net
• Technische Beschreibung von CVE-2026-109618 und CVE-2026-109619

---

Wenn Sie nicht wissen, womit Ihre Website gebaut ist und wer für sie zuständig ist, ist das schon ein Grund, sich damit zu befassen, ohne auf die nächste Nachricht zu warten. Die Prüfung kann man auch beauftragen bei SmartGT, dem Team, das die digitalen Ressourcen des Clusters betreut.

Autor des Beitrags — SmartGT. Originalquelle: „Kritische Schwachstellen in PHP: Das Update darf nicht warten“.