Das Wichtigste in 60 Sekunden / tl;dr
- CVE-2026-109618 und CVE-2026-109619 betreffen PHP selbst. Beide sind mit 9,2 von 10 Punkten als kritisch bewertet und können Codeausführung ohne Anmeldung ermöglichen.
- PHP-FPM, Apache mit mod_php und weitere PHP-Webserver-Anbindungen müssen geprüft werden. Eine Login-Seite ist kein verlässlicher Schutz.
- Die ersten behobenen Versionen sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Bei Distributionspaketen zählt auch der nachgewiesene Sicherheits-Backport.
- Jetzt Hoster oder Administration kontaktieren, PHP aktualisieren, alte Worker ersetzen und die Anwendung testen. Ein reines WordPress-, Plugin- oder Composer-Update genügt nicht.
01
Was ist betroffen und wie ernst ist es?
PHP verarbeitet auf dem Server die Anfragen vieler Websites und Webanwendungen. Deshalb gehören auch CMS, Shops, Kundenportale, APIs und interne PHP-Tools in die Bestandsaufnahme. Der Produktname allein sagt nicht, ob die darunterliegende Laufzeit bereits repariert ist.
CVE ist die eindeutige Kennung einer bekannten Sicherheitslücke. Bei CVE-2026-109618 kann PHP nach einem Speichermangel mit unvollständig initialisierten Daten weiterarbeiten. Bei CVE-2026-109619 können ungültige Speicherverweise aus einer Anfrage in einer späteren Anfrage weiterverwendet werden. Mögliche Folge ist RCE: Angreifer führen eigenen Code mit den Rechten des PHP-Webprozesses aus.
Für Apache mit mod_php ist eine Ausnutzung bereits vor dem Anwendungscode demonstriert. Auch für PHP-FPM beschreibt das zweite Advisory einen validierten Angriffspfad, der eine passende Anwendungsoperation voraussetzt. FPM ist deshalb keine pauschale Entwarnung. PHP nennt außerdem php-cgi, FrankenPHP und LiteSpeed als zu prüfende Umgebungen.
Ein Login innerhalb der PHP-Anwendung kann zu spät greifen. Ein vorgeschalteter Zugangsschutz oder eine Netzwerksperre kann die Erreichbarkeit begrenzen. Auch intern erreichbare Systeme benötigen das Update.
02
Welche PHP-Version brauche ich?
Die Tabelle zeigt die ersten offiziellen PHP-Releases mit beiden Fixes je Versionszweig. Installiere diese oder eine neuere korrigierte Version desselben unterstützten Zweigs.
| Versionszweig | Erster Fix | Vorher betroffen |
|---|---|---|
| PHP 8.2 | 8.2.35 | 8.2.0 bis 8.2.34 |
| PHP 8.3 | 8.3.36 | 8.3.0 bis 8.3.35 |
| PHP 8.4 | 8.4.27 | 8.4.0 bis 8.4.26 |
| PHP 8.5 | 8.5.12 | 8.5.0 bis 8.5.11 |
Bei Linux-Distributionen oder LTS-Anbietern kann die sichtbare PHP-Basisversion älter bleiben, obwohl Sicherheitskorrekturen eingespielt wurden. Das heißt Backport. Lass dir für beide CVEs die korrigierte Paketversion oder die Herstellermeldung bestätigen.
PHP 8.1 und ältere Zweige erhalten keine regulären Updates mehr vom PHP-Projekt. Für 7.4, 8.0 und 8.1 wurden ausnahmsweise minimale Quellcode-Backports bereitgestellt, keine Wiederaufnahme des Supports. Kläre ein Anbieterpaket oder den Wechsel auf einen unterstützten Zweig. PHP 8.2 erreicht sein Supportende am 31. Dezember 2026.
03
Was jetzt konkret zu tun ist
Meine praktische Reihenfolge für Betreiber und Administration:
Zuständigkeit und Bestand klären
Alle Domains, Subdomains, Testsysteme und Container erfassen. Wer aktualisiert PHP: Hoster, Agentur oder eigenes Team? Pro Anwendung die verwendete Laufzeit feststellen.
Patch bestätigen und einspielen
Aktuelles Backup und Rückweg prüfen, dann das korrigierte PHP-Paket beziehungsweise Container-Image zeitnah ausrollen. Öffentlich erreichbare Systeme zuerst behandeln.
Laufende Prozesse erneuern
PHP-FPM, Apache oder die jeweilige Laufzeit nach Anbieteranleitung neu starten beziehungsweise ersetzen. Alle Instanzen und Worker müssen den korrigierten Code verwenden. Ein Image nur herunterzuladen aktualisiert keinen laufenden Container.
Wirkung und Funktion prüfen
Den Patch-Stand im tatsächlichen Webbetrieb bestätigen. Danach Login, Formulare, Uploads, Checkout und Hintergrundjobs testen. Ergebnis, Paketversion und Zeitpunkt dokumentieren.
Auffälligkeiten untersuchen
Unerwartete Dateien, neue Konten, Prozessabstürze und ungewöhnliche Requests prüfen. Bei Einbruchsverdacht System isolieren, Logs und Beweise sichern und fachliche Unterstützung hinzuziehen. Ein Update beseitigt keinen bereits erfolgten Einbruch.
Direkt an den Hoster schicken
Bitte bestätigen Sie, dass alle PHP-Webinstanzen meiner Domains gegen CVE-2026-109618 und CVE-2026-109619 gepatcht sind. Welche korrigierte PHP- oder Paketversion läuft tatsächlich, wann wurden die Worker neu gestartet und sind weitere Schritte durch mich nötig?
Technischer Hinweis: Die Konsole ist nur ein Teil der Prüfung
php -v zeigt die Version der Kommandozeile. Eine Website kann eine andere PHP-FPM-Version oder einen anderen Container verwenden. Prüfe zusätzlich die Zuordnung im Hosting-Panel beziehungsweise in der Serverkonfiguration und den Paketnachweis. Keine öffentlich erreichbare phpinfo()-Datei als dauerhaften Test zurücklassen.
04
Wenn das Update nicht sofort möglich ist
CERT-EU empfiehlt in diesem Fall, die Isolation öffentlich erreichbarer Anwendungen zu erwägen. Praktisch: Zugriff am vorgeschalteten Proxy oder Netzwerk begrenzen oder vorübergehend eine statische Wartungsseite ausliefern, ohne Requests weiter an PHP zu leiten.
PHP dokumentiert zusätzliche Übergangsmaßnahmen, aber keine vollständige Konfigurationslösung. Dazu gehören das Abschalten von session.upload_progress.enabled sowie unter PHP 8.5 von fatal_error_backtraces, jeweils vor der Request-Verarbeitung und mit Neustart aller Worker. Diese Änderungen schließen nur bestimmte Angriffspfade.
Besondere Vorsicht bei memory_limit=-1: Das entfernt die PHP-interne Speichergrenze und kann die Verfügbarkeit gefährden. Die im Advisory beschriebene Übergangslösung benötigt weitere Ressourcen- und Request-Begrenzungen und ersetzt ebenfalls keinen Patch. Änderungen nur anhand der vollständigen Herstelleranleitung durch die Administration vornehmen lassen.
05
Kurze Antworten
Reicht ein Update meines CMS oder Shops?
Nur wenn damit nachweislich auch die betroffene PHP-Laufzeit korrigiert wird. Üblicherweise muss PHP separat beim Hoster, im Betriebssystem oder im Container aktualisiert werden.
Bin ich hinter einer Firewall automatisch sicher?
Eine Netzwerksperre kann Angriffe von außen begrenzen. Eine Firewall, die Webanfragen weiterhin an PHP durchlässt, ist kein Patch-Nachweis.
Beweisen unauffällige Logs, dass nichts passiert ist?
Nein. Das PHP-Advisory warnt ausdrücklich davor, aus fehlenden Fehlermeldungen Sicherheit abzuleiten. Logs ergänzen die Prüfung, ersetzen aber weder Update noch Untersuchung eines konkreten Verdachts.
06
Offizielle Quellen
Geprüft am 21. Oktober 2026 nach Veröffentlichung der Patches. Die PHP-Advisories enthalten die technischen Details. CERT-EU wird hier für die Empfehlung zur vorübergehenden Isolation zitiert; seine Vorabwarnung erschien noch vor den Releases.
Quellen: PHP: Security advisory, 21 October 2026 · PHP: CVE-2026-109618 / GHSA-w8hw-w9fx-j79w · PHP: CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp · PHP 8.5.12 · PHP 8.4.27 · PHP 8.3.36 · PHP 8.2.35 · PHP: Supported versions · CERT-EU: Security Advisory 2026-018 (Vorabwarnung / advance warning)