Das PHP-Projekt hat am 21. Oktober 2026 Updates für zwei kritische Sicherheitslücken veröffentlicht, die unauthentifizierte Remote-Code-Ausführung ermöglichen. Wer Websites oder Anwendungen auf PHP-Basis betreibt, muss die PHP-Engine des Servers aktualisieren und sicherstellen, dass die laufenden Prozesse die korrekte Version geladen haben. Ein Update des CMS allein behebt keinen Fehler in der zugrunde liegenden Laufzeitumgebung.
🚨 Organizations should immediately patch critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619. These vulnerabilities enable unauthenticated #RCE and affect PHP installations serving web requests. Learn more: 🔗 https://t.co/8vu6SvNzfB pic.twitter.com/LUWik7aQcG
, CISA Cyber (@CISACyber) October 21, 2026
Die Schwachstellen tragen die Kennungen CVE-2026-109618 und CVE-2026-109619, beide mit einem CVSS-v4.0-Score von 9,2 von 10. Cloudflare berichtet, Angriffsdatenverkehr gegen eigene Kunden beobachtet zu haben, CloudLinux meldet Versuche, die bekannten Angriffsmustern entsprechen. Das sind Hinweise auf feindliche Aktivität, kein Beweis dafür, dass jede verwundbare Installation kompromittiert wurde.
Zwei Speicherverwaltungsfehler im PHP-Kern
CVE-2026-109618 betrifft das Verhalten von PHP, wenn eine Operation den verfügbaren Arbeitsspeicher erschöpft. Der Abbruch kann dazu führen, dass interne Daten nur teilweise initialisiert bleiben. Beim Beenden der Anfrage kann der Prozess diese Daten fälschlicherweise als gültig behandeln. Laut dem offiziellen Advisory kann dies bis zur Ausführung von Code ohne Authentifizierung führen, mit den Rechten des Kontos, unter dem der Webprozess läuft.
CVE-2026-109619 betrifft einen internen Zustand, der nach der Freigabe des referenzierten Speichers weiterhin zugänglich bleibt. Eine nachfolgende Anfrage, die vom gleichen Prozess verarbeitet wird, kann diese nun ungültigen Referenzen verwenden. Auch hier wurde die Möglichkeit der Remote-Code-Ausführung nachgewiesen. Das bedeutet nicht automatisch, dass ein Angreifer Systemadministratorrechte erlangt: Der erste Zugriff hängt von den Berechtigungen des betroffenen Prozesses ab.
Welche Server betroffen sind
Der PHP-Sicherheitshinweis nennt Installationen, die Webanfragen über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed verarbeiten. Das höchste Risiko sieht das Projekt bei Apache mit mod_php, wo ein nachgewiesener Angriff ausgelöst werden kann, bevor der Anwendungscode überhaupt zu laufen beginnt. Eine Schutzprüfung im CMS reicht für diesen Pfad daher nicht aus.
Das Risiko ist nicht in allen Konfigurationen gleich. Die Advisories unterscheiden zwischen nachgewiesenen Angriffspfaden und Bedingungen, die von Ausführungsmodus, Erweiterungen und Anwendung abhängen. Für die zweite Schwachstelle wurde Remote-Code-Ausführung auch in PHP-FPM über den Session-Verwaltungszyklus validiert. PHP-FPM allein zu verwenden bedeutet also nicht, dass der Server als sicher gilt.
Drei Punkte zum Merken
- Schweregrad: zwei kritische Schwachstellen, beide CVSS v4.0 mit 9,2 bewertet.
- Behebung: PHP aktualisieren und sicherstellen, dass die Prozesse, die den Webauftritt bedienen, den korrekten Code geladen haben.
- Prüfung: Die tatsächlich vom Webserver verwendete Engine kontrollieren, nicht nur den im Terminal verfügbaren Befehl.
Korrekte Versionen und der Sonderfall Backport-Pakete
Das PHP-Projekt benennt die ersten korrekten Releases für die vier gepflegten Versionszweige. Die Tabelle bezieht sich auf die vom Projekt verteilten Versionen. Für Pakete von Linux-Distributionen und Support-Anbietern muss zusätzlich das jeweilige Sicherheitsbulletin geprüft werden.
Two critical vulnerabilities have been identified in PHP, a widely used programming language that powers websites and web applications. These vulnerabilities (CVE-2026-109618 and CVE-2026-109619) could allow malicious cyber actors to remotely execute code in PHP core, potentially… pic.twitter.com/tnwiQv5v0F
, FBI Cyber Division (@FBICyberDiv) October 21, 2026
Die konkreten Versionsnummern sind in den offiziellen Advisories der beiden Schwachstellen dokumentiert.
PHP 8.1 und ältere Zweige erhalten vom PHP-Projekt keine Updates mehr, allerdings pflegen einige Anbieter Pakete mit rückportierten Korrekturen für ältere Versionen, sogenannte Backports. Bei diesen Paketen reicht die ursprüngliche Versionsnummer allein nicht aus, um festzustellen, ob die Korrektur enthalten ist. Es muss die tatsächlich verteilte Revision sowie die Herstellerempfehlung geprüft werden. Der offizielle Sicherheitssupport für PHP 8.2 endet zudem am 31. Dezember 2026: Diesen Patch einzuspielen und die Migration zu planen sind zwei voneinander unabhängige Aufgaben.
Update einspielen und das Ergebnis prüfen
Das Update muss alle auf dem Server verwendeten PHP-Installationen erfassen. Ein einzelnes System kann mehrere Versionen, mehrere Sites und separate Prozesse beherbergen. Die cPanel-Hinweise unterscheiden beispielsweise zwischen dem internen PHP des Panels und den EasyApache-Paketen für die Websites. Auch Plesk und CloudLinux veröffentlichen Hinweise für spezifische Komponenten und Plattformen: Die Verfügbarkeit muss für die tatsächlich eingesetzte Umgebung geprüft werden.
Daniele Molteni
Der Befehl php -v zeigt das Programm an, das in der Shell ausgeführt wird. Dieses kann sich von der Engine unterscheiden, die für die Website konfiguriert ist. Eine Prüfung im Verwaltungspanel oder eine Diagnoseseite, die vom Webserver ausgeführt wird, erlaubt eine Kontrolle im richtigen Kontext. Wer phpinfo() verwendet, muss den Zugriff einschränken und die Seite nach der Prüfung entfernen. Sie Pfade, Konfigurationen, HTTP-Header und Umgebungsvariablen offenlegen kann. Die mit dem eigenen Administrator oder Anbieter abzustimmende Vorgehensweise lautet:
- Backup oder Snapshot vorbereiten, mit einem verfügbaren Wiederherstellungsverfahren.
- Verwendete Versionen und Komponenten ermitteln, einschließlich der den einzelnen Sites zugewiesenen Engines sowie der von Panels genutzten Engines.
- Korrekte Pakete installieren über den Paketmanager der Distribution oder die offiziellen Werkzeuge des Anbieters.
- Betroffene Dienste und Prozesse neu starten, gemäß den Anweisungen für PHP-FPM, Apache oder die verwendete Umgebung: Alte Prozesse dürfen keine Anfragen mehr verarbeiten.
- Ergebnis im Terminal und auf der Website prüfen, Version, Paketrevision und Funktionsfähigkeit der Anwendungen kontrollieren.
WAF und temporäre Maßnahmen ersetzen den Patch nicht
Konkret: cloudflare und CloudLinux haben Regeln angekündigt, um bestimmte Angriffsmuster abzufangen. Das ist eine zusätzliche Schutzschicht, keine Behebung des Fehlers auf dem Server. Cloudflare selbst empfiehlt ausdrücklich, die PHP-Updates auch dann einzuspielen, wenn WAF-Schutzmaßnahmen aktiv sind.
Auch die in den offiziellen Advisories genannten Konfigurationsänderungen decken nur spezifische Angriffspfade ab und stellen keine allgemeine Lösung dar. Sie müssen in Bezug auf die Anwendung bewertet und an der richtigen Stelle in der Konfiguration gesetzt werden. Vollständiger Schutz vor diesen beiden Lücken erfordert den korrekten Code, der vom PHP-Projekt oder über ein Anbieterpaket mit integriertem Patch bereitgestellt wird.
Die entscheidende Kontrolle
Was wirklich zählt, ist das, was der Server tatsächlich ausführt. Die bloße Existenz eines aktualisierten Pakets oder eines Panels in der neuesten Version beweist nicht, dass jede Website die alte Engine verlassen hat. Die Prüfung muss bis zum Prozess reichen, der die eingehenden Anfragen entgegennimmt und verarbeitet.
Für Administratoren schließt die Maßnahme daher mit drei überprüfbaren Ergebnissen ab: installierte Korrekturen, aktualisierte Prozesse und kontrollierte exponierte Anwendungen. Diese Abfolge verhindert, dass die Verfügbarkeit eines Patches mit seiner tatsächlichen Anwendung verwechselt wird.
Quellen
- PHP, offizieller Sicherheitshinweis vom 21. Oktober 2026.
- PHP, Advisory CVE-2026-109618 und Advisory CVE-2026-109619.
- PHP, Kalender der unterstützten Versionen.
- Cloudflare, beobachtete Angriffe und WAF-Schutzmaßnahmen.
- CloudLinux, Status der Updates und Mitigationen.
- cPanel, Release Notes und Plesk, Bulletin zu betroffenen Komponenten.
- PHP-Handbuch: Befehlszeilenoptionen und von phpinfo offengelegte Informationen.
