Die PHP-Sicherheitslücke php2shell: Was Unternehmen jetzt tun müssen

Nur ein PHP-Update schließt die Lücken vollständig

• Was: CVE-2026-109618 und CVE-2026-109619 sind zwei kritische Lücken im PHP-Kern (CVSS 4.0: 9,2). Unter passenden Bedingungen können Angreifer darüber ohne Anmeldung Code auf dem Server ausführen, mit den Rechten des PHP-Prozesses.
• Wen: Gefährdet sind PHP-Installationen, die Webanfragen bedienen, etwa mit PHP-FPM, Apache mod_php, php-cgi, FrankenPHP oder LiteSpeed. Der offizielle CVE-Eintrag listet die Zweige 8.2 bis 8.5 vor den Fix-Versionen, die Entdecker sehen den Fehler weit zurück bis PHP 5.4.
• Fix: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, veröffentlicht am 21. Oktober 2026. Für 8.1, 8.0 und 7.4 gibt es nur minimale Quellcode-Backports, für 7.3 und älter nichts von PHP selbst.
• Nicht genug: Ein Update deiner WordPress-Website, deines Shops oder eines Plugins ändert nichts, und eine WAF (Web Application Firewall, ein vorgeschalteter Schutzfilter) genügt laut dem Schweizer Bundesamt für Cybersicherheit (BACS) allein nicht. Nach dem PHP-Update müssen alle PHP-Prozesse neu starten und Container neu gebaut werden.
• Offen: Ein erfolgreicher Einbruch ist in den Quellen, die wir bis zum Morgen des 22. Oktober 2026 geprüft haben, nicht belegt, Angriffsversuche dagegen schon. Wie viele Websites wirklich verwundbar sind, weiß niemand genau, denn Scans nach Versionsnummer erkennen Backports nicht.

Was die Lücken im Ernstfall bedeuten und warum sie so heikel sind

Beide Lücken hängen damit zusammen, wie PHP mit Fehlern umgeht, etwa wenn der Speicher knapp wird oder eine Anfrage mitten in der Arbeit abbricht. Dabei kann der Zustand eines PHP-Prozesses beschädigt werden, und ein Angreifer kann das mit präparierten Anfragen auslösen. Weil der Fehler im PHP-Kern liegt, hilft kein Update von WordPress, Shopware oder einem Plugin.

Im schlimmsten Fall kann ein Angreifer damit Dateien der Website verändern, Schadcode wie Webshells (Fernzugänge für Angreifer) ablegen, Zugangsdaten für Datenbank und Schnittstellen auslesen und auf Daten zugreifen, die die Anwendung selbst lesen darf. Ob auch andere Websites auf demselben Server betroffen sind, hängt davon ab, wie der Hoster sie trennt.

WordPress, Shopware, Shopify: Bist du von den PHP-Lücken betroffen?

Entscheidend ist, wer PHP auf deinem Server betreibt und welche Version dort läuft. Die Lücken liegen in PHP selbst, das CMS spielt keine Rolle.

WordPress. WordPress läuft auf PHP und ist deshalb mittelbar betroffen. WordPress.org schreibt aber, dass kein WordPress-Update nötig ist. Bei WordPress-Websites entscheidet allein die PHP-Version des Servers. Automattic meldete am Abend des 21. Oktober, dass seine Plattformen, darunter WordPress.com und WordPress VIP, geschützt sind. Bei Managed-Hostern patcht der Hoster, auf eigenen Servern du oder deine Agentur.

Shopware, TYPO3, Drupal, WooCommerce. TYPO3 und WooCommerce schreiben ausdrücklich dasselbe wie WordPress: Die Anwendung braucht kein Update, PHP schon. Drupal nennt das PHP-Update die einzige vollständige Abhilfe. Shopware hat seine SaaS-Shops am 21. Oktober automatisch aktualisiert, laut Statusseite zwischen 9:00 und 16:33 Uhr MESZ. Wer Shopware oder TYPO3 selbst hostet, braucht den PHP-Fix auf dem eigenen Server oder beim Hoster.

