Kaffee läuft. Wir auch. Noch bis 18:00 Uhr erreichbar.

PHP-Lücke PHP2Shell: Was Website-Inhaber jetzt prüfen sollten

·

Blogger Bernhard

Seit Dienstag kursiert in Fachkreisen ein neuer Name mit unangenehm vertrautem Klang: „PHP2Shell“. Gemeint sind zwei kritische Sicherheitslücken in PHP – der Programmiersprache, auf der WordPress, Joomla, Shopware, viele Onlineshops und auch selbst betriebene Nextcloud-Installationen laufen. Am 21. Oktober 2026 hat das PHP-Projekt Updates veröffentlicht, am selben Tag hat das BSI gewarnt.

Wer eine Firmenwebsite, einen kleinen Shop oder ein Kundenportal betreibt, muss deshalb nicht nachts den Server neu aufsetzen. Er sollte aber wissen, wer bei ihm für PHP zuständig ist – und ob diese Stelle schon gehandelt hat. Dieser Beitrag erklärt, was bekannt ist, welche Hosting-Variante welche Aufgaben mit sich bringt und welche Fragen Sie heute stellen sollten.

Was passiert ist – und was gesichert ist

Das PHP-Projekt hat am 21. Oktober 2026 die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei Schwachstellen (CVE-2026-109618 und CVE-2026-109619), die jeweils mit 9,2 von 10 Punkten (CVSS 4.0) als kritisch eingestuft sind. Laut PHP-Sicherheitshinweis können Angreifer darüber unter Umständen ohne Anmeldung eigenen Code auf dem Webserver ausführen. Betroffen sind nach Angaben des Projekts alle PHP-Installationen, die Webanfragen beantworten – unabhängig davon, ob PHP über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed läuft. Das höchste Risiko sieht das PHP-Team bei Apache mit mod_php.

Technisch geht es um den Umgang von PHP mit Speicherfehlern und abgebrochenen Anfragen. Für die Praxis zählt vor allem: Die Lücke steckt nicht in WordPress, einem Plugin oder einem Theme, sondern in der Laufzeitumgebung darunter. Ein WordPress-Update schließt sie deshalb nicht. Geschlossen wird sie nur durch eine korrigierte PHP-Version auf dem Server.

Ganz ruhig verlief die Veröffentlichung nicht. Laut Tenable kursierten die CVE-Kennungen am 20. Oktober auf Hacker News und in sozialen Medien; laut PHP Foundation war die Veröffentlichung ursprünglich für den 22. Oktober geplant und wurde deshalb um einen Tag vorgezogen. Linux-Distributionen und Anbieter von Langzeitsupport hatten die Korrekturen laut PHP-Projekt bereits vorab erhalten.

Was noch nicht geklärt ist

Zur Ausnutzung der Lücken liegen inzwischen mehrere Meldungen vor. Laut Tenable hat Amazon einen ersten Angriffsversuch auf sein Honeypot-Netz (eine absichtlich ungeschützte Falle) bereits am 17. Oktober beobachtet, vier Tage vor der Veröffentlichung, weitere am 21. Oktober – ob diese Versuche bei echten Systemen erfolgreich gewesen wären, ist laut Amazon unklar. Amazon spricht inzwischen von breiten Ausnutzungsversuchen („in the wild“). Das Sicherheitsunternehmen watchTowr hat nach eigener Aussage beide Lücken nachgestellt und beobachtet Ausnutzungsversuche. Am 24. Oktober meldete der Sicherheitsforscher Adel Karimi erfolgreiche Angriffe auf drei Honeypot-Server mit PHP 8.4.26; sie waren laut Bericht bewusst günstig konfiguriert und sagen nichts darüber, wie zuverlässig der Angriff bei anderen Konfigurationen funktioniert. Die US-Behörde CISA hat beide Lücken am 26. Oktober in ihren Katalog bekanntermaßen ausgenutzter Schwachstellen (KEV) aufgenommen.

Unsere Einordnung: Dass die Lücken aktiv ausgenutzt werden, ist durch die KEV-Aufnahme belegt. Wie viele echte Server bisher übernommen wurden, geht aus den genannten Quellen nicht hervor. Für Website-Betreiber ist das ein Grund zu zügigem Handeln, aber keiner für Panik.

Wer ist zuständig? Das hängt vom Hosting ab

Die wichtigste Frage für Selbstständige und kleine Betriebe ist nicht technisch, sondern organisatorisch: Wer kümmert sich bei Ihnen um PHP? Grob gibt es drei Fälle.

Webhosting-Paket oder Managed Hosting

Sie wählen im Kundenbereich höchstens eine PHP-Version aus, um den Server kümmert sich der Anbieter – der Normalfall bei kleinen Firmenwebsites. Hier muss der Hoster die korrigierte PHP-Version einspielen; Sie können das gar nicht selbst.

