Stand: 21. Oktober 2026, vor Veröffentlichung der Sicherheitsupdates. Das PHP-Team veröffentlicht Details, betroffene und korrigierte Versionen am 21. Oktober um 14:00 Uhr UTC (16:00 Uhr deutscher Zeit). Wir ergänzen diese Seite, sobald sie vorliegen, und trennen bis dahin Bestätigtes von Berichten.

Kurz gesagt

  • Zwei Lücken in PHP selbst (CVE-2026-109618 und CVE-2026-109619), vom PHP-Team mit 9,2 von 10 bewertet. Sie erlauben nach bisherigen Berichten das Ausführen von Code aus der Ferne.
  • Offizielle Updates erhalten nur die unterstützten Versionen PHP 8.2 bis 8.5. Für PHP 8.1 und älter gibt es keinen offiziellen Fix.
  • Die Lücke steckt nicht im Shop oder im CMS, sondern darunter. Plugins, Firewalls in der Anwendung oder Updates von WordPress oder Shopware schließen sie nicht.
  • Wer seinen Server nicht selbst betreibt, sollte heute bei seinem Hoster nachfragen, welche PHP-Version läuft und wann das Update eingespielt wird.

Was bestätigt ist und was nicht

Das PHP-Team hat am 20. Oktober eine Sicherheitsveröffentlichung angekündigt: zwei kritische Lücken, beide mit CVSS v4.0 9,2 bewertet, Veröffentlichung am 21. Oktober um 14:00 Uhr UTC. Es behält sich vor, früher zu veröffentlichen, falls Details bekannt werden oder Angriffe auftauchen. Details, betroffene und korrigierte Versionen folgen erst mit der Veröffentlichung.

Vorab sind Informationen durchgesickert. Sicherheitsforscher bestätigen, dass es sich um Lücken handelt, über die Code aus der Ferne ausgeführt werden kann. Nach Berichten von Sicherheitsforschern betreffen sie PHP ab Version 5.4, also praktisch jede PHP-Installation seit 2012. Das PHP-Team hat das noch nicht bestätigt. Aktive Angriffe sind bisher nicht bekannt; Fachleute rechnen aber damit, dass sie kurz nach der Veröffentlichung beginnen.

Was „Code aus der Ferne ausführen“ bedeutet

Bei einer Remote Code Execution (RCE) bringt ein Angreifer den Server dazu, eigene Befehle auszuführen, ohne Zugangsdaten und ohne Zutun des Betreibers. Er handelt dann mit den Rechten der Website: Er kann ihre Dateien ändern, Hintertüren ablegen, die Konfiguration lesen und darüber an Datenbankzugänge, API-Schlüssel und Zahlungsanbindungen gelangen.

Liegen mehrere Websites oder Anwendungen auf demselben Server, ist meist nicht nur eine betroffen. Bei einem Onlineshop geht es dann um Kundendaten, und eine solche Datenpanne ist binnen 72 Stunden der Aufsichtsbehörde zu melden.

Wer betroffen ist

Betroffen ist, wer PHP auf einem Server betreibt, der aus dem Internet erreichbar ist. Das gilt für die meisten WordPress-Websites, Shopware-, xt:Commerce-, Magento- und WooCommerce-Shops, Foren, Kundenportale und viele Eigenentwicklungen. Entscheidend ist die PHP-Version:

  • PHP 8.2 bis 8.5: Updates kommen. Sie müssen aber auch eingespielt werden, und PHP muss danach neu starten. Achtung: Für PHP 8.2 endet die Sicherheitsunterstützung am 31. Dezember 2026. Wer jetzt auf 8.2 aktualisiert, sollte den nächsten Versionssprung gleich mit einplanen.
  • PHP 8.1 und älter: kein offizieller Fix. Diese Versionen haben das Ende ihrer Unterstützung längst erreicht, PHP 7.4 etwa Ende 2022, PHP 5.6 Ende 2018. Sie laufen trotzdem noch auf sehr vielen Servern, oft weil der Shop oder die Website nie für neuere Versionen angepasst wurde.
  • Nicht öffentlich erreichbare Systeme, etwa interne Werkzeuge nur im Firmennetz oder hinter einem VPN, sind weniger dringend, aber nicht ausgenommen. Wer einmal im Netz ist, nutzt sie als nächsten Schritt.

Was bei älteren PHP-Versionen möglich ist

