PHP-Sicherheitslücke PHP2Shell, was KMU jetzt tun müssen

Lesezeit ca. 8 Minuten | Stand 22. Oktober 2026

Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Updates für zwei kritische Sicherheitslücken veröffentlicht. Sie tragen die Kennungen CVE-2026-109618 und CVE-2026-109619 und laufen unter dem Namen PHP2Shell.

Beide Lücken erlauben es Angreifern, ohne Login eigenen Code auf einem Webserver auszuführen. Bewertet sind sie mit 9.2 von 10 Punkten nach CVSS 4.0.

Das betrifft nicht ein einzelnes Plugin, sondern die Programmiersprache, auf der ein grosser Teil des Webs läuft. Laut W3Techs nutzen 69.3 Prozent aller Websites, deren Serversprache bekannt ist, PHP. Läuft Deine Website mit WordPress, Joomla, TYPO3 oder einem Shop wie WooCommerce, betrifft Dich das direkt.

Dieser Beitrag erklärt, was passiert ist, welche Systeme betroffen sind und was Du heute konkret tun solltest.

‍

Das Wichtigste in Kürze

• Was: zwei kritische Lücken im PHP-Kern, ausnutzbar ohne Login und ohne Zutun eines Nutzers
• Wer: jede PHP-Installation, die Webanfragen beantwortet, unabhängig vom CMS
• Fix: PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 beziehungsweise ein gepatchtes Paket Deines Hosters
• Dringlichkeit: sofort, das Bundesamt für Cybersicherheit BACS rät zu unverzüglichen Updates
• Wichtig: ein Update entfernt keinen Angreifer, der schon im System ist

‍

Was hinter PHP2Shell steckt

PHP verarbeitet jede Anfrage an Deine Website in einem sogenannten Worker. Dieser Prozess bekommt Speicher, erledigt die Anfrage und räumt danach auf. Genau beim Aufräumen liegen die beiden Fehler.

CVE-2026-109618, Fehler bei vollem Speicher

Läuft PHP mitten in einer Anfrage der Speicher aus, bricht die Verarbeitung abrupt ab. Interne Daten sind dann nur halb vorbereitet. Beim anschliessenden Aufräumen behandelt PHP diese unfertigen Daten trotzdem als gültig.

Ein Angreifer kann diesen Zustand gezielt herbeiführen, etwa mit präparierten Formular- oder Upload-Anfragen. Bei Apache mit mod_php ist laut PHP-Team ein Angriff möglich, bevor überhaupt eine Zeile der Website ausgeführt wird.

CVE-2026-109619, Altlasten aus der vorherigen Anfrage

Ein Worker beantwortet nacheinander viele Anfragen. Bestimmte interne Zustände überleben das Ende einer Anfrage, obwohl der zugehörige Speicher schon freigegeben ist. Die nächste Anfrage im selben Worker kann diese veralteten Daten benutzen.

Bestätigte Angriffswege laufen unter anderem über die Funktion für den Upload-Fortschritt von Sessions. Sie ist standardmässig aktiv und greift auch dann, wenn die Website selbst gar keine Sessions startet.

Wer die Lücken gefunden hat

Gefunden haben sie mehrere Teams unabhängig voneinander, darunter Wiz Research und die Sicherheitsfirma Calif in Zusammenarbeit mit OpenAI. Das PHP-Projekt nennt alle drei. Laut Wiz fand das Team die erste Lücke am 19. August 2026, am 24. August ging die Meldung an das PHP-Sicherheitsteam. Beteiligt waren KI-Modelle, die das Finden und das Ausnutzen der Fehler deutlich beschleunigt haben.

Genau diese Geschwindigkeit macht die Lage ernst. Thomas Caspers, Vizepräsident des deutschen BSI, erwartet eine breite Ausnutzung innerhalb von Stunden nach den Updates, weil Angreifer die Fixes mit KI-Werkzeugen schnell analysieren können.

Amazon Threat Intelligence berichtet zudem von einem Angriffsversuch auf ihr Honeypot-Netzwerk am 17. Oktober, also vier Tage vor der offiziellen Veröffentlichung.