Viele Anbieter haben schnell reagiert. Laut einer Übersicht von severint.net (letzter Stand 31. Oktober 2026, 20:26 Uhr MEZ) melden unter anderem Hetzner, netcup, Mittwald, Uberspace und Contabo auf ihren Statusseiten, dass ihre Webhosting-Systeme aktualisiert sind. Einige haben dafür Websites oder Upload-Funktionen vorübergehend abgeschaltet – falls Ihre Seite am Mittwoch zeitweise nicht erreichbar war, könnte das der Grund sein. Laut der Übersicht fehlt von drei Anbietern noch jede Äußerung. Das heißt nicht, dass dort nichts passiert ist – aber es heißt, dass Sie nachfragen sollten.

Eigener virtueller oder dedizierter Server

Wer einen vServer, Root-Server oder „Cloud-Server“ gemietet hat, ist selbst Administrator – oder hat einen Dienstleister, der es ist. Die Anbieter sind hier eindeutig: IONOS, Contabo, dogado, Hostinger und andere weisen laut der unten genannten Übersicht darauf hin, dass Kunden bei selbst verwalteten Servern die Updates selbst einspielen müssen. Das gilt auch für den Raspberry Pi oder das NAS im Büro, falls darauf eine PHP-Anwendung läuft, die aus dem Internet erreichbar ist.

Agentur oder IT-Dienstleister betreut die Website

Häufig hat eine Agentur die Seite gebaut und „kümmert sich drum“. Ob das Serverupdates umfasst, steht im Wartungsvertrag – oder eben nicht. Genau diese Lücke zwischen „die Agentur macht WordPress-Updates“ und „der Hoster macht den Server“ ist der Punkt, an dem Dinge liegen bleiben.

Was Sie heute konkret tun können

  1. Hosting-Variante klären. Ein Blick in Vertrag oder Rechnung genügt: Steht dort „Webhosting“, „Managed“ oder ein Tarifname mit Speicherplatz, ist der Anbieter zuständig. Steht dort „vServer“, „Root“ oder „VPS“, sind Sie es oder Ihr Dienstleister.
  2. Statusseite des Anbieters lesen. Meldet die Status- oder Störungsseite, dass die PHP-Systeme aktualisiert sind, ist der wichtigste Teil erledigt. Findet sich nichts, schreiben Sie dem Support eine kurze Mail mit der Frage: „Sind die PHP-Versionen auf meinem Paket gegen CVE-2026-109618 und CVE-2026-109619 abgesichert?“
  3. PHP-Version nachsehen. In WordPress finden Administratoren sie unter „Werkzeuge“ → „Website-Zustand“ → „Bericht“ (englisch: Site Health → Info) im Abschnitt „Server“. Alternativ steht die eingestellte Version im Kundenbereich des Hosters.
  4. Bei 8.1 oder älter: wechseln. Für PHP 8.1 und ältere Versionen veröffentlicht das PHP-Projekt keine fertigen Updates mehr, sondern nur noch minimale Korrekturen im Quellcode für 7.4 bis 8.1; noch ältere Versionen erhalten vom Projekt gar nichts. Ob Ihr Hoster diese Korrekturen selbst einbaut, ist seine Sache – und nicht garantiert. Der saubere Weg ist der Wechsel auf eine unterstützte Version, sinnvollerweise 8.3 oder 8.4. Vorher eine Sicherung anlegen und danach die Website durchklicken, denn ältere Plugins vertragen neuere PHP-Versionen nicht immer.
  5. Eigener Server: Updates einspielen und PHP neu starten. Die Distributionen liefern die Korrekturen als normale Paketupdates. Wichtig ist, danach PHP-FPM bzw. den Webserver neu zu starten, sonst läuft der alte Code weiter. PHP aus Fremdquellen (Control-Panels, Zusatz-Repositories) wird von der Distribution nicht mit aktualisiert und muss gesondert geprüft werden.

Vorsicht beim Vergleich von Versionsnummern

Eine angezeigte Versionsnummer wie „8.2.29“ bedeutet nicht automatisch „ungeschützt“. Linux-Distributionen und manche Hoster bauen Sicherheitskorrekturen in ihre eigenen Pakete ein, ohne die Versionsnummer auf den Stand des PHP-Projekts anzuheben. AlmaLinux etwa kündigt solche Korrekturen ausdrücklich auch für PHP 7.4 und 8.2 an. Verlässlich ist am Ende nur die Aussage dessen, der das PHP auf dem Server betreibt.

Notlösungen ersetzen kein Update

