Kritische PHP-Schwachstellen: das Risiko für Websites von Gemeinden, kommunalen Einrichtungen und regionalen Projekten

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 im Internet geschrieben sind: WordPress, Joomla, OpenCart, Bitrix, Laravel. Auf regionaler Ebene bedeutet das die Websites von Stadt- und Gemeinderäten, kommunalen Betrieben, Schulen, Bibliotheken, Museen und Wiederaufbauprojekten — also gerade jenen Teil der digitalen Infrastruktur, der in der Regel weder einen eigenen Administrator noch ein Budget für die Betreuung hat.

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 es eine Frage der digitalen Resilienz der Gemeinde ist und nicht einer einzelnen Website

Niemand sucht gezielt nach der Website einer bestimmten Gemeinde. Sobald Beispiele für die Ausnutzung öffentlich werden — und sie sind bereits öffentlich —, starten innerhalb von Stunden automatische Scanner, die das gesamte Internet der Reihe nach durchgehen. Ihnen ist es gleich, ob es das Portal einer Bezirksverwaltung oder die Seite eines ländlichen Kulturhauses ist: entscheidend ist allein die Version, mit der der Server antwortet.

Die Besonderheit des öffentlichen Sektors besteht darin, dass die Ressourcen selten einzeln stehen. Die Website des Rats, das System für elektronische Anträge, der Dienstleistungskalender und die Seite eines kommunalen Betriebs liegen oft auf demselben Hosting und unter demselben Konto. Wer die schwächste davon übernimmt, erhält Zugang zu den übrigen — und kann anschließend nicht nur Spam verschicken, sondern auch Mitteilungen im Namen der Behörde veröffentlichen. Für die Gemeinde ist das keine technische Störung mehr, sondern ein Vertrauensverlust gegenüber dem offiziellen Informationskanal.

Die praktische Schlussfolgerung für alle, die in der Gemeinde für den digitalen Bereich zuständig sind: Beginnen sollte man nicht mit dem Update, sondern mit einer Bestandsliste — welche Ressourcen überhaupt existieren, auf wessen Hosting sie liegen und wer Zugang zu ihnen hat. Sehr oft zeigt sich, dass ein Teil der Websites seit Jahren von niemandem betreut wird.

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 der Gemeinde oder Einrichtung keine Fachkraft gibt, die für Updates zuständig 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“.