Shopify. Shopify betreibt seine Plattform selbst, und der Kern läuft laut Shopify Engineering auf Ruby on Rails (Beschreibung von 2020), also nicht auf PHP. Eine Stellungnahme zu den PHP-Lücken haben wir bis zum Morgen des 22. Oktober 2026 nicht gefunden.

Betroffen sein kann alles rund um den Shop: ein WordPress-Blog, ein App-Backend, Middleware oder ein selbst gehostetes Frontend. Solche Teile gehören ins Inventar, auch wenn der Shop selbst bei Shopify liegt.

Ein Plattformwechsel ist keine Antwort auf diese Lücke. Wer ohnehin einen Umzug von Shopware, Magento oder WooCommerce nach Shopify prüft, nimmt die Frage „Wer patcht was?“ aber in die Planung der Shopify-Migration auf.

Welche PHP-Version ist gepatcht und wie prüfst du das?

Offiziell gepatcht sind vier Zweige: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für 8.1, 8.0 und 7.4 hat das PHP-Security-Team laut Ankündigung minimale Backports als Git-Branches bereitgestellt, für 7.3 und älter nichts. Wer auf diesen Versionen läuft, braucht den Fix von Distribution, LTS-Anbieter oder Hoster, oder ein Upgrade.

Die Versionsnummer täuscht. Ubuntu, AlmaLinux und Red Hat portieren den Fix teils in ältere Versionen zurück und lassen die Nummer stehen, Red Hat etwa bei PHP 7.4 auf RHEL 8. Ubuntu 22.04 liefert ihn zum Beispiel in der Paketversion 8.1.2-1ubuntu2.28, die nach Nummer uralt wirkt. Debian verteilt dagegen neue Versionen, 8.2.35 für Bookworm und 8.4.27 für Trixie. Ein Scanner, der nur die Versionsnummer liest, meldet deshalb falschen Alarm oder falsche Entwarnung. Verlässlich ist die genaue Paketversion im Abgleich mit der Sicherheitsmeldung des Anbieters, so rät es auch das BACS, und das Prinzip erklärt Red Hat.

So prüfst du es. In WordPress findest du die Version unter Werkzeuge, Website-Zustand, Reiter Info, Abschnitt Server (Dokumentation auf Englisch). Auf eigenen Servern zeigt dir der Paketmanager Version und Changelog. In Containern zählt die Version im laufenden Container, nicht die im Dockerfile. Starte nach jedem Update PHP-FPM, Apache und alle langlebigen Worker neu, denn alte Prozesse laufen mit dem alten Code weiter.

Zehn Fragen, die Agentur und Hoster jetzt beantworten sollten

Wenn du nicht selbst patchst, ist das Gespräch mit Agentur oder Hoster zentral. Diese Fragen holen verbindliche Antworten statt Beruhigung. Eine gute Antwort nennt Namen, Daten und Zeiten.

• Welche Websites, Shops und Anwendungen laufen auf PHP, auch Staging, Microsites und Altprojekte, in welcher Version und bei welchem Hoster?
• Wer ist je System für PHP-Update, Anwendungs-Update und Neustart zuständig, und wo steht das schriftlich?
• Läuft etwas auf PHP 8.1 oder älter, woher kommt dafür der Fix, was kostet er im Monat, und wann ist das Upgrade geplant?
• Bis wann ist der Patch eingespielt, in welcher Reihenfolge werden die Systeme abgearbeitet, und welche Zwischenmaßnahmen gelten bis dahin?
• Wie wird sichergestellt, dass der Patch wirklich läuft, und welchen Nachweis gibt es dafür?
• Wurde vor dem Patch angegriffen, welche Logs gibt es, wie weit reichen sie zurück, und wie wird das Dateisystem auf Webshells geprüft?
• Welche Zugangsdaten und Schlüssel werden bei Verdacht in welcher Reihenfolge rotiert, und wer koordiniert das?
• Was kostet die Reaktion auf diese Lücke, was deckt der Wartungsvertrag ab, und gibt es Bereitschaft außerhalb der Bürozeiten?
• Was regeln Hosting- und Wartungsvertrag zu Haftung und zur Abschaltung bei Schadsoftware, und was heißt das für den Ernstfall?
• Wie schnell kommt eine Information bei Verdacht auf Datenabfluss, damit die 72 Stunden der DSGVO eingehalten werden können?