Für Systeme auf PHP 8.1 und älter gibt es keine Lösung, die nichts kostet. Es gibt vier Wege, und oft ist es eine Kombination:

  1. Portieren: Die Anwendung wird auf eine aktuelle PHP-Version gehoben. Bei gepflegten Systemen sind das Tage, bei alten Shops mit vielen Anpassungen eher Wochen.
  2. Erweiterte Unterstützung: Einige Linux-Distributionen und kommerzielle Anbieter pflegen ältere PHP-Versionen über das offizielle Ende hinaus und spielen Sicherheitskorrekturen nach. Ob und wann ein Fix für diese beiden Lücken kommt, muss für jede Installation einzeln geprüft werden.
  3. Angriffsfläche verkleinern: Was nicht öffentlich sein muss, wird es auch nicht: Verwaltungsbereiche, Archive und Testumgebungen nur noch aus dem eigenen Netz oder per VPN, Altsysteme getrennt von Servern mit anderen Anwendungen. Das schließt die Lücke nicht, begrenzt aber, wer sie erreichen kann und was danach erreichbar ist.
  4. Abschalten: Archivshops, alte Kampagnenseiten, vergessene Subdomains. Was niemand mehr braucht, ist die günstigste Lösung.

Typische Fallen beim Patchen

Bei der Bestandsaufnahme in den von uns betriebenen und betreuten Umgebungen sind uns vier Muster begegnet, die einen Server sicher aussehen lassen, obwohl er es nicht ist:

  • „Keine Updates verfügbar“: Ist die Paketliste des Servers veraltet, meldet die Update-Prüfung nichts, obwohl längst neue Versionen bereitstehen. Erst die Liste aktualisieren, dann prüfen.
  • Zusätzliche Paketquellen: Viele Server beziehen PHP nicht vom Betriebssystem, sondern aus einer eigenen Quelle, um mehrere Versionen parallel anzubieten. Deren Updates laufen getrennt und müssen eigens geprüft werden. Wir fanden Server, deren PHP-Quelle seit Monaten nicht mehr abgefragt worden war.
  • Die Konfiguration sagt 8.2, es läuft 7.4: Auf einem Server mit mehreren PHP-Versionen waren einzelne Websites in der Verwaltungsoberfläche auf eine neue Version eingestellt, ausgeliefert wurden sie aber weiter von einer alten. Sichtbar wurde das erst, als wir die tatsächlich laufende Version jeder Website abgefragt haben, statt der Einstellung zu glauben.
  • Vergessene Installationen: alte Shopkopien, Archive, Testumgebungen mit eigener Adresse, die nirgends mehr auftauchen außer im DNS. Sie laufen oft auf den ältesten Versionen.

Dazu kommt ein Klassiker: Ein Update ist erst wirksam, wenn PHP-FPM oder der Webserver neu gestartet wurde. Bis dahin läuft der alte Code im Speicher weiter.

So gehen wir vor

  1. Inventar: Jeder Server und jede Website mit PHP, mit tatsächlich laufender Version und Herkunft der Pakete, nicht nur mit der dokumentierten.
  2. Einordnen nach Erreichbarkeit: öffentlich erreichbar und ohne Anmeldung zuerst, dann hinter Anmeldung, dann nur intern.
  3. Patch-Pfad je System: Paketquelle des Betriebssystems, zusätzliche Quelle oder erweiterte Unterstützung. Paketlisten werden vorab aktualisiert, damit das Update am Veröffentlichungstag ohne Umwege läuft.
  4. Einspielen und nachweisen: Update installieren, PHP neu starten, die laufende Version jeder Website von außen und innen prüfen.
  5. Nicht patchbare Systeme eingrenzen: Zugriff einschränken, vom Rest trennen oder abschalten, abgestimmt mit dem jeweiligen Betreiber. Parallel planen wir Portierung oder Ablösung.
  6. Beobachten: Protokolle und Auffälligkeiten in den Tagen nach der Veröffentlichung, wenn automatisierte Angriffe zu erwarten sind.

Was Sie jetzt tun sollten

  • Wissen Sie, welche PHP-Version Ihre Website und Ihr Shop nutzen? Bei Shared Hosting steht sie meist in der Verwaltungsoberfläche des Hosters.
  • Liegt sie unter 8.2: Fragen Sie Ihren Hoster oder Dienstleister, ob es erweiterte Unterstützung gibt und was ein Umstieg kostet.
  • Liegt sie bei 8.2 oder höher: Klären Sie, wer das Update am 21. Oktober einspielt und wann.
  • Gibt es Archive, Testumgebungen oder alte Subdomains, die noch erreichbar sind?
  • Liegen weitere Anwendungen mit Kundendaten auf demselben Server?

Kunden, deren Server wir betreiben, müssen nichts tun: Wir spielen die Updates für unterstützte Versionen am Tag der Veröffentlichung ein. Wer ältere Versionen nutzt, hat bereits von uns gehört oder hört in Kürze von uns. Wenn Sie unsicher sind, wo Ihre Website steht, sehen wir sie uns an. Kontakt aufnehmen ›