CVE-2026-109618 und CVE-2026-109619: Analyse zweier kritischer PHP-Schwachstellen und das Vorgehen bei der Reaktion

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. Beide Schwachstellen haben die Bewertung 9,2 Punkte und erlauben, beliebigen Code auf dem Server ohne Authentifizierung auszuführen.

Da PHP die am weitesten verbreitete Sprache des Server-Teils des Webs bleibt — darauf laufen WordPress, Joomla, OpenCart, Bitrix, Laravel und ein erheblicher Teil selbstgebauter Integrationen mit CRM- und Buchhaltungssystemen —, umfasst der Kreis der betroffenen Systeme die Mehrheit der Organisationen mit eigener Webpräsenz, einschließlich wissenschaftlicher und analytischer Einrichtungen.

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.

Risikobewertung für Einrichtungen

Das zentrale Merkmal dieses Falls ist, dass kein gezielter Angriff nötig ist. Nach der Veröffentlichung von Exploit-Beispielen beginnt das massenhafte Scannen des Adressraums innerhalb von Stunden und unterscheidet nicht zwischen Organisationstypen: das einzige Auswahlkriterium ist die Version, mit der der Server antwortet.

Für wissenschaftliche und analytische Einrichtungen kommen zu den typischen Folgen (Platzierung einer Web Shell, Spamversand, Aufnahme der Domain in Sperrlisten, Verlust der E-Mail-Zustellung) zwei spezifische hinzu. Die erste ist die Datenintegrität: Forschungsdatensätze, normative Dokumente und Umfrageergebnisse, die auf demselben Server liegen, werden veränderbar, und das Austauschen von Zahlen in einer Veröffentlichung wird erst mit großer Verzögerung entdeckt. Die zweite betrifft den Ruf: Material, das im Namen der Einrichtung veröffentlicht wird, gilt als ihre offizielle Position.

Bei der Bewertung des eigenen Risikos sollten auch Systeme berücksichtigt werden, in denen PHP unausgesprochen steckt: Verwaltungsoberflächen von Geräten, Netzwerkgeräte, Videoüberwachungssysteme und interne Portale. Sie landen selten auf der Liste der zu aktualisierenden Ressourcen.

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

---

Ein externes Perimeter-Audit und die Versionsprüfung können unter anderem beauftragt werden bei SmartGT — einem Team, das die digitalen Ressourcen von Partnerorganisationen betreut.

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