Wie sicher ist PHP nach PHP2Shell noch?

Die Universität Freiburg schaltete am Vormittag des 21. Oktober 2026 Webseiten, Intranet und Lernplattform ab, in den Niederlanden gingen die Websites der Bürgerportale DigiD und MijnOverheid vom Netz. Auslöser waren zwei Fehler im PHP-Interpreter, von denen laut dem Sicherheitsunternehmen Wiz mindestens einer bis zu PHP 5.4 aus dem Jahr 2012 zurückreicht. Auf PHP laufen 69,3 Prozent aller Websites, deren serverseitige Programmiersprache die Marktforscher von W3Techs erkennen.

Für jeden, der eine Website, einen Shop oder ein Intranet betreibt, lässt sich aus diesem Mittwoch eine unbequeme Lehre ziehen: Angriffe beginnen inzwischen oft schon vor dem Update, spätestens wenige Stunden danach, und viele Server bekommen die Korrektur gar nicht. Hier lesen Sie, was bei PHP2Shell passiert ist, warum ein Fehler in PHP so viele Websites trifft, wie die Sprache so groß wurde und was Sie jetzt tun sollten.

Wissenstest

Was wissen Sie über PHP und PHP2Shell?

5 Fragen aus dem Artikel. Wählen Sie Ihre Antwort, dann decken Sie die Lösung auf.

1 Wofür stand PHP, als Rasmus Lerdorf die Werkzeuge 1995 ankündigte? Aufklappen ↓

Auflösung aufdecken ↓

Richtig: A. Lerdorf schrieb die kleinen Programme für seine eigene Homepage. Seit PHP 3.0 steht der Name für „PHP: Hypertext Preprocessor“.

APersonal Home Page Tools BProgrammable Hypertext Processor CPHP Hosting Platform

2 Auf welchem Anteil der Websites mit erkennbarer serverseitiger Programmiersprache läuft PHP laut W3Techs? Aufklappen ↓

Auflösung aufdecken ↓

Richtig: B. Auf Platz zwei folgt JavaScript mit 8,1 Prozent. Die 39,6 Prozent sind der Anteil von WordPress an allen Websites.

A39,6 Prozent B69,3 Prozent C85,1 Prozent

3 Welche PHP-Version bekommt seit dem 1. Januar 2026 keine Sicherheitsupdates des PHP-Teams mehr? Aufklappen ↓

Auflösung aufdecken ↓

Richtig: A. Die Pflege von PHP 8.1 endete am 31. Dezember 2025. Für PHP2Shell lieferte das PHP-Team ausnahmsweise eine kleine Quellcode-Korrektur.

APHP 8.1 BPHP 8.3 CPHP 8.4

4 Welcher Anteil der 11.334 Lücken im WordPress-Ökosystem steckte 2025 laut Patchstack in Plugins? Aufklappen ↓

Auflösung aufdecken ↓

Richtig: C. Neun Prozent betrafen Themes, sechs Lücken den WordPress-Kern. Das vierte Kapitel vergleicht das mit den Lücken im Interpreter.

A6 Prozent B46 Prozent C91 Prozent

5 Was sollten Sie nach dem PHP-Update auf dem Server zusätzlich tun? Aufklappen ↓

Auflösung aufdecken ↓

Richtig: B. Ohne Neustart läuft im Speicher noch der alte Interpreter. Weil die Lücken Speicherinhalte preisgeben können, sollten Sie Passwörter und API-Schlüssel neu setzen.

AWordPress neu installieren BDen PHP-Dienst neu starten und Zugangsdaten wechseln CDen Wartungsmodus einschalten

Quelle: Dr. Web Fachartikel „Wie sicher ist PHP nach PHP2Shell noch?“

© 2026 Dr. Web | Das Fachportal für Entscheider | Quiz von Dr. Web

Was ist bei PHP2Shell passiert?

Zwei Fehler im PHP-Interpreter erlauben Angreifern, ohne Anmeldung eigenen Code auf Webservern auszuführen. Einzelheiten kursierten am 20. Oktober 2026 schon vor dem Update, am 21. Oktober erschienen die abgesicherten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Die Sicherheitsfirma Calif meldete dem PHP-Team den ersten Fehler am 11. August 2026, Wiz Research folgte am 24. August. Wiz schreibt, die eigenen Forscher hätten die erste Lücke am 19. August mit dem Werkzeug Wiz Atlas sowie den Sprachmodellen Gemini 4 Argon und GPT-5.6 Sol entdeckt. Auf der Projektseite zur Lücke stehen Wiz, OpenAI und Calif als Entdecker.

Am 21. September bestätigte das PHP-Team die Meldungen und begann im Stillen mit der Korrektur.

Am Nachmittag des 20. Oktober nannte ein später gelöschter Beitrag auf Hacker News beide Lücken, bevor das Update fertig war. Die Sicherheitsfirma watchTowr bestätigte die Funde kurz darauf. Firmenchef Benjamin Harris schrieb, übersetzt aus dem Englischen: „Wir können bestätigen, dass diese Schwachstellen echt sind.“ Am Abend kündigte das PHP-Sicherheitsteam auf php.net ein kritisches Update für Mittwoch, 16 Uhr deutscher Zeit, an und behielt sich vor, die Veröffentlichung vorzuziehen, sobald weitere Einzelheiten bekannt würden.

Was diese Vorwarnung des PHP-Teams für Hoster und Betreiber bedeutete, haben wir am Mittwochmorgen zusammengefasst.

PHP2Shell: vom ersten Fund bis zum Update

Die wichtigsten Stationen von August bis zum 21. Oktober 2026, Uhrzeiten nach deutscher Zeit.

9,2

von 10 Punkten nach CVSS 4.0 für jede der beiden Lücken

4

abgesicherte Versionen: 8.5.12, 8.4.27, 8.3.36 und 8.2.35

seit 5.4

steckt laut Wiz in fast jeder Version mindestens einer der Fehler

3 / Orange

Kritikalität laut BSI: Maßnahmen müssen unverzüglich ergriffen werden

11.08.

Erste Meldung

Calif meldet dem PHP-Team den ersten Fehler, am 24. August folgt Wiz.

20.10.

Leak

Ein später gelöschter Beitrag auf Hacker News nennt beide Lücken, watchTowr bestätigt sie.

20.10.

Vorwarnung

Das PHP-Team kündigt auf php.net ein Update für Mittwoch, 16 Uhr, an.

21.10., 5:02

Firewall-Regeln

Cloudflare verteilt Regeln gegen beide Lücken.

21.10., 9:34

Erste Angriffsmeldungen

Hoster melden Patchstack Angriffe, bestätigte Einbrüche nennt bis zum Abend niemand.

21.10., 10:39

Abschaltungen

Die Uni Freiburg nimmt Webseiten, Intranet und ILIAS vom Netz, mittags ist DigiD.nl nicht erreichbar.

21.10., 15:30

Update

Die abgesicherten Versionen erscheinen kurz vor dem angekündigten Termin.

Die Uhrzeit des Updates nennt CERT-EU, Patchstack nennt 15:52 Uhr, angekündigt war 16 Uhr. Den Zeitpunkt des Leaks auf Hacker News kennen wir nur aus Sekundärquellen.

Quellen: php.net, Sansec, Wiz, BleepingComputer, Cloudflare, Patchstack, Universität Freiburg, NOS, CERT-EU, BSI. © 2026 Dr. Web | Das Fachportal für Entscheider | Infografik von Dr. Web

In der Nacht schob Cloudflare ab 5:02 Uhr deutscher Zeit Regeln in seine Firewall für Webanwendungen, die Angriffe auf beide Lücken abfangen sollen. Cloudflare-Technikchef Dane Knecht sprach von ersten Angriffen und nannte die Regeln eine Notlösung. Um 9:34 Uhr verzeichnete der Sicherheitsanbieter Patchstack die ersten Meldungen von Hostern über Angriffe.

Bestätigte Einbrüche meldete am Mittwoch niemand. Das BSI konnte die Berichte über Angriffe nicht verifizieren.

Vorsorglich gingen trotzdem viel genutzte Dienste vom Netz. Das Rechenzentrum der Universität Freiburg meldete um 10:39 Uhr, Webseiten, Intranet, die Lernplattform ILIAS und das Webmail der Studierenden seien abgeschaltet. Nach einem Bericht der Stuttgarter Nachrichten folgten die Universitäten Heidelberg, Tübingen, Ulm sowie das KIT, dazu die Webseiten der baden-württembergischen Landesregierung. In Mainz schaltete die Stadt ihr Portal und mehrere Dienste ab, in den Niederlanden meldete der Sender NOS um 12:48 Uhr, die Websites der Bürgerportale DigiD und MijnOverheid seien nicht erreichbar.

Die abgesicherten Versionen erschienen kurz vor dem angekündigten Termin, CERT-EU nennt 15:30 Uhr, Patchstack 15:52 Uhr.

Das BSI stuft die Lage mit der Kritikalität 3 auf seiner vierstufigen Skala ein, Farbe Orange, und rät, Server notfalls vorübergehend vom Internet zu trennen. „Es besteht also unverzüglicher Handlungsbedarf!“, sagte BSI-Vizepräsident Thomas Caspers. Seine Behörde rechnet damit, dass Angreifer die Updates mit KI-Werkzeugen binnen kurzer Zeit auswerten und in Exploits verwandeln.

Was im Interpreter schiefläuft

Bei CVE-2026-109618 unterbricht die Behandlung eines Speicherengpasses den Interpreter, während interne Daten einer Anfrage erst halb angelegt sind. Beim Aufräumen hält PHP diese unfertigen Daten dann für gültig. Auslösen lässt sich der Engpass über präparierte Formulardaten im Format multipart/form-data, wie Browser sie für Datei-Uploads senden. PHP zerlegt solche Daten selbst, bevor überhaupt eine Zeile WordPress- oder Shop-Code läuft.

Bei CVE-2026-109619 bleiben interne Daten einer Anfrage erhalten, obwohl PHP den zugehörigen Speicher schon freigegeben hat. Die nächste Anfrage an denselben PHP-Prozess greift auf diese Reste zu, Fachleute nennen das einen Use-after-free.

Am höchsten schätzt das PHP-Team das Risiko für Apache mit dem Modul mod_php ein.

Laut Sansec geben die Lücken auch Speicherinhalt preis, ähnlich wie 2014 Heartbleed bei OpenSSL. Die Daten tauchen dann im Sitzungs-Cookie PHPSESSID auf. Wiz las in einem weiteren Versuch Passwörter und API-Schlüssel aus dem Arbeitsspeicher der PHP-Prozesse.

Ein Angriff verlangt einige Tausend bis Zehntausende Anfragen an denselben Server. Eine Anmeldung oder das Zutun eines Nutzers braucht der Angreifer nicht.

Warum trifft ein Fehler in PHP so viel vom Web?

PHP läuft auf 69,3 Prozent aller Websites, deren serverseitige Programmiersprache W3Techs erkennt, und der Fehler sitzt im Interpreter selbst. Jede Anwendung darauf erbt diese Schwäche, von WordPress über Drupal bis Magento, und kein Update der Anwendung schließt die Lücke.

Der Marktforscher W3Techs untersucht laufend Websites mit nennenswertem Inhalt und ordnet ihnen eine serverseitige Sprache zu, sofern sie sich erkennen lässt, hier mit Stand 21. Oktober 2026. Auf Platz zwei folgt JavaScript mit 8,1 Prozent, das Ruby im Spätsommer 2026 überholt hat.

WordPress steckt nach W3Techs hinter 39,6 Prozent aller Websites und hinter 58,3 Prozent derer mit erkennbarem Content-Management-System. Joomla, Drupal, TYPO3, PrestaShop und Contao sind ebenfalls in PHP geschrieben, dazu die Shopsysteme Magento und Shopware.

Wiz führte auf aktuellen Testinstallationen von WordPress, Drupal und Joomla ohne Anmeldung eigenen Code aus. Sansec listet erfolgreiche Testangriffe auf Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, Nextcloud 35.0.1 und Laravel 13.11. Die Wiz-Installationen waren jeweils auf dem neuesten Stand, genützt hat das keiner.

Ein Fehler im Interpreter gleicht einem Riss im Fundament eines Mietshauses. Ob im Erdgeschoss eine Bäckerei oder eine Kanzlei sitzt, ändert am Riss nichts, und ein frischer Anstrich im Laden auch nicht.

Das BSI formuliert das nüchterner: „Ein Update der Anwendungen ist daher nicht ausreichend, die zugrundeliegende PHP-Laufzeitumgebung muss ebenfalls gepatcht werden.“

Für einen WordPress-Betreiber heißt das: Das Dashboard meldet alles grün, und die Website ist trotzdem angreifbar. Bei Shared und Managed Hosting kümmert sich der Hoster um PHP, auf einem eigenen virtuellen oder dedizierten Server bleibt die Aufgabe beim Betreiber. Kommt PHP aus den Paketquellen der Linux-Distribution, liefert deren Sicherheitsteam die Korrektur. Debian stellte Pakete für PHP 8.2 und 8.4 bereit, Ubuntu lieferte am 21. Oktober Updates für 8.1, 8.3 und 8.5.

Wie viele Server erreichbar sind, lässt sich nur schätzen, weil die meisten ihre PHP-Version verbergen. Der zu Google gehörende Dienst VirusTotal zählte am 21. Oktober rund 5,1 Millionen IP-Adressen, die PHP verrieten. Rund 1,1 Millionen davon nannten ihre Version.

Auf mindestens rund 846.000 dieser Adressen lief eine Version, die das PHP-Team nicht mehr pflegt.

Die ganz großen PHP-Nutzer haben sich zum Teil schon vor Jahren abgekoppelt. Facebook entwickelte mit Hack einen eigenen Ableger, die Laufzeitumgebung HHVM unterstützt seit ihrer eigenen Version 4.0 kein PHP mehr. Slack startete 2014 mit PHP 5, wechselte 2016 zu HHVM und danach zu Hack. Die Wikimedia-Server, auf denen die Wikipedia läuft, nutzen dagegen weiter normales PHP, derzeit in Version 8.3.

Wie wurde aus einem Werkzeug für die eigene Homepage die Sprache des Webs?

Rasmus Lerdorf schrieb 1994 ein paar kleine C-Programme für seine eigene Homepage und nannte sie Personal Home Page Tools. Ab 1997 bauten Andi Gutmans und Zeev Suraski daraus eine vollwertige Sprache, die mit jeder Hauptversion strenger und mit PHP 7 deutlich schneller wurde.

Am 8. Juni 1995 kündigte Lerdorf in der Usenet-Gruppe comp.infosystems.www.authoring.cgi die Version 1.0 seiner „PHP Tools“ an. Die kleinen CGI-Programme zählten Besucher, protokollierten Zugriffe, schützten Seiten mit Passwörtern und lieferten Formulare und ein Gästebuch.

„Ich hatte nicht vor, eine Sprache zu schreiben. Ich hatte keine Ahnung, wie man eine Sprache schreibt“, sagte Lerdorf 2012 auf der Entwicklerkonferenz OSCON.

Aus den Werkzeugen wurde PHP/FI, das im November 1997 die Testphase verließ. Zu diesem Zeitpunkt schrieben zwei Entwickler aus Tel Aviv, Andi Gutmans und Zeev Suraski, den Parser bereits neu. Am 6. Juni 1998 erschien PHP 3.0, und der Name bekam eine neue Lesart: PHP steht seitdem für „PHP: Hypertext Preprocessor“, ein Kürzel, das sich selbst enthält. Die beiden Israelis bauten danach den Kern noch einmal. Aus ihren Vornamen bildeten sie den Namen Zend Engine, mit diesem Kern erschien am 22. Mai 2000 PHP 4.

PHP 5 brachte am 13. Juli 2004 ein neues Objektmodell für Klassen und Objekte.

Danach steckte die nächste Hauptversion sechs Jahre fest. PHP 6 sollte Unicode von Grund auf unterstützen, das Vorhaben kam nicht voran. „Die aktuelle Arbeit ist offensichtlich ins Stocken geraten“, schrieb Lerdorf im März 2010 auf der Mailingliste der Kernentwickler und schlug vor, den Zweig beiseitezulegen. Einzelne Neuerungen wie Namespaces erschienen stattdessen schon in PHP 5.3, die nächste große Version hieß nach einer Abstimmung im Juli 2014 gleich PHP 7.

PHP 7 erschien am 3. Dezember 2015. Das PHP-Team versprach eine bis zu doppelt so schnelle Ausführung wie unter PHP 5.6 und einen deutlich geringeren Speicherbedarf.

Mit PHP 8.0 kam am 26. November 2020 ein Just-in-time-Compiler, der Code während der Ausführung in Maschinencode übersetzt. Bei typischen Webanwendungen bringt der Compiler laut php.net keinen Zugewinn, die Leistung liegt auf dem Niveau von PHP 7.4. Messbar schneller werden vor allem rechenlastige Programme, die lange laufen.

PHP 8.1 folgte im November 2021 mit Aufzählungstypen und Fibers, einer Technik für nebenläufige Abläufe.

Im selben Monat kündigte Nikita Popov, einer der produktivsten Kernentwickler, seinen Abschied von JetBrains zum 1. Dezember an und wollte sich künftig vor allem um das Compiler-Projekt LLVM kümmern. JetBrains warnte damals, gestützt auf Zahlen von 2021, die Abhängigkeit von wenigen Köpfen bringe „die Sprache, auf der 78 Prozent des Webs laufen, in eine heikle Lage“, übersetzt aus dem Englischen. Am 22. November 2021 gründeten zehn Unternehmen die PHP Foundation, die seitdem Entwickler für die Arbeit am Kern bezahlt.

Ist PHP eine unsichere Sprache?

Nein, die meisten Lücken stecken in Plugins und Anwendungen, nicht im Interpreter. 2025 verzeichnete die US-Datenbank NVD 13 Lücken in PHP selbst, Patchstack zählte im selben Jahr 11.334 im WordPress-Ökosystem. Der schlechte Ruf stammt aus einer Zeit, als PHP gefährliche Voreinstellungen mitbrachte.

Die bekannteste dieser Voreinstellungen hieß register_globals. PHP legte damit jeden Parameter aus der Adresszeile, aus Formularen und Cookies automatisch als Variable an. Prüfte ein Skript etwa eine Variable namens angemeldet, konnte ein Angreifer sie einfach mit in die Adresse schreiben und sich so selbst anmelden. Mit PHP 4.2.0 war die Funktion ab April 2002 standardmäßig aus. Entfernt wurde register_globals im März 2012 mit PHP 5.4, zusammen mit den Magic Quotes und dem Safe Mode, zwei vermeintlichen Schutzfunktionen.

„Die Sicherheit im Web ist heute miserabel“, sagte Lerdorf 2007 auf einer Konferenz in London. „Ich nehme einen Teil der Schuld voll auf mich, aber nicht alles.“

Für den Interpreter führt die NVD mindestens 747 Einträge, mit einem Höchstwert von 120 im Jahr 2016. Zwischen 2021 und 2023 zählte die NVD jeweils sieben oder acht, 2024 dann 18, 2025 13 und bis zum 21. Oktober 2026 bereits 14.

Drei PHP-Lücken führt die US-Behörde CISA auf ihrer Liste nachweislich ausgenutzter Schwachstellen. Alle drei betreffen die Art, wie PHP an den Webserver angebunden ist.

Viele Interpreter-Lücken haben dieselbe Wurzel wie PHP2Shell. Der Kern von PHP ist in C geschrieben, einer Sprache, die dem Programmierer die Verwaltung des Arbeitsspeichers überlässt. Nach unserer Auswertung der NVD-Daten gehört knapp die Hälfte der PHP-Lücken mit Fehlerklasse zu den Speicherfehlern, gezählt nach den Fehlerklassen für Pufferüberläufe, Zugriffe auf freigegebenen Speicher und Ganzzahlüberläufe.

CISA, NSA, FBI und die Cybersicherheitsbehörden aus vier weiteren Ländern nennen in ihrem Bericht vom Dezember 2023 für Microsoft und das Google-Projekt Chromium einen Anteil der Speicherfehler an den Sicherheitslücken von rund 70 Prozent.

Den alten Code-Bestand schreibt niemand schnell neu, deshalb arbeiten Entwickler an nachträglichen Absicherungen, etwa mit Fil-C, das C-Code speichersicher machen soll.

Für den Alltag eines Website-Betreibers sind die Plugins das größere Risiko. Von den 11.334 Lücken, die Patchstack 2025 im WordPress-Ökosystem fand, steckten 91 Prozent in Plugins, 9 Prozent in Themes und sechs Lücken im WordPress-Kern. Für 46 Prozent lag zum Zeitpunkt der Veröffentlichung noch kein Patch der Entwickler vor. Bei bereinigten Websites fand der Sicherheitsdienst Sucuri 2023 in 39,1 Prozent der Fälle eine veraltete Version des Content-Management-Systems vor.

Gefährlich wird meist nicht die neueste Version, sondern die vergessene. Das gilt für Plugins genauso wie für PHP selbst.

Warum laufen so viele Server auf alten PHP-Versionen?

Ein Wechsel der Hauptversion kostet Arbeit, weil ältere Plugins und eigene Skripte auf neuem PHP oft nicht mehr laufen. Viele Betreiber verschieben den Umstieg deshalb, und Distributionen wie Ubuntu oder Debian pflegen alte Versionen weiter, nachdem das PHP-Team längst aufgehört hat.

Laut WordPress.org laufen 36,4 Prozent aller WordPress-Installationen auf PHP 8.1 oder älter, also auf Versionen, für die das PHP-Team keine regulären Updates mehr veröffentlicht. Allein auf PHP 7.4 laufen 16,1 Prozent, obwohl dessen Pflege am 28. November 2022 endete. Über alle PHP-Websites zeigt W3Techs ein ähnliches Bild: 65,2 Prozent nutzen PHP 8, 27,0 Prozent PHP 7 und 7,7 Prozent noch PHP 5.

Seit einer Abstimmung im Frühjahr 2024 gilt für jede neue Version ein fester Takt. Zwei Jahre lang bekommt jede Version Fehlerkorrekturen, zwei weitere Jahre nur noch Sicherheitsupdates, und die Pflege endet stets am 31. Dezember. Die Entwickler Jakub Zelenka und Derick Rethans hatten den Vorschlag eingebracht, die beiden Punkte zur Pflege wurden ohne Gegenstimme angenommen.

Für PHP 8.2 enden die Sicherheitsupdates am 31. Dezember 2026, in zehn Wochen. Ein Update auf 8.2.35 verschafft also nur einen Aufschub.

Ein Grund für das Zögern steckt im Code selbst: PHP 8.0 entfernte Funktionen wie create_function() und each(), außerdem machte die Version viele frühere Warnungen zu Fehlern, die ein Skript abbrechen. Ein Plugin, das noch auf diese Funktionen setzt, legt nach dem Wechsel die ganze Website lahm, und vor dem Umstieg steht deshalb ein Test, den viele Betreiber Jahr für Jahr verschieben.

Sicherheitsupdates für alte Versionen kommen trotzdem, nur nicht vom PHP-Team. Ubuntu 22.04 liefert PHP 8.1 mit regulärem Support bis Mai 2027 aus und lieferte am 21. Oktober eine korrigierte Fassung nach, Debian 12 versorgt PHP 8.2 über Debian LTS bis Juni 2028 mit Updates. Gegen Geld halten Anbieter wie Zend by Perforce, TuxCare oder Freexian auch PHP 7 und älter am Leben. Für PHP2Shell veröffentlichte das PHP-Team ausnahmsweise kleine Quellcode-Korrekturen für 7.4, 8.0 und 8.1, fertige Pakete daraus müssen Distributionen und Hoster selbst bauen.

Phoenix Security zitiert eine Auswertung über die Suchmaschine Shodan mit 883.717 erreichbaren Hosts mit einer Version ohne offizielle Pflege, rund 59 Prozent aller Hosts mit sichtbarer Versionsangabe. Für Deutschland nennt die Firma 45.835 Hosts und markiert die Zahlen selbst als ungeprüft, eine zweite Quelle haben wir nicht gefunden.

Zend by Perforce schreibt in einem Marktbericht von 2026, 40 Prozent der befragten Unternehmen nutzten noch PHP-Versionen, deren Pflege bereits geendet hat.

Hinter einem alten PHP auf dem Server steht damit eine Entscheidung mit Preis, auch wenn sie niemand bewusst getroffen hat. Bezahlt wird entweder für verlängerte Sicherheitsupdates, für den Umzug auf eine neue Version oder im Ernstfall für den Einbruch.

Wie schnell nutzen Bots eine neue Lücke aus?

Oft schon am Tag der Veröffentlichung oder davor. Mandiant schätzt die mittlere Zeit bis zur Ausnutzung für 2025 auf minus sieben Tage, bei den meistangegriffenen WordPress-Lücken vergingen laut Patchstack im Median fünf Stunden bis zum ersten Angriff.

Laut dem Bad Bot Report 2026 des Sicherheitskonzerns Thales stammten 2025 53 Prozent aller Anfragen im Web von Bots, 40 Prozent aller Anfragen ordnet Thales bösartigen Bots zu. Die Zahl der Angriffe KI-gestützter Bots stieg nach dem Bericht binnen eines Jahres auf das 12,5-Fache.

Ein großer Teil dieser Bots sucht rund um die Uhr nach längst bekannten Schwachstellen. Die Sicherheitsforscher von F5 Labs zählten im August 2025 mehr als 47.000 Angriffsversuche allein auf CVE-2017-9841, eine Lücke im Testwerkzeug PHPUnit aus dem Jahr 2017. Die Datei eval-stdin.php liegt auf manchen Servern noch heute öffentlich im Ordner vendor, weil Entwickler das Testwerkzeug mit hochgeladen haben. Bei einem anderen Scanner, den F5 Labs untersuchte, zielten 80 Prozent der Anfragen auf .env-Dateien mit Zugangsdaten und 11 Prozent auf phpinfo.php.

Der WordPress-Sicherheitsanbieter Wordfence protokollierte 2024 mehr als 54 Milliarden bösartige Anfragen und 55 Milliarden Angriffe auf Passwörter.

Solche Scanner tarnen sich inzwischen auch als KI-Crawler. Zwischen dem 28. Juli und dem 23. August 2026 beobachtete GreyNoise 824 IP-Adressen, die unter gefälschten Namen der Crawler von Anthropic, OpenAI, Google und Perplexity nach .env-Dateien und AWS-Zugangsdaten fragten.

Angriffe kommen oft schon vor dem Patch

Mittlere Zeit zwischen der Veröffentlichung einer Lücke und ihrer ersten Ausnutzung nach Mandiant, dazu aktuelle Werte für 2025.

2018 und 2019

63 Tage

2020 und 2021

44 Tage

2021 und 2022

32 Tage

2023

5 Tage

−7 Tage

mittlere Zeit bis zur Ausnutzung 2025: Angriffe im Schnitt vor dem Patch

5 Std.

Median bis zum ersten Angriff bei den meistangegriffenen WordPress-Lücken 2025

28,96 %

der 2025 ausgenutzten Lücken nutzten Angreifer schon am Tag der Veröffentlichung oder früher aus

53 %

aller Anfragen im Web stammten 2025 von Bots

Mandiant zählt die von seinen Analysten untersuchten, nachweislich ausgenutzten Lücken. Für 2025 schätzt der Bericht M-Trends 2026 minus sieben Tage, also Angriffe vor dem Patch.

Quellen: Google Cloud/Mandiant (Time-to-Exploit 2023, M-Trends 2026), Patchstack, VulnCheck, Thales Bad Bot Report 2026. © 2026 Dr. Web | Das Fachportal für Entscheider | Infografik von Dr. Web

Schneller geworden ist vor allem der Weg vom Patch zum Angriff. Mandiant, die Incident-Response-Sparte von Google Cloud, maß für 2018 und 2019 im Schnitt 63 Tage zwischen Veröffentlichung und erster Ausnutzung, für 2023 noch fünf Tage. Für 2025 schätzt der Bericht M-Trends 2026 minus sieben Tage: Angreifer nutzen Lücken im Schnitt aus, bevor der Patch erscheint. Nach dem Schwachstellendienst VulnCheck nutzten Angreifer 28,96 Prozent der 2025 nachweislich ausgenutzten Lücken schon am Tag der Veröffentlichung oder früher aus.

Nach VulnCheck entfiel im ersten Halbjahr 2026 ein Drittel aller nachweislich ausgenutzten Lücken auf Content-Management-Systeme.

Bei PHP selbst waren Angreifer zuletzt im Juni 2024 schnell. Binnen 24 Stunden nach der Veröffentlichung von CVE-2024-4577 sah Akamai in seinen Honeypots, präparierten Ködersystemen, die ersten Angriffsversuche. Später landeten darüber der Fernzugriffstrojaner Gh0st RAT und Kryptominer auf den Servern.

In einem Versuch des Anthropic-Teams für Sicherheitsforschung baute ein KI-Modell aus 18 veröffentlichten Firefox-Patches acht funktionierende Angriffe, den ersten nach knapp einer Stunde. Die Forscher folgern, ein Einzelner könne die Patches eines Monats an einem Nachmittag in Angriffe verwandeln. Wiz, einer der Entdecker von PHP2Shell, berichtet Ähnliches über die eigene Arbeit: Die Forscher hätten funktionierende Angriffe mit KI-Hilfe in Stunden an mehrere Anwendungen angepasst, ein einzelner Forscher habe in einer Woche geschafft, wofür früher ein Spitzenteam Monate gebraucht hätte.

Sansec erwartete Massenangriffe 15 Minuten nach dem Update.

Ein Update, das am Wochenende oder nach dem nächsten Wartungstermin eingespielt wird, kommt bei einer Lücke dieser Art womöglich Tage zu spät. Nach dem BSI-Lagebericht 2025 richteten sich rund 80 Prozent der angezeigten Angriffe gegen kleine und mittlere Unternehmen, und viele dieser Unternehmen vernachlässigen weiterhin ihre Updates.

Was sollten Website-Betreiber jetzt tun?

Prüfen Sie die PHP-Version und aktualisieren Sie auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, bei Shared Hosting fragen Sie gerne direkt beim Hoster nach. Danach lohnen sich ein Blick in die Protokolle sowie neue Passwörter und Schlüssel für alles, was im Arbeitsspeicher der PHP-Prozesse lag.

Die Schritte gelten für jede Website auf PHP, unabhängig vom System darauf, sortiert nach Dringlichkeit.

1. Version feststellen. In WordPress zeigt der Bereich „Website-Zustand“ unter „Informationen“ die PHP-Version, auf eigenen Servern verrät sie der Befehl php -v. Eine öffentlich erreichbare phpinfo-Datei löschen Sie besser gleich mit, Scanner fragen genau danach.
2. Übergang absichern. Für die Zeit bis zum Update nennt das PHP-Team Einstellungen in der php.ini, etwa session.upload_progress.enabled auf 0, warnt aber, übersetzt aus dem Englischen: „Eine vollständige Abhilfe existiert nicht, sicher ist nur das Update.“ Firewall-Regeln von Cloudflare oder Imperva helfen als Notlösung, der Wartungsmodus von WordPress oder Magento hilft laut Sansec nicht.
3. Update einspielen. Abgesichert sind die vier oben genannten Versionen sowie die Pakete der Distributionen, etwa 8.2.35-1~deb12u1 für Debian 12. Der PHP-Dienst muss danach neu starten, sonst läuft im Speicher noch der alte Interpreter.
4. Protokolle prüfen. Wiz nennt als Anzeichen ungewöhnliche Multipart-Anfragen mit Fehlern zum Speicherlimit, gehäufte HTTP-Fehler 500 und auffällig große PHPSESSID-Cookies.
5. Zugangsdaten wechseln. Weil die Lücken Speicherinhalte preisgeben können, empfehlen wir, Datenbank-Passwörter, API-Schlüssel und die Schlüssel in der wp-config.php neu zu setzen, sobald der Server gepatcht ist.
6. Wechsel planen. Läuft die Website auf PHP 8.2 oder älter, gehört der Umzug auf 8.4 oder 8.5 in die Planung für die nächsten Wochen, mit einem Test auf einer Kopie der Website.

Angebliche Prüfwerkzeuge für PHP2Shell auf GitHub meiden Sie besser: Precursor Security zählte über 100 Repositorys mit Bezug zur Lücke, Tenable warnt vor Schadcode in Beispiel-Exploits.

Haben Sie die Website einer Agentur übergeben, fragen Sie dort gerne nach, wer für das PHP auf dem Server zuständig ist. Erstaunlich oft weiß das keiner der Beteiligten sicher, und in genau dieser Lücke zwischen Hoster, Agentur und Betreiber bleibt ein Server jahrelang auf PHP 7.4 stehen.

Hat PHP nach PHP2Shell eine Zukunft?

Ja, die Sprache folgt einem festen Fahrplan: PHP 8.6 soll am 19. November 2026 erscheinen, die PHP Foundation bezahlt elf Entwickler. Knapp bemessen ist dagegen das Geld, das Unternehmen in die Sprache stecken, auf der ihr Geschäft läuft.

PHP 8.5 brachte im November 2025 einen Pipe-Operator, mit dem sich Funktionsaufrufe verketten lassen, und eine eigene Erweiterung, die Webadressen nach den Standards RFC 3986 und WHATWG zerlegt. Für 8.6 sind unter anderem eine Funktion clamp() und die partielle Funktionsanwendung beschlossen, bei der ein Programm einer Funktion nur einen Teil ihrer Argumente vorab übergibt.

Zu den zehn Gründern der PHP Foundation gehörten JetBrains, Automattic, Symfony, Laravel und Zend. Nach ihrem Transparenzbericht schreibt die Stiftung heute rund 42 Prozent aller Änderungen am PHP-Kern. Gemessen an dieser Rolle ist das Budget klein. 2025 bekam die Stiftung Spenden von umgerechnet rund 650.000 Euro und gab rund 698.000 Euro aus, das Minus nennt sie eine bewusste Entscheidung. Die deutsche Sovereign Tech Agency förderte PHP zusätzlich mit 205.000 Euro für 2023 und 2024 sowie 223.680 Euro für 2025 und 2026.

Aus dem ersten Förderprogramm bezahlte die Agentur 2024 auch eine Sicherheitsprüfung des Kerns durch Quarkslab. Die Prüfer fanden 27 Probleme, 17 davon mit Folgen für die Sicherheit, darunter drei schwere. Das PHP-Team hat alle behoben.

In das Unternehmen hinter dem Framework Laravel investierte Accel 2024 in einer einzigen Finanzierungsrunde umgerechnet rund 50,7 Millionen Euro. Die Summe entspricht den Spenden an die PHP Foundation aus 78 Jahren, gerechnet mit dem Aufkommen von 2025.

Wie dünn die Personaldecke bei vielen Basisprojekten des Netzes ist, haben wir für 23 Open-Source-Projekte, auf denen das Internet aufbaut, ausgewertet: Elf hängen an ein oder zwei Personen. PHP steht mit elf bezahlten Entwicklern besser da, im Verhältnis zur Reichweite bleibt die Mannschaft klein.

Auf Packagist, dem zentralen Verzeichnis für PHP-Bibliotheken, liegen 475.087 Pakete, die zusammen mehr als 207 Milliarden Mal installiert wurden. In der Umfrage „State of PHP 2025“ von JetBrains planten 58 Prozent der befragten Entwickler für das kommende Jahr keinen Wechsel zu einer anderen Sprache.

In der Entwicklerumfrage von Stack Overflow gaben 2026 noch 17,7 Prozent der Befragten an, PHP zu nutzen, knapp weniger als bei Rust.

Sicherer als ihr Ruf aus den Nullerjahren ist die Sprache allemal, und gepflegt wird sie besser als je zuvor. Unsicher wird PHP dort, wo Server jahrelang auf alten Versionen laufen und Updates auf den nächsten Wartungstermin warten. Gegen beides hilft kein neuer Operator, nur ein Betreiber, der das Update in Stunden statt in Wochen einspielt.

Glossar: 19 wichtige Fachbegriffe zu PHP und PHP2Shell

CGI

CGI (Common Gateway Interface) heißt die älteste Schnittstelle, über die ein Webserver ein externes Programm startet und dessen Ausgabe an den Browser schickt. Lerdorfs erste PHP-Werkzeuge waren solche CGI-Programme in C. In der Variante php-cgi steckten 2012 und 2024 zwei schwere Lücken.

CVE

CVE (Common Vulnerabilities and Exposures) ist das weltweite Nummernsystem für bekannte Sicherheitslücken. Jede Lücke bekommt eine Kennung aus Jahr und laufender Nummer, etwa CVE-2026-109618. Die US-Datenbank NVD ergänzt die Einträge um Bewertung, Fehlerklasse und betroffene Versionen.

CVSS

CVSS (Common Vulnerability Scoring System) bewertet die Schwere einer Sicherheitslücke auf einer Skala von 0 bis 10. In Version 4.0 fließen unter anderem ein, ob Angreifer eine Anmeldung brauchen und wie aufwendig ein Angriff ist. Beide PHP2Shell-Lücken erhielten 9,2 Punkte.

Exploit

Exploit heißt ein Programm oder eine Abfolge von Anfragen, die eine Sicherheitslücke gezielt ausnutzt. Aus einem veröffentlichten Patch lässt sich ablesen, wo der Fehler saß, und daraus ein Exploit bauen. KI-Modelle verkürzen diesen Schritt nach Versuchen von Wiz und Anthropic auf Stunden.

FrankenPHP

FrankenPHP ist ein moderner Anwendungsserver für PHP auf Basis des Webservers Caddy, entwickelt von Kévin Dunglas. Seit Mai 2025 unterstützt die PHP Foundation das Projekt offiziell, der Code liegt in der PHP-Organisation auf GitHub. Laut PHP-Team ist auch FrankenPHP von PHP2Shell betroffen.

Interpreter

Interpreter nennt man das Programm, das PHP-Code beim Aufruf einer Seite liest und ausführt. Bei PHP ist das ein in C geschriebener Kern, die Zend Engine, mit zahlreichen Erweiterungen. Eine Lücke im Interpreter betrifft jede Anwendung, die darauf läuft, unabhängig von WordPress oder Shop.

JIT-Compiler

JIT-Compiler (Just in time) übersetzen Code während der Ausführung in Maschinencode des Prozessors. PHP bekam einen solchen Compiler mit Version 8.0 im November 2020. Rechenlastige Programme laufen damit deutlich schneller, typische Webseiten laut php.net so schnell wie unter PHP 7.4.

mod_php

mod_php heißt das Modul, mit dem der Webserver Apache PHP direkt in seinen eigenen Prozessen ausführt. Die Anbindung ist alt, einfach einzurichten und bei Shared Hosting verbreitet. Für PHP2Shell schätzt das PHP-Team das Risiko bei mod_php am höchsten ein.

Multipart-Formulardaten

Multipart-Formulardaten (multipart/form-data) nennt man das Format, in dem Browser Formulare mit Datei-Uploads an den Server senden. PHP zerlegt diese Daten vor jedem Skript selbst. Genau dort lösen Angreifer bei PHP2Shell den Speicherengpass aus, an dem der erste Fehler ansetzt.

NVD

NVD (National Vulnerability Database) heißt die Schwachstellendatenbank des US-Standardisierungsinstituts NIST. Die Datenbank ordnet jeder CVE betroffene Produkte und Versionen zu. Für den PHP-Interpreter verzeichnet die NVD mindestens 747 Einträge, mit dem Höchstwert von 120 im Jahr 2016.

Packagist

Packagist ist das zentrale Verzeichnis für PHP-Bibliotheken, aus dem der Paketmanager Composer seine Pakete lädt. Am 21. Oktober 2026 lagen dort 475.087 Pakete mit zusammen mehr als 207 Milliarden Installationen. Moderne PHP-Projekte binden darüber fast alle fremden Bausteine ein.

PHP Foundation

PHP Foundation heißt die gemeinnützige Organisation, die seit November 2021 Entwickler für die Arbeit am PHP-Kern bezahlt. Gegründet haben die Stiftung zehn Unternehmen, darunter JetBrains und Automattic. 2025 bezahlte die Foundation elf Entwickler, die rund 42 Prozent der Änderungen am Kern schrieben.

PHP-FPM

PHP-FPM (FastCGI Process Manager) verwaltet eine Gruppe von PHP-Prozessen, an die ein Webserver wie nginx oder Apache die Anfragen weiterreicht. Die Prozesse bearbeiten nacheinander viele Anfragen. Diese Wiederverwendung der Prozesse macht den zweiten PHP2Shell-Fehler möglich, bei dem Reste einer Anfrage in die nächste geraten.

register_globals

register_globals hieß eine Einstellung, mit der PHP jeden Parameter aus Adresszeile, Formular und Cookie automatisch als Variable anlegte. Angreifer konnten so Variablen eines Skripts von außen setzen. Ab PHP 4.2.0 war die Funktion standardmäßig aus, mit PHP 5.4 verschwand sie 2012 ganz.

Sovereign Tech Agency

Sovereign Tech Agency heißt die Agentur des Bundes, die freie Software für die digitale Infrastruktur fördert. Die Agentur gab PHP 205.000 Euro für 2023 und 2024 sowie 223.680 Euro für 2025 und 2026. Aus dem ersten Programm stammte auch die Sicherheitsprüfung des PHP-Kerns durch Quarkslab.

Speicherfehler

Speicherfehler entstehen, wenn ein Programm über die Grenzen eines Speicherbereichs hinaus liest oder schreibt oder bereits freigegebenen Speicher weiterbenutzt. In Sprachen wie C prüft der Compiler das nicht von selbst. Knapp die Hälfte der PHP-Lücken mit Fehlerklasse gehört nach unserer Auswertung dazu.

Use-after-free

Use-after-free nennt man einen Speicherfehler, bei dem ein Programm auf Speicher zugreift, der bereits freigegeben ist. Liegen dort inzwischen fremde oder vom Angreifer gesteuerte Daten, lässt sich der Programmablauf manipulieren. CVE-2026-109619 ist ein solcher Fehler zwischen zwei Anfragen.

Web Application Firewall

Web Application Firewall (WAF) heißt ein Filter vor einer Webanwendung, der verdächtige Anfragen nach Regeln abweist. Cloudflare verteilte am 21. Oktober Regeln gegen PHP2Shell, Imperva meldete Schutz für seine Kunden. Cloudflare-Technikchef Dane Knecht nannte diese Regeln selbst eine Notlösung, die kein Update ersetzt.

Zend Engine

Zend Engine heißt der Kern des PHP-Interpreters, benannt nach den Vornamen von Zeev Suraski und Andi Gutmans. Die erste Fassung erschien Mitte 1999 und steckte ab PHP 4 im Interpreter. PHP 5 brachte 2004 die Zend Engine II mit einem neuen Objektmodell.

FAQ: Wie sicher ist PHP nach PHP2Shell noch?

Quellen