Seit der Veröffentlichung registrieren Amazon, Cloudflare und weitere Sicherheitsfirmen zahlreiche Angriffsversuche. Laut Amazon wird PHP2Shell inzwischen breit ausgenutzt. Ob die Versuche auf echten Systemen erfolgreich waren, ist noch offen. Zudem kursiert erster Angriffscode öffentlich.

‍

Welche PHP-Versionen betroffen sind

Betroffen ist jede PHP-Installation, die Webanfragen beantwortet. Das PHP-Team nennt ausdrücklich PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Laut Wiz reichen die Lücken bis PHP 5.4 zurück. Jede Version der letzten zehn Jahre ist von mindestens einer der beiden Lücken betroffen.

Eine Stolperfalle gibt es bei Linux-Servern. Distributionen wie Debian, Ubuntu oder Red Hat bauen Sicherheitsfixes oft in ihre bestehenden Pakete ein. Die Versionsnummer sieht dann alt aus, das Paket ist aber geflickt. Massgebend ist die Paketversion, die Dein Hoster oder Distributor als gepatcht ausweist.

Wie gross das Problem mit alten Versionen ist, zeigt ein Blick auf die Zahlen. Von allen Websites mit PHP laufen laut W3Techs noch 27 Prozent auf PHP 7 und 7.7 Prozent auf PHP 5. Für diese Versionen gibt es vom PHP-Projekt seit Jahren keine regulären Updates mehr.

‍

Diese Systeme laufen typischerweise mit PHP

Vielen Unternehmern ist gar nicht bewusst, dass ihre Website auf PHP läuft. Die folgenden Systeme basieren darauf. Nutzt Du eines davon selbst gehostet oder bei einem klassischen Webhoster, gehört das Thema heute auf Deine Liste.

• Content-Management-Systeme: WordPress, Joomla, Drupal, TYPO3, Contao, Craft CMS, Kirby, Concrete CMS, ProcessWire
• Onlineshops: WooCommerce, Magento und Adobe Commerce, Shopware, PrestaShop, OpenCart
• Individuelle Anwendungen: Projekte mit Laravel, Symfony oder anderen PHP-Frameworks, etwa Kundenportale oder Buchungstools
• Weitere Webanwendungen: Nextcloud, Matomo, Moodle, MediaWiki, phpMyAdmin, Roundcube
• Versteckte Installationen: Hosting-Panels, Admin-Oberflächen, interne Fachanwendungen und Geräte mit Weboberfläche

Den letzten Punkt betont auch das BACS. PHP steckt oft in Verwaltungsoberflächen, Containern oder Appliances, ohne dass die Betreiber davon wissen. Aus unserer Erfahrung gilt das auch für vergessene Testinstallationen auf Subdomains.

Anders liegt der Fall bei gehosteten Plattformen wie Webflow, Shopify oder Wix. Dort betreibt der Anbieter die Server selbst. Du hast keinen eigenen PHP-Server, den Du aktualisieren musst.

‍

Was Du jetzt konkret tun solltest

1. PHP-Version herausfinden

In WordPress findest Du sie unter Werkzeuge, Website-Zustand, Bericht und dort im Bereich Server. Bei anderen Systemen steht sie meist im Admin-Bereich oder im Kundencenter Deines Hosters.

2. Beim Hoster nachfragen

Bei Shared Hosting spielt der Hoster die PHP-Updates ein, nicht Du. Frag nach, ob die PHP-Versionen auf Deinem Paket die Fixes für CVE-2026-109618 und CVE-2026-109619 enthalten und ob alle PHP-Prozesse danach neu gestartet wurden. Das BACS empfiehlt, sich die Behebung vom Anbieter bestätigen zu lassen.

3. Eigenen Server sofort patchen

Betreibst Du einen eigenen Server oder VPS, spiel die Updates Deiner Distribution sofort ein. Starte danach PHP-FPM beziehungsweise Apache neu und baue Container neu. Erst dann läuft die geflickte Version wirklich.

4. Veraltete Versionen anheben

Steht bei Dir PHP 8.1 oder älter, ist jetzt der Moment für den Wechsel auf eine unterstützte Version. Prüf vorher, ob Theme und Plugins damit funktionieren. Am sichersten testest Du das auf einer Kopie der Website.