Meldepflichten: Eine PHP-Lücke allein löst noch keine Meldung aus

Eine Schwachstelle ist rechtlich noch kein Vorfall. Die Meldepflicht nach DSGVO entsteht erst bei einer Verletzung des Schutzes personenbezogener Daten, also wenn Daten vernichtet, verloren, verändert oder offengelegt wurden oder unbefugt darauf zugegriffen wurde (Art. 4 Nr. 12).

Nach den Leitlinien des Europäischen Datenschutzausschusses laufen die 72 Stunden nach Art. 33 ab dem Moment, in dem du mit hinreichender Gewissheit weißt, dass das passiert ist. Gemeldet wird, wenn voraussichtlich ein Risiko für die Betroffenen besteht, bei hohem Risiko musst du sie nach Art. 34 auch selbst informieren. Eine kurze Erstprüfung ist zulässig, muss aber sofort beginnen.

Hoster und Agenturen sind meist Auftragsverarbeiter. Sie müssen dich bei Kenntnis unverzüglich informieren, die Meldung an die Aufsicht bleibt bei dir als Verantwortlichem. Die Meldekette gehört deshalb in den Vertrag, bevor etwas passiert.

Unter NIS2 kommt mehr hinzu, falls du zu den wesentlichen oder wichtigen Einrichtungen gehörst. Die Länder setzen das unterschiedlich um.

Österreich: Das NISG 2026 gilt in den Hauptbestimmungen seit dem 1. Oktober 2026. Bei einem erheblichen Sicherheitsvorfall nennt das Bundesamt für Cybersicherheit eine Frühwarnung binnen 24 Stunden nach Kenntnis, eine Meldung binnen 72 Stunden und einen Abschlussbericht nach einem Monat. Eine Schwachstelle allein ist kein Vorfall, Schwachstellen und Beinahe-Vorfälle lassen sich freiwillig melden.

Deutschland: Das NIS-2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft. Schweiz: Es gibt kein NIS2. Die Meldepflicht für Cyberangriffe gilt dort nach Angaben des BACS nur für kritische Infrastrukturen, binnen 24 Stunden nach Entdeckung. Bei Datenschutzverletzungen mit voraussichtlich hohem Risiko ist nach Art. 24 des revidierten Datenschutzgesetzes der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte so rasch wie möglich zu informieren, eine feste Frist von 72 Stunden gibt es dort nicht.

Hersteller von Produkten mit digitalen Elementen trifft außerdem der Cyber Resilience Act: Die Meldepflicht für aktiv ausgenutzte Schwachstellen nach Art. 14 gilt seit dem 11. September 2026, die ENISA erinnert in ihrer gemeinsamen Erklärung zu den PHP-Lücken daran. Das ist keine Rechtsberatung. Was für dich gilt, klärst du mit deiner Rechts- oder Datenschutzberatung.

Wie aus einem Audit ein Notfall-Release wurde

Die Spur beginnt 2024. Laut PHP Foundation war es das erste externe Audit seit Jahren, finanziert von der Sovereign Tech Agency und durchgeführt von Quarkslab. Beim Beheben eines gemeldeten Fehlers stieß ein von der Foundation beauftragter Entwickler auf erste Anzeichen eines Problems im Umgang mit Speichermangel. Eine saubere Lösung kam über Monate nicht zustande: Jeder Ansatz brach die Kompatibilität, öffnete neue Wege, den Dienst lahmzulegen (Denial of Service), oder verlangte Änderungen an vielen Erweiterungen, und der Entscheidungsprozess des Sicherheitsteams bremste die Arbeit. Die Foundation nennt die Verzögerung selbst „a structural failure“.

