Kritische PHP-Schwachstellen: was das für die Websites von Wiederaufbauprojekten bedeutet

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. Zwei Schwachstellen mit einer Gefahrenbewertung von 9,2 von 10 erlauben, fremden Code auf dem Server ohne Autorisierung auszuführen.

PHP ist die Sprache, in der die meisten Websites geschrieben sind: WordPress, Joomla, OpenCart, Bitrix, Laravel. Im Kontext des Wiederaufbaus bedeutet das Programmportale, Spendenseiten, Register beschädigten Eigentums, Websites von Nichtregierungsorganisationen und Auftragnehmern — also Ressourcen, auf denen personenbezogene Daten, Dokumente und Zahlungsdaten nebeneinander liegen.

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 eine gehackte Projektwebsite eine Frage des Vertrauens ist und nicht nur der Technik

Niemand sucht Ihr Projekt gezielt. Sobald Exploit-Beispiele ö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 das Portal eines nationalen Programms oder die Seite einer Initiative für eine einzige Gemeinde ist: es zählt nur die Version, mit der der Server antwortet.

Die typischen Folgen sind bekannt: eine Webshell auf dem Server, Spam und fremde Werbung auf den Seiten, die Domain auf schwarzen Listen, E-Mails, die nicht mehr ankommen. Für Wiederaufbauprojekte ist aber etwas anderes am teuersten. Erstens das Austauschen der Bankverbindung für Spenden – das klassische Szenario, bei dem eine Website mit Spendenfunktion nicht gehackt wird, um sie zu beschädigen, sondern um still die Kontonummer zu ändern. Zweitens die öffentliche Berichterstattung: wenn Dokumente und Zahlen von außen verändert werden können, verliert die Offenheit ihren Sinn, auf der das Vertrauen von Spendern und Partnern beruht.

Drittens die Daten von Menschen. Anträge, Register beschädigten Eigentums und Fragebögen der Programmteilnehmer liegen meist auf demselben Server wie die Website.

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 es in Ihrem Projekt niemanden gibt, der für Updates und Zugänge verantwortlich ist, kann das Audit der Ressourcen extern beauftragt werden – unter anderem bei SmartGT.

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