5. Auf Spuren eines Angriffs prüfen

Ein Update schliesst die Tür, wirft aber niemanden hinaus. Das BACS rät, Logs und Systeme auf ungewöhnliche Anfragen, Abstürze, veränderte Dateien und unbekannte Prozesse zu prüfen. In WordPress gehören dazu auch neue Admin-Konten oder Plugins, die niemand installiert hat.

6. Übergangslösungen nur als Überbrückung

Wer nicht sofort aktualisieren kann, findet in der Sicherheitsmeldung von PHP Einstellungen, die einzelne Angriffswege blockieren. Dazu gehört etwa das Abschalten von session.upload_progress. Das PHP-Team schreibt aber klar, dass diese Massnahmen eine Installation nicht sicher machen. Auch eine Web Application Firewall allein genügt laut BACS nicht.

‍

Den Anlass nutzen und die Infrastruktur prüfen

PHP2Shell ist ein Ausnahmefall, aber kein Einzelfall. Jede selbst gehostete Website besteht aus Schichten, die alle gepflegt werden müssen. Server, PHP-Version, CMS, Theme und jedes einzelne Plugin.

WordPress ist dabei nicht per se unsicher. Mit sauberem Hosting, regelmässigen Updates und einem klaren Verantwortlichen läuft es zuverlässig. In der Praxis sehen wir bei KMU aber oft das Gegenteil. Die Website wurde vor Jahren gebaut, die Agentur gibt es nicht mehr, und niemand weiss genau, wer für Updates zuständig ist.

Genau dann lohnt sich ein ehrlicher Blick auf drei Fragen.

• Verantwortung: Wer kümmert sich bei Dir um Updates, und wie schnell reagiert diese Person bei einer Lücke wie dieser?
• Aufwand: Wie viele Stunden und Franken fliessen jedes Jahr in Wartung, Plugins und Sicherheit?
• Alternative: Würde eine Plattform ohne eigenen Server, etwa Webflow, diesen Aufwand für Dich wegnehmen?

Die Antwort muss nicht immer ein Relaunch sein. Manchmal reicht ein Wartungsvertrag oder ein besseres Hosting. Wie sich die Systeme im Alltag unterscheiden, zeigt unser Vergleich Webflow vs. WordPress. Wenn ein Neustart sinnvoll ist, hilft Dir die Relaunch-Checkliste bei der Planung.

‍

Unverbindliche Beratung zu Deiner Website

Du weisst nicht genau, auf welchem System Deine Website läuft oder ob Dein Hoster schon reagiert hat? Wir schauen es uns gemeinsam mit Dir an. Im Gespräch zeigen wir Dir, wo Deine Website heute steht und welche Möglichkeiten Du hast, vom sauberen Update bis zum Wechsel auf eine wartungsarme Plattform.

Das Gespräch ist kostenlos und ohne Verkaufsdruck. Buch Dir hier einen Termin, wir melden uns innerhalb von 24 Stunden.

‍

Quellen

• PHP-Projekt, Security advisory vom 21. Oktober 2026
• GitHub Advisory GHSA-w8hw-w9fx-j79w zu CVE-2026-109618
• GitHub Advisory GHSA-6wmf-4rv5-p3rp zu CVE-2026-109619
• BACS, Kritische Schwachstellen in PHP, Sicherheitsupdates sofort einspielen
• BSI, Cybersicherheitswarnung zu PHP
• BSI, Pressemitteilung vom 21. Oktober 2026
• Wiz Research, PHP2Shell
• Amazon Threat Intelligence, Ausnutzung vor der Veröffentlichung
• Rapid7, technische Einordnung beider CVEs
• php2shell.com, Übersicht und Credits der Entdecker
• watchTowr, aktive Ausnutzung von PHP2Shell
• Netzwoche, Kritische PHP-Sicherheitslücken machen Websites angreifbar
• W3Techs, Verbreitung von PHP und PHP-Versionen

‍

Passend dazu

• eMudhra-Zertifikate kompromittiert, der Schlüssel mit dem Wert 4
• Webflow vs. WordPress im Vergleich
• Relaunch-Checkliste für Deine Website
• Was kostet eine Webseite?