Im Sommer 2026 kamen die Funde, so berichtet es die PHP Foundation. Calif begann am 30. Juli ein Audit und meldete am 11. August eine Codeausführung ohne Vorbedingungen mit derselben Grundursache wie das Problem von 2024. OpenAI meldete dieselbe Ursache am selben Tag unabhängig. Wiz Research meldete am 24. August weitere Angriffswege, OpenAI am 18. September. Laut CVE-Eintrag waren die Nummern am 12. Oktober reserviert, am 18. Oktober lagen die Backports bereit.

Dann kam der Leak. Am 20. Oktober kursierten gegen 15 Uhr UTC die beiden CVE-Nummern, eine falsche Release-Zeit und ein falscher Schweregrad von 10,0, tatsächlich liegt er bei 9,2. PHP veröffentlichte um 19:30 Uhr UTC die Vorankündigung und zog den Release um einen Tag auf Mittwoch, den 21. Oktober, 14 Uhr UTC (16 Uhr MESZ) vor. Nach Angaben der PHP Foundation veröffentlichte Chainguard am 21. Oktober schon um 07:41 Uhr UTC Images mit dem Fix, mehr als sechs Stunden vor dem Release, und brach damit das Embargo. Der Release selbst erschien vor dem angekündigten Termin.

Wie viele Websites betroffen sind, weiß niemand, den Rahmen aber geben drei Messungen

Eine Prozentzahl betroffener Websites gibt es nicht, und jede, die du liest, ist gerechnet oder geschätzt. Belegen lassen sich drei getrennte Dinge: wie verbreitet PHP ist, auf welchen Versionen es läuft und wie viele Server im offenen Internet PHP zeigen.

Verbreitung. Laut W3Techs läuft PHP auf 69,3 Prozent der Websites, deren serverseitige Sprache bekannt ist (Stand 22. Oktober 2026). Allein WordPress, das auf PHP aufbaut, steckt hinter 39,6 Prozent aller Websites. Unter .at-Domains liegt der PHP-Anteil bei 76,9 Prozent, unter .de bei 77,7 Prozent und unter .ch bei 70,4 Prozent. Das beschreibt den Rahmen und sagt nichts über die Zahl verwundbarer Seiten.

Versionen. Nach W3Techs laufen 65,2 Prozent der PHP-Websites auf PHP 8, 27,0 Prozent auf PHP 7 und 7,7 Prozent noch auf PHP 5 (Stand 21. Oktober 2026, die Werte verschieben sich täglich um Zehntelprozente). Rechnet man die Zweige durch (eigene Rechnung), laufen rund 48,5 Prozent der PHP-Websites auf 8.1 oder älter, also ohne reguläres Fix-Release, und rund 51,5 Prozent auf 8.2 bis 8.5. Ob der Fix dort schon läuft, sagt diese Zahl nicht.

Server. Internetscans erfassen Server und Dienste, keine Websites. Shodan zählte laut Mallory am 21. Oktober rund 2,6 Millionen Dienste mit PHP-Versionsangabe, Censys rund 6,3 Millionen Hosts mit PHP-Software, VirusTotal rund 5,1 Millionen IP-Adressen, von denen nur etwa 1,1 Millionen eine Version nennen. Die Zahlen sind nicht addierbar, und weil auf einem Server oft viele Websites liegen, lassen sich Hosts nicht in Websites umrechnen. Palo Alto Networks nennt über 22,6 Millionen exponierte Instanzen, ohne zu erklären, was eine Instanz ist.

Österreich. Im Shodan-Scan, den Mallory ausgewertet hat, laufen bei Diensten mit sichtbarer PHP-Version in Österreich 64 Prozent auf PHP 8.1 oder älter, in Deutschland 57 Prozent und in der Schweiz 81 Prozent, über alle Länder sind es 73,5 Prozent. Gezählt sind Dienste nach IP-Standort, keine Websites. Das zeigt die Richtung, keine Betroffenheit.

So haben Cloud, Plattformen und Hoster auf php2shell reagiert

Vier Muster ziehen sich durch die Reaktionen vom 21. Oktober (Uhrzeiten in MESZ, sofern nicht UTC genannt). Sie helfen dir, die eigene Lage einzuordnen.

Schutz vor dem Release. Cloudflare schaltete um 03:02 Uhr UTC für alle Kunden mit aktivierter WAF einen Standardschutz frei und nennt ihn eine zusätzliche Verteidigungsschicht, die man beim Patchen aktiv lässt. Wer hinter einer WAF sitzt, gewinnt Zeit, ist aber nicht gepatcht, und laut AWS sieht eine WAF Teile der Lücke technisch nicht.

Automatisch gepatcht. Manche Plattformen haben das ohne Zutun der Kunden erledigt: Shopware bei den SaaS-Shops, außerdem rollt Google Cloud Patches für App Engine Standard (PHP 8.2 und neuer) und für Cloud Run mit automatischen Base-Image-Updates aus. Automattic meldet seine WordPress-Plattformen als geschützt. Eigene Container müssen Kunden selbst neu bauen, und bei Google Cloud sind abgekündigte Laufzeiten nicht gepatcht.

Abschalten bis zum Patch. Der niederländische Hoster Mijndomein nahm alle Kundenwebsites vom Netz und brachte die Hosting-Pakete ab etwa 18 Uhr wieder online. mittwald fuhr ab 16:17 Uhr alle Systeme herunter. IONOS schaltete Nextcloud-Instanzen ab, die Universitäten Freiburg und Bochum nahmen Webdienste vorsorglich vom Netz oder sperrten sie für externen Zugriff, und zahlreiche niederländische Behördenseiten gingen offline. Ein Beleg für erfolgreiche Einbrüche ist das nicht, die Quellen nennen Vorsicht als Grund.

Release heißt nicht geschützt. Auch Hoster brauchten Stunden. Hetzner hatte am Abend Patches für PHP 7.4 und 8.0 bis 8.5 auf Webhosting- und Managed-Servern eingespielt, ältere Versionen standen noch aus. mittwald meldete um 21:54 Uhr die Patches für 8.2 bis 8.5 und die LTS-Versionen auf der Zielgeraden, erst um 0:28 Uhr galten alle Versionen ab 5.6 als gepatcht. IONOS spielt das Update seit 17:44 Uhr auf allen Systemen ein, geplant binnen 24 Stunden. Bei Mijndomein stand das Plesk-Update um 16:30 Uhr bereit, der Rollout dauerte bis etwa 18 Uhr.

Was frühere Fälle zeigen: Das Zeitfenster ist kurz

Bei Log4Shell kam der erste Ausnutzungsversuch laut Cloudflare neun Minuten nach der Offenlegung, begrenzte Tests gab es dort schon acht Tage vorher. Bei der PHP-CGI-Lücke CVE-2024-4577, die nur Windows betraf, stand einen Tag nach dem Fix ein Proof of Concept online, und wenige Tage später nutzte laut Imperva Ransomware die Lücke. Mandiant misst für 2023 eine durchschnittliche Zeit bis zur Ausnutzung von fünf Tagen, ohne 15 Ausreißer, mit ihnen sind es 47 Tage.

Zwei Lehren lassen sich übertragen. Erstens beendet ein Patch den Vorfall nicht automatisch: Bei Citrix Bleed blieben gestohlene Sitzungen nach dem Patch gültig, bei Drupal 2014 entfernte das Update keine Backdoors. Zweitens verschwinden verwundbare Systeme langsam: Bei Heartbleed waren einen Monat nach der Offenlegung noch rund 300.000 Server offen.