Das PHP-Projekt nennt einige Konfigurationsänderungen, etwa das Abschalten der Funktion „session.upload_progress“, die einzelne Angriffswege erschweren. Es betont aber, dass diese nur bestimmte Pfade abdecken und kein vollständiger Ersatz sind. Auch die Schutzregeln, die Cloudflare laut eigenen Angaben für bekannte Angriffsmuster ausgerollt hat, wirken nur für Datenverkehr, der über Cloudflare läuft, und sind als Übergangslösung gedacht. Das britische NCSC rät laut Help Net Security, nicht zeitnah aktualisierbare Systeme vom Netz zu nehmen – für eine Firmenwebsite ist ein Tag Wartungsseite meist das kleinere Übel.

Update eingespielt – ist damit alles gut?

Meistens ja, aber nicht zwingend. Ein Update schließt die Lücke für die Zukunft. Wurde ein Server vorher bereits angegriffen, entfernt es keine hinterlassene Hintertür. Amazon empfiehlt laut Tenable, bei Untersuchungen mindestens bis zum 17. Oktober zurückzuschauen, nicht erst ab dem Tag der Veröffentlichung.

Für eine kleine Website heißt das realistisch:

  • Auf Auffälligkeiten achten: unbekannte Administrator-Konten, neue Dateien, die niemand angelegt hat, plötzliche Weiterleitungen auf fremde Seiten, Spam-Mails aus dem eigenen Webspace oder Warnungen des Hosters.
  • Sicherungen prüfen: Gibt es eine Sicherung der Website von vor dem 17. Oktober – und lässt sie sich im Ernstfall auch zurückspielen? Wie man das testet, steht in „Backup vorhanden – aber lässt es sich auch wiederherstellen?“.
  • Bei konkretem Verdacht: nicht einfach weiterlaufen lassen, sondern Hoster oder Dienstleister einschalten. Dann gehören in der Regel auch Passwörter für Datenbank, Administratorkonten und angebundene Dienste geändert. Sind dabei möglicherweise personenbezogene Daten von Kunden betroffen, kann eine Meldepflicht nach der DSGVO bestehen (Art. 33, grundsätzlich innerhalb von 72 Stunden). Das sollte im Einzelfall mit dem Datenschutzbeauftragten oder einer rechtlichen Beratung geklärt werden.

Grenzen und offene Punkte

  • Die Lage entwickelt sich weiter. Angaben zum Ausmaß der Angriffe stammen überwiegend von Sicherheitsfirmen. Stand dieses Beitrags: 1. November 2026.
  • Die Übersicht der Hoster-Reaktionen stammt von einer Drittseite, die ihrerseits Statusseiten auswertet. Den aktuellen Stand Ihres Anbieters erfahren Sie nur direkt bei ihm.
  • Ob und wie gut eine konkrete Anwendung auf einem konkreten Server angreifbar ist, hängt von Konfiguration und Einsatzart ab. Bei PHP-FPM etwa ist die Lücke laut PHP-Advisory nur unter bestimmten Bedingungen erreichbar, zum Beispiel wenn der vorgeschaltete Webserver PHP_VALUE-Parameter übergibt. Eine pauschale Entwarnung für bestimmte Konstellationen gibt es aus unserer Sicht nicht.
  • PHP 8.2 erhält laut PHP-Projekt nur noch bis 31. Dezember 2026 Sicherheitsupdates. Wer jetzt ohnehin wechselt, sollte nicht auf 8.2 stehen bleiben.
  • Menübezeichnungen in WordPress und bei Hostern können je nach Version und Sprache abweichen.

Fazit: Eine Mail an den Hoster, ein Blick auf die Version

PHP2Shell ist ernst, weil PHP fast überall läuft – laut W3Techs auf rund 69 Prozent der Websites, deren Serversprache bekannt ist. Für die typische kleine Firmenwebsite im Webhosting-Paket ist die Arbeit trotzdem überschaubar: Der Hoster muss das Update einspielen, Sie müssen sich vergewissern, dass er es getan hat, und eine veraltete PHP-Version endlich anheben. Wer einen eigenen Server betreibt, hat heute dagegen echte Arbeit – oder sollte jemanden haben, der sie erledigt. Und wie bei Router-Firmware gilt auch hier: „Läuft doch noch“ ist kein Konzept. Wer ohnehin Zuständigkeiten klärt, kann gleich die Zertifikate mit auf die Liste setzen – siehe „Kürzere Zertifikatslaufzeiten: Was Sie jetzt prüfen sollten“.

Sie wissen nicht genau, wer bei Ihrer Website für Server und PHP zuständig ist, oder betreiben einen eigenen Server, der jetzt Aufmerksamkeit braucht? DGH-IT schaut sich das gern mit Ihnen an – ohne Verkaufsdruck.

Quellen & weiterführende Informationen

Alle Quellen abgerufen am 01.11.2026.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert