PHP2Shell: Ist Ihre Website betroffen?

Die Lage in Kürze: Was seit dem 17. Oktober geschehen ist

Ein Vorfall wie dieser lässt sich am besten einordnen, wenn man die Reihenfolge der Ereignisse kennt. Sie erklärt auch, warum viele Betreiber Stunden oder Tage nach der Veröffentlichung noch ungeschützt waren, obwohl der Hersteller sofort reagiert hat.

• 17. Oktober 2026: Amazon Web Services berichtet über erste Ausnutzungsversuche, vier Tage bevor die Lücken öffentlich bekannt werden. Angreifer kannten also offenbar bereits vor der Veröffentlichung einen Weg, die Schwachstellen auszulösen.
• 21. Oktober 2026: Das PHP-Projekt veröffentlicht Sicherheitsupdates für alle aktuell unterstützten Zweige. Die Kennungen CVE-2026-109618 und CVE-2026-109619 werden vergeben. Die US-Behörde CISA ruft Organisationen auf, sofort zu aktualisieren.
• 21. bis 23. Oktober 2026: Sicherheitsfirmen reproduzieren die Fehler unabhängig voneinander, melden mehrere Fälle aktiver Ausnutzung und ein breit gestreutes, ungezieltes Scannen des Internets. Öffentliche Beispielprogramme zirkulieren.
• 24. Oktober 2026: Die korrigierten Versionen liegen seit drei Tagen vor. Die Frage ist nicht mehr, ob eine Lösung existiert, sondern ob sie auf Ihrem Server schon angekommen ist. Zusätzlich nennt das CERT-EU eine dritte Kennung, CVE-2026-115560, zu der bislang keine Einzelheiten veröffentlicht sind.

Die CISA hat in ihrer Warnung vom 21. Oktober festgehalten, dass ihr zu diesem Zeitpunkt keine erfolgreiche Ausnutzung bekannt war. Seitdem haben Sicherheitsforscher weitere Beobachtungen veröffentlicht. Lesen Sie solche Aussagen immer mit ihrem Datum: Sie beschreiben den Wissensstand eines bestimmten Tages und sind keine Entwarnung.

Was hinter dem Namen PHP2Shell steckt

Der Name und seine Bedeutung

PHP2Shell ist kein offizieller Produktname, sondern ein Spitzname, den die Sicherheitsgemeinschaft für zwei zusammengehörige Schwachstellen in der Programmiersprache PHP gewählt hat. Der Name beschreibt das Ziel eines Angriffs: Aus einer gewöhnlichen PHP-Anfrage wird eine Shell, also eine Kommandozeile, über die jemand Befehle auf dem Server ausführen kann. Mit einer Shell steuert ein Angreifer den Server mit den Rechten des Webservers.

Beide Lücken erhielten von den Bewertungsstellen die Note 9,2 von 10 nach dem Bewertungssystem CVSS in der Version 4.0. Das ist die Kategorie „kritisch“. Vergleichbar hohe Werte vergeben die Fachleute nur für Fehler, die aus der Ferne, ohne Zugangsdaten und mit großer Wirkung ausnutzbar sind.

Zwei Schwachstellen, ein gemeinsames Muster

Die beiden Lücken haben unterschiedliche technische Ursachen, folgen aber demselben Grundgedanken. Mitten in einem Arbeitsschritt tritt ein schwerer Fehler auf, PHP bricht die Arbeit ab und lässt dabei halb fertige Daten zurück. Beim anschließenden Aufräumen behandelt PHP diese unfertigen Daten so, als wären sie in Ordnung. Lassen sich die Reste gezielt vorbereiten, bestimmt der Angreifer, was der Aufräumcode als Nächstes tut.

Man kann sich das wie eine Baustelle vorstellen, die mitten im Gießen einer Decke geräumt wird. Der Räumtrupp folgt dem Plan und räumt weg, was dort laut Plan stehen müsste. Steht dort etwas anderes, weil jemand die Baustelle präpariert hat, räumt der Trupp trotzdem nach Plan und richtet dabei Schaden an. Der Fehler liegt im Fundament, auf dem Ihre Anwendung läuft, und nicht in der Anwendung selbst.

CVE-2026-109618: Wenn der Arbeitsspeicher mitten im Vorgang ausgeht

Die erste Lücke betrifft den Moment, in dem PHP eine eingehende Anfrage vorbereitet. Schickt ein Besucher ein Formular ab, wandelt PHP die übermittelten Felder in eine Liste um, auf die Ihr Programmcode später zugreift. Dazu legt PHP für jedes Feld Einträge in einer internen Tabelle an. Jeder Eintrag braucht Speicher, und PHP darf pro Anfrage nur so viel Speicher verbrauchen, wie die Einstellung „memory_limit“ erlaubt.

Wird dieses Limit genau in dem Augenblick überschritten, in dem ein Eintrag halb angelegt ist, bricht PHP mit einem Fehler ab. Die Tabelle zählt den neuen Eintrag aber bereits mit, obwohl er nie vollständig befüllt wurde. Beim Aufräumen am Ende der Anfrage liest PHP auch diesen unfertigen Eintrag und deutet die zufälligen Bytes darin als gültigen Wert. Gelingt es einem Angreifer, vorher dafür zu sorgen, dass an dieser Stelle von ihm gewählte Bytes liegen, kann er den Aufräumvorgang dazu bringen, eine Funktion seiner Wahl aufzurufen. Die Sicherheitsfirma Datadog hat diesen Weg in einer Laborumgebung bis zum Aufruf eines Systembefehls nachvollzogen.

Wichtig für Ihre Einschätzung: Der Angreifer braucht dafür weder ein Benutzerkonto noch eine bestimmte Seite Ihrer Website. Jede PHP-Datei, die über das Netz erreichbar ist, öffnet den betroffenen Pfad, selbst eine Datei, die nur einen Satz ausgibt. Die Anfrage muss lediglich so groß und so aufgebaut sein, dass der Speicher an der richtigen Stelle ausgeht.

Das erklärt auch, warum Berichte von „Fehlern im Protokoll“ sprechen, die mit „Unknown on line 0“ enden. Diese Zeilenangabe bedeutet, dass PHP noch gar keine Ihrer Dateien ausgeführt hatte, als der Fehler eintrat. Auch deshalb fällt ein Angriff auf diesem Weg so leicht durch das Raster der üblichen Überwachung.

CVE-2026-109619: Wenn ein Rest der vorigen Anfrage überlebt

Die zweite Lücke hat mit der Lebensdauer von Arbeitsprozessen zu tun. Ein PHP-Prozess bearbeitet im Laufe seines Lebens sehr viele Anfragen nacheinander. Manche Zeiger, die der Prozess verwaltet, verweisen auf Speicher, der eigentlich nur zu einer einzigen Anfrage gehört. Gibt PHP diesen Speicher frei, ohne den Zeiger zu löschen, kann eine spätere Anfrage dem Zeiger in einen Bereich folgen, der bereits freigegeben ist. Fachleute nennen diese Fehlerklasse „Use-after-free“.

Laut der Sicherheitsmitteilung des PHP-Projekts tritt der veraltete Zustand auf zwei Wegen auf. Entweder unterbricht ein schwerer Fehler PHP beim Zurücksetzen seines Zustands, oder eine späte Diagnosemeldung erzeugt nach dem Aufräumen erneut Zustand. Bestätigt wurden zwei ausnutzbare Fälle. Der erste betrifft die Rückverfolgung bei schweren Fehlern und gilt nur für PHP 8.5. Der zweite betrifft die Verarbeitung von Datei-Uploads, bei der nach einem schweren Fehler Reste von Sitzungs- oder Dekodierdaten liegen bleiben können.

Der Upload-Fall ist für Betreiber besonders relevant, weil PHP die Funktion „session.upload_progress“ standardmäßig eingeschaltet hat. Sie verfolgt Datei-Uploads, noch bevor das Zielskript läuft, und arbeitet auch dann, wenn Ihre Anwendung nie eine Sitzung startet. Auf Servern, die PHP als Apache-Modul betreiben, wurde die Befehlsausführung bestätigt, bei PHP-FPM ebenfalls, dort allerdings nur, wenn die Anwendung nach dem Start eine passende Operation ausführt.

Zwei Einschränkungen helfen bei der Einordnung. Der Angreifer muss mit seinen Anfragen denselben Arbeitsprozess erreichen, und je mehr Prozesse parallel laufen, desto geringer ist die Trefferquote pro Versuch. Beseitigt wird die Lücke dadurch nicht. Bei einem Angriff, der Tausende Versuche startet, verlieren selbst große Prozesspools ihren Schutzeffekt.

Hintergrund: Warum Speicherfehler so gefährlich sind

Beide Lücken gehören zur Familie der Speicherfehler. Um zu verstehen, warum sie als kritisch gelten, lohnt ein kurzer Blick in den Maschinenraum der Programmierung. Programme speichern ihre Arbeitsdaten in Bereichen des Arbeitsspeichers und halten über Zeiger fest, wo welche Daten liegen. Solange Zeiger und Speicher zusammenpassen, läuft alles korrekt.

Gefährlich wird es, wenn beides auseinanderfällt. Zeigt ein Zeiger auf einen Bereich, der bereits freigegeben oder anderweitig belegt wurde, liest oder schreibt das Programm an einer Stelle, die ihm nicht mehr gehört. Dort kann inzwischen etwas anderes liegen, im ungünstigsten Fall Daten, die ein Angreifer eingeschleust hat. Das Programm vertraut dem Zeiger, ohne zu ahnen, dass er veraltet ist, und führt aus, was dort steht.

Solche Fehler sind schwer zu finden, weil sie nur unter bestimmten Bedingungen auftreten, etwa wenn der Speicher knapp wird oder zwei Anfragen in ungünstiger Reihenfolge eintreffen. Sie sind zugleich schwer zu beheben, weil sie oft tief in der Architektur eines Programms sitzen. Aus diesem Grund beschäftigen sie die Sicherheitsforschung seit Jahrzehnten und sind der Grund, warum sich neuere Sprachen ausdrücklich bemühen, solche Fehlerklassen von vornherein auszuschließen.

Für Betreiber ist wichtig, dass diese Fehler unterhalb ihrer Anwendung liegen. Kein noch so sorgfältig geschriebenes Plugin kann ausgleichen, was die Laufzeitumgebung falsch macht. Das ist keine Kritik an den Entwicklern von PHP, die den Fehler behoben haben, sondern eine Erinnerung daran, dass jede Software Fehler enthält und dass das Aktualisieren der Grundlage zu den wirksamsten Maßnahmen gehört.

Warum Login, Passwort und Plugin-Schutz nicht helfen

Viele Betreiber verlassen sich zu Recht auf mehrere Schutzebenen: starke Passwörter, Zwei-Faktor-Anmeldung, Sicherheits-Plugins, gesperrte Administrationsbereiche. Gegen PHP2Shell wirken diese Maßnahmen nicht, und der Grund liegt in der Reihenfolge der Abläufe.

Wenn eine Anfrage Ihren Server erreicht, übernimmt zuerst der Webserver, und danach beginnt PHP mit der Auswertung der übermittelten Daten. Erst wenn diese Auswertung abgeschlossen ist, führt PHP Ihren Programmcode aus, und erst dort prüft Ihr System, ob jemand angemeldet ist. Bei PHP2Shell geschieht der entscheidende Fehler bereits in der ersten Phase. Die Datadog-Forscher beschreiben es so, dass kein Code der Zielanwendung den Angriff beeinflussen oder abwehren kann, weder Anmeldung noch Filter.

Daraus folgt eine unbequeme, aber klare Konsequenz: Ein Sicherheits-Plugin, das als PHP-Code in Ihrer Anwendung läuft, kann diese Lücke nicht schließen. Schutz bieten nur Maßnahmen, die vor PHP greifen. Dazu zählen ein Reverse-Proxy oder eine Web-Application-Firewall, die verdächtige Anfragen verwirft, bevor sie PHP erreichen. Sie sind jedoch ein Zwischenschritt, den die Behörden ausdrücklich nur als Teilschutz bezeichnen. Vollständig behebt nur das Update die Ursache.

Welche PHP-Versionen betroffen sind

Die Reichweite dieser Lücken ist groß. Nach Angaben von Google Cloud sind alle PHP-Versionen von 5.4 bis einschließlich 8.5.11 betroffen. Das PHP-Projekt hat für die aktuell gepflegten Zweige korrigierte Stände veröffentlicht: 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Beide Schwachstellen werden mit denselben Versionsnummern behoben, und wer eine dieser Versionen oder eine neuere einsetzt, hat laut Hersteller und Behörden die Korrektur an Bord. Das gilt allerdings nur für Prozesse, die nach dem Einspielen neu gestartet wurden.

Was für PHP 8.1 und älter gilt

Die Zweige 8.1, 8.0, 7.4 und alles davor befinden sich außerhalb der regulären Pflege durch das PHP-Projekt. Dort erscheinen keine gewöhnlichen Korrekturversionen mehr. Nach Darstellung von Datadog hat das PHP-Sicherheitsteam für 7.4, 8.0 und 8.1 minimale Quellcode-Korrekturen bereitgestellt. Solche Korrekturen sind noch kein fertiges Paket: Distributionen und Hoster müssen sie prüfen, einbauen und verteilen, und das dauert erfahrungsgemäß länger als bei aktuellen Versionen.

Die CISA empfiehlt für diesen Fall eine deutliche Maßnahme. Wer nicht sofort aktualisieren kann oder weiterhin PHP 8.1 oder älter einsetzt, soll die betroffenen Systeme vom Netz nehmen, bis sie gepatcht oder umgestellt sind. Für einen Mittelständler bedeutet das konkret: Eine Kundenverwaltung auf PHP 7.4, die aus dem Internet erreichbar ist, gehört in dieser Woche auf die Prioritätenliste ganz nach oben.

Die Falle mit der Versionsnummer

Auf Servern mit Linux-Distributionen wie Debian oder Ubuntu gilt eine Besonderheit. Die Betreiber der Distributionen übernehmen Sicherheitskorrekturen häufig in ältere Programmversionen, ohne die sichtbare Versionsnummer zu erhöhen. Ein Server, der „PHP 8.2.7“ meldet, kann deshalb bereits korrigiert sein, obwohl die Nummer unter 8.2.35 liegt. Umgekehrt gilt nichts davon automatisch, und die sichtbare Nummer ist darum ein Indiz, aber kein Beweis.

Wer wissen möchte, welchen Stand der Server hinter der eigenen Website von außen meldet, findet im Basis-Scan für 99 € eine Auswertung der sichtbaren Hinweise, samt ehrlicher Kennzeichnung dessen, was sich nicht erkennen lässt.

Warum die Antwort selten ein schlichtes Ja oder Nein ist

Die Schlagzeilen legen nahe, dass jeder Betreiber nur nachsehen müsse. In der Praxis zerfällt die Frage in drei Zustände, und nur einer davon lässt sich ohne weiteres benennen.

Sicher betroffen ist ein Server, der nachweislich einen Stand unterhalb der Korrektur ausführt und nicht durch eine anderweitig eingearbeitete Korrektur geschützt ist. Wahrscheinlich geschützt ist ein Server, bei dem ein aktueller Stand erkennbar ist und der Betreiber bestätigt, dass alle Dienste seither neu gestartet wurden. Dazwischen liegt eine große Grauzone: Server, die ihre Version nicht verraten, Zwischenstationen, die Auskünfte verändern, und Projekte, bei denen mehrere Versionen nebeneinander laufen.

In dieser Grauzone landen erfahrungsgemäß gerade die kleinen und mittleren Betriebe, weil sie ihre Technik nicht selbst betreiben. Sie sind auf Auskünfte ihres Hosters oder ihrer Agentur angewiesen und können deren Qualität nicht einschätzen. Eine unabhängige Untersuchung von außen schließt diese Lücke nicht vollständig, sie liefert aber ein zweites, unabhängiges Indiz und deckt auf, wo Auskunft und Außenansicht auseinanderfallen. Wie eine solche Untersuchung abläuft und was sie leisten kann, erläutert der Beitrag PHP-Sicherheitslücke prüfen in fünf Minuten.

Genau für diese Unsicherheit ist der Basis-Scan für Ihre Adresse gedacht. Er liefert keine Vermutung, sondern einen datierten Bericht, der die Lage in Grün, Gelb, Rot oder „nicht feststellbar“ einordnet.

Warum ein eingespieltes Update allein noch keinen Schutz bedeutet

Zwischen dem Installieren einer neuen PHP-Version und dem Moment, in dem sie Anfragen aus dem Internet bedient, liegen Stationen, an denen eine Korrektur wirkungslos bleiben kann. Die Sicherheitsfirmen betonen, dass laufende Prozesse ihren alten Code im Arbeitsspeicher behalten, bis sie ersetzt werden.

Besonders tückisch ist das bei Servern, die monatelang ohne Neustart laufen. Die Datei auf der Platte ist neu, der Dienst im Speicher alt, und von außen ist der Unterschied nicht zu erkennen. Ähnlich verhält es sich bei Containern: Ein neues Abbild im Register ändert nichts, solange der alte Container weiterläuft. Und auch eine Wiederherstellung aus einer älteren Sicherung kann einen überholten Stand zurückbringen, wenn die Konfiguration mitgesichert wurde.

Hinzu kommen die Systeme am Rand, die in keiner Liste stehen: eine Testumgebung für Entwickler, ein altes Projekt auf einer Unterdomain, eine Wartungsseite. Angreifer unterscheiden nicht zwischen produktiv und Test, sie nehmen, was erreichbar ist. Ein Betrieb, der sein Hauptsystem sorgfältig gepflegt hat, kann über eine vergessene Nebenseite trotzdem verwundbar bleiben.

Für die Bewertung folgt daraus eine nüchterne Regel: Maßgeblich ist nicht, was installiert wurde, sondern was tatsächlich antwortet. Kennt man diesen Unterschied, stellt man dem Hoster andere Fragen und gibt sich mit anderen Antworten zufrieden.

Ein Bericht mit Datum und Uhrzeit, wie ihn der Basis-Scan erstellt, hilft dabei, den Zustand vor und nach einem Update festzuhalten und beim Hoster gezielt nachzufragen.

Welche Serverarten betroffen sind

PHP kann auf mehreren Wegen mit einem Webserver zusammenarbeiten. Das PHP-Projekt stellt klar, dass alle Installationen gefährdet sind, die Webanfragen bedienen, und zählt dazu Apache mit dem Modul mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Die höchste Gefahr sieht das Projekt bei mod_php, weil dort PHP direkt im Prozess des Webservers läuft.

Für Betreiber ist die Unterscheidung weniger wichtig als für Administratoren. Entscheidend ist die Frage, ob PHP eine Anfrage aus dem Internet verarbeitet. Das ist bei jeder PHP-Website der Fall. Eine Konsolenanwendung, die nur auf einem Rechner ohne Netzzugang läuft, ist dagegen nicht betroffen. Die Gefährdung entsteht also durch die Erreichbarkeit, nicht durch die Art der Anbindung.

Zusätzliche Wege, die gern vergessen werden

Viele Betriebe denken nur an ihre öffentliche Website. PHP steckt aber in weit mehr Systemen, als man auf den ersten Blick vermutet. Dazu gehören interne Wikis, Ticketsysteme, Kundenportale, Terminbuchungen, Newsletter-Werkzeuge, Dokumentenablagen und Wartungsseiten. Die CISA weist in ihrer Warnung ausdrücklich darauf hin, dass PHP oft Bestandteil anderer Software ist und seine Verbreitung deshalb nicht immer offen sichtbar ist.

Auch mitgelieferte Laufzeitumgebungen zählen. Ein Anwendungspaket, das seinen eigenen PHP-Interpreter mitbringt, wird durch ein Update des Server-PHP nicht berührt. Dasselbe gilt für Container, in denen eine eigene PHP-Version steckt.

Fünf typische Betriebe und was PHP2Shell für sie bedeutet

Die folgenden Beispiele sind typische Konstellationen und keine Berichte über einzelne Kunden. Sie zeigen, dass dieselbe Lücke je nach Hosting-Art ganz unterschiedliche Fragen aufwirft und unterschiedliche Beteiligte in die Pflicht nimmt.

Der Handwerksbetrieb mit WordPress beim Webhoster

Ein Dachdeckerbetrieb betreibt seine Firmenseite mit WordPress bei einem günstigen Hosting-Paket. Das Unternehmen hat nie bewusst eine PHP-Version gewählt, der Hoster stellt eine Voreinstellung bereit. Der Inhaber kann den Server weder neu starten noch Pakete installieren und ist auf die Mechanismen angewiesen, die der Anbieter seinen Kunden an die Hand gibt.

Die Lage ist typisch für den Mittelstand: Die Verantwortung für die Grundlage liegt beim Hoster, die Folgen eines Vorfalls aber beim Betrieb. Für den Dachdecker ist wichtig zu wissen, dass die Betroffenheit nicht an WordPress hängt, sondern an dem, was darunter läuft, und dass ein Hoster, der keine neue Version anbietet, sehr konkret gefragt werden muss.

Die Werbeagentur mit eigenem virtuellen Server

Eine kleine Agentur hat für ihre Kunden einen virtuellen Server gemietet, auf dem Apache mit mod_php läuft. Hier trägt die Agentur die volle Verantwortung für das Betriebssystem. Genau diese Konstellation nennt das PHP-Projekt als die riskanteste, weil jede Anfrage unmittelbar vom Webserver selbst verarbeitet wird.

Zusätzlich verschärft sich die Lage durch die Bündelung. Sind auf dem Server mehrere Kundenprojekte vereint, öffnet ein Einbruch den Zugang zu allen. Die Agentur haftet gegenüber jedem einzelnen Auftraggeber, und die Frage, ob der Server zwischen dem 17. Oktober und dem Zeitpunkt der Korrektur bereits angegriffen wurde, betrifft jedes Projekt.

Der Händler mit Container-Shop

Ein Händler betreibt seinen Shop als Container-Anwendung, die ein Dienstleister vor zwei Jahren eingerichtet hat. Der Container basiert auf einem fertigen Abbild mit eingebautem PHP, und Wartungsarbeiten am Server im Rechenzentrum berühren dieses Abbild nicht.

Das Beispiel zeigt eine Falle moderner Betriebsformen: Ein bloßes Update erreicht oft nur die Hülle. Ob der Inhalt gewechselt wurde, weiß in solchen Projekten meist nur der Dienstleister, der das Abbild gebaut hat, und der Händler muss darauf vertrauen, dass er es getan hat.

Das Steuerbüro mit dem alten Mandantenportal

Ein Steuerbüro nutzt seit Jahren ein selbst entwickeltes Portal, über das Mandanten Belege hochladen. Der damalige Programmierer ist nicht mehr erreichbar, die Anwendung läuft auf PHP 7.4, weil neuere Versionen sie überfordern. Das Portal verarbeitet vertrauliche Daten und ist zugleich der Fall, in dem das Risiko am höchsten ist.

Für diese Konstellation passt die Empfehlung der CISA ausdrücklich, ungepatchte Systeme auf PHP 8.1 oder älter vom Netz zu nehmen. Das Steuerbüro steht vor einem Zielkonflikt zwischen Verfügbarkeit für Mandanten und Schutz anvertrauter Daten, und diese Abwägung kann niemand außer der Kanzleiführung treffen. Fachliche Unterstützung hilft, die Lage nüchtern zu bewerten.

Das Architekturbüro mit statischer Seite

Ein Architekturbüro betreibt eine rein statische Website, die aus fertigen HTML-Dateien besteht und über ein Verteilnetz ausgeliefert wird. Auf dem Server läuft kein PHP, und damit fehlt die Angriffsfläche dieser beiden Lücken.

Ganz ohne Restrisiko ist auch dieser Fall nicht. Sobald ein Kontaktformular über ein Skript beim Hoster verarbeitet wird, steckt doch wieder PHP im Spiel, und die vermeintlich statische Seite ist nur so statisch wie ihre Formulare. Das Architekturbüro ist ein gutes Beispiel dafür, dass die Betroffenheit häufig an Details hängt, die dem Betreiber nicht bewusst sind.

Was ein erfolgreicher Angriff konkret bedeuten würde

Befehle auf einem Server auszuführen, ist für einen Angreifer die höchste Stufe an Zugriff, die über das Internet erreichbar ist. Die Folgen hängen davon ab, mit welchen Rechten der Webserver arbeitet und was auf dem Rechner liegt. Realistisch sind mehrere Szenarien, die oft kombiniert auftreten.

Datenabfluss

Alles, was die Anwendung lesen kann, kann auch der Angreifer lesen. Das umfasst Konfigurationsdateien mit Datenbank-Zugangsdaten, Kundendatensätze, Bestellungen, Kontaktanfragen und hochgeladene Dokumente. Besonders brisant sind Zugangsdaten, weil sie dem Angreifer auch dann noch nutzen, wenn die Lücke längst geschlossen ist. Nach einem Vorfall müssen deshalb Passwörter und Schlüssel getauscht werden, nicht nur das PHP.

Manipulation der Website

Angreifer verändern Seiten gern unauffällig. Sie schleusen Weiterleitungen auf fremde Angebote ein, blenden Werbelinks für Glücksspiel oder Medikamente aus, die nur Suchmaschinen sehen, oder verteilen Schadsoftware an Ihre Besucher. Solche Veränderungen bleiben oft wochenlang unbemerkt, weil die Seite für den Inhaber normal aussieht. Der Schaden zeigt sich später im Ranking, in Warnhinweisen des Browsers und in verärgerten Kunden.

Dauerhafter Zugang für spätere Zwecke

Ein erfahrener Angreifer nutzt den ersten Zugriff, um eine Hintertür zu installieren. Gemeint ist ein unauffälliger Eintrag oder eine Datei, über die er jederzeit zurückkehren kann, auch nachdem Sie PHP aktualisiert haben. Ein Update schließt die Tür, durch die er hereinkam, entfernt aber keine Hintertür, die er bereits angelegt hat. Deshalb gehört nach jedem Verdachtsfall eine Suche nach unbekannten Dateien dazu.

Ausgangspunkt für weitere Angriffe

Ein übernommener Server dient häufig als Sprungbrett. Von dort aus werden Spam-Mails versendet, andere Websites angegriffen oder Rechenleistung für fremde Zwecke abgezweigt. Für den Betreiber heißt das: Der Hoster sperrt unter Umständen das Konto, Mailserver landen auf Sperrlisten, und die Fehlersuche kostet Tage.

Ob bereits Spuren einer Manipulation vorliegen, lässt sich teilweise von außen erkennen. Der Scan für 99 € sucht deshalb auch nach typischen Hintertüren und nach Schadcode in ausgelieferten Seiten, bevor ein Schaden sichtbar wird.

Fünf Missverständnisse, die jetzt Schaden anrichten

In den ersten Tagen nach einer Veröffentlichung wie dieser verbreiten sich Halbwahrheiten schneller als Fakten. Fünf davon hört man in diesen Tagen besonders oft.

„Wir sind zu klein, uns greift niemand an.“

Die berichteten Angriffe richten sich nicht gegen bestimmte Firmen, sondern durchsuchen das Netz breit nach erreichbaren PHP-Servern. Eine Bäckerei mit Online-Bestellung ist für einen solchen Scan genauso sichtbar wie ein Konzern. Die Größe eines Betriebs schützt nicht, die Erreichbarkeit entscheidet.

„Wir haben doch eine Firewall.“

Die Firewall im Büro oder im Router schützt Ihr Firmennetz, nicht den Webserver beim Hoster. Gemeint ist für diesen Fall allenfalls eine Web-Application-Firewall vor dem Server, und auch die fängt nur einen Teil der Anfragen ab. Fragen Sie konkret nach, welche Art von Schutz vor Ihrer Website sitzt.

„Unser Hoster macht das automatisch.“

Mancher Hoster aktualisiert tatsächlich zügig, mancher stellt die Korrektur nur bereit und überlässt die Umstellung dem Kunden. Ob bei Ihnen die automatische oder die manuelle Variante gilt, steht in Ihrem Vertrag und im Kundenmenü. Annahmen helfen nicht weiter, entscheidend ist die belegte Auskunft.

„Wir haben die Seite nur kurz offline genommen, das reicht.“

Eine Abschaltung verhindert weitere Zugriffe, behebt aber nichts. Sobald die Seite wieder erreichbar ist, besteht dieselbe Lücke wie zuvor. Eine Abschaltung ist als Notbremse sinnvoll, die Korrektur muss trotzdem erfolgen, bevor die Seite wieder online geht.

„Wenn etwas passiert wäre, hätten wir es gemerkt.“

Das stimmt gerade bei dieser Schwachstelle nicht. Die Forscher stellen fest, dass ein erfolgreicher Angriff den Prozess nicht zum Absturz bringen muss und die Antwort sogar normal ausfallen kann. Ein ruhig laufender Server ist kein Beleg dafür, dass nichts geschah.

Wie Sie intern und gegenüber Kunden kommunizieren

Technische Fragen lassen sich lösen, Vertrauen ist schwerer zurückzugewinnen. Wer offen und früh informiert, behält in aller Regel die Sympathie seiner Kunden, auch wenn etwas schiefgegangen ist. Das gilt für Mitarbeiter ebenso wie für Geschäftspartner.

Intern genügt eine kurze, sachliche Nachricht: Was ist passiert, wer ist zuständig, bis wann ist mit einer Klärung zu rechnen und was sollen Mitarbeiter bis dahin vermeiden. Bitten Sie darum, Auffälligkeiten sofort zu melden, etwa unerwartete Weiterleitungen, Warnhinweise im Browser oder Beschwerden über merkwürdige E-Mails mit Ihrem Absender.

Gegenüber Kunden sagen Sie nur aus, was Sie wissen. Schreiben Sie nicht „alles ist sicher“, solange Sie das nicht belegen können. Schreiben Sie lieber, welche Maßnahme Sie ergriffen haben und was Sie noch prüfen. Wenn personenbezogene Daten betroffen sein könnten, stimmen Sie den Wortlaut mit Ihrem Datenschutzbeauftragten oder Ihrer Rechtsberatung ab, bevor Sie ihn versenden.

Was PHP2Shell über die heutige Bedrohungslage zeigt

Dieser Fall steht beispielhaft für eine Entwicklung, die Betreiber ernst nehmen sollten. Der zeitliche Abstand zwischen dem ersten bekannten Angriffsversuch und der öffentlichen Bekanntgabe betrug hier vier Tage, und innerhalb weniger Stunden nach der Veröffentlichung waren Beispielprogramme im Umlauf. Eine Planung, die erst mit der nächsten Meldung beginnt, kommt häufig zu spät.

Die Datadog-Forscher weisen zudem auf ein strukturelles Risiko hin. Die Korrektur verändert die Fehlerbehandlung bei Speichermangel, lässt aber das zugrunde liegende Muster bestehen, dass Zähler früher aktualisiert werden als der Speicher, den sie beschreiben. Sie erwarten deshalb, dass Fachleute weitere Fälle derselben Art finden, und rechnen damit, dass ältere PHP-Versionen Fälle behalten, die nie behoben werden. Für Betreiber folgt daraus ein nüchterner Schluss: Die Pflege der PHP-Version ist keine einmalige Aufgabe, sondern gehört dauerhaft in den Betrieb.

Wer den Wechsel auf eine unterstützte Version bisher aufgeschoben hat, weil die Anwendung dafür angepasst werden müsste, sollte diese Arbeit jetzt einplanen. Ein Projekt, das auf einer veralteten Version festhängt, wird mit jeder weiteren Veröffentlichung dieser Art riskanter und teurer.

Wer warnt und warum die Warnungen auch Deutschland betreffen

Die Warnung der CISA stammt von einer US-Behörde und richtet sich zunächst an amerikanische Organisationen. Für deutsche Betreiber ist sie dennoch relevant, weil PHP überall dieselbe Software ist und Angreifer keine Landesgrenzen kennen. Ein Server in Stuttgart enthält denselben Code wie einer in Texas, und er wird von denselben automatisierten Suchläufen erfasst.

Hierzulande gibt das Bundesamt für Sicherheit in der Informationstechnik regelmäßig Hinweise zu kritischen Schwachstellen heraus. Betreiber sollten diese Meldungen verfolgen und zusätzlich auf Mitteilungen ihres Hosters achten. Maßgeblich sind am Ende die Angaben des Herstellers und der Anbieter, bei denen die Software tatsächlich läuft.

Es lohnt sich auch, Warnungen gelassen, aber ernsthaft zu lesen. Behörden und Sicherheitsfirmen formulieren bewusst deutlich, damit Maßnahmen zügig beginnen. Ein Teil der Dringlichkeit ist ihrer Aufgabe geschuldet, ein anderer Teil spiegelt die tatsächliche Lage. Die Kunst besteht darin, beides auseinanderzuhalten, und dazu hilft ein nüchterner Blick auf die eigene Konstellation.

Wer besonders genau hinsehen sollte: Betroffenheit nach Branche

Technisch gilt die Lücke für alle gleich, die Folgen unterscheiden sich aber je nach Geschäftsmodell erheblich. Die folgende Einordnung hilft bei der Frage, wie dringend Ihre Prüfung ist und welches Risiko Sie am meisten treffen würde.

Betriebe mit sensiblen Daten

Steuerberater, Arztpraxen, Rechtsanwälte und Beratungsunternehmen verarbeiten Informationen, die einem besonderen Schutz unterliegen. Ein Zugriff auf den Server kann hier schnell eine meldepflichtige Datenpanne auslösen. Für diese Gruppe steht die Frage nach einem möglichen Datenabfluss an erster Stelle, noch vor der Frage nach der Version.

Händler mit Online-Shop

Ein Shop lebt von Verfügbarkeit und Vertrauen. Ein Angriff kann Zahlungsdaten gefährden, den Betrieb unterbrechen und über manipulierte Seiten die Kunden Ihrer Kunden treffen. Bei Shops kommt hinzu, dass eine Zahlungsabwicklung eigene Anforderungen an den Serverstand stellen kann.

Dienstleister und Agenturen

Wer mehrere Kundenprojekte betreut, trägt eine Verantwortung, die über die eigene Website hinausgeht. Ein einziger übernommener Server kann viele Kunden gleichzeitig betreffen. Hier zählt neben der Technik auch die Frage, wann und wie Kunden informiert werden.

Vereine, Verbände und kleine Organisationen

Diese Seiten werden häufig von ehrenamtlichen Helfern betreut. Aktualisierungen geraten leicht in Vergessenheit, und Zuständigkeiten wechseln mit dem Vorstand. Gerade deshalb ist dort die Frage nach einem Verantwortlichen mit Namen besonders wichtig.

Betriebe ohne eigene Webanwendung

Auch eine einfache Visitenkarten-Seite ist betroffen, sobald sie PHP ausführt. Der mögliche Schaden fällt kleiner aus, solange keine Kundendaten gespeichert werden. Der Server bleibt aber auch dann ein Sprungbrett, das für fremde Zwecke missbraucht werden kann.

Was in den nächsten Tagen zu erwarten ist

Aus dem Verlauf vergleichbarer Ereignisse lassen sich einige Entwicklungen ableiten, auf die sich Betreiber einstellen sollten. Das sind Einschätzungen und keine Gewissheiten.

Erstens wird das Scannen nach angreifbaren Servern vermutlich zunehmen, solange nennenswert viele Systeme ungepatcht erreichbar sind. Die Berichte der Sicherheitsfirmen beschreiben bereits ein breites, ungezieltes Abtasten des Netzes. Zweitens dürften Distributionen und Hoster in den kommenden Tagen weitere Pakete und Sicherheitsmitteilungen veröffentlichen, auch für ältere Zweige. Betreiber sollten diese Nachrichten aktiv verfolgen, statt auf eine Benachrichtigung zu warten.

Drittens ist damit zu rechnen, dass Forscher weitere Wege finden, die zugrunde liegenden Fehlermuster auszulösen. Datadog weist darauf hin, dass mehrere öffentliche Beispielprogramme bereits verschiedene Codepfade ansprechen. Eine Verteidigung, die auf einem einzelnen Erkennungsmerkmal beruht, ist deshalb brüchig, und tragfähiger ist die gepflegte Basis. Wer jetzt sauber aufräumt, ist für die nächste Meldung besser gerüstet.

Was Hoster jetzt leisten müssen und was Kunden erwarten dürfen

Eine Meldung wie diese stellt Hoster vor eine Mammutaufgabe. Tausende Server, viele Konfigurationen, alte und neue PHP-Zweige, dazu Kunden, die ihre Anwendungen nicht auf jeder Version betreiben können. Ein ordentlich geführter Betrieb hat für solche Fälle eingespielte Abläufe: Pakete prüfen, in Testumgebungen ausrollen, Server in sinnvoller Reihenfolge umstellen und die Kunden informieren.

Kunden dürfen von ihrem Anbieter erwarten, dass er zeitnah und konkret informiert. Dazu gehört, welche Versionen bereitgestellt werden, bis wann Umstellungen erfolgen und was der Kunde selbst tun muss, falls der Anbieter nur die Möglichkeit schafft. Ebenso dürfen sie erwarten, dass bei Zweigen ohne reguläre Pflege klar kommuniziert wird, ob und wann eine Lösung folgt.

Ob ein Anbieter diesen Anspruch erfüllt, zeigt sich in solchen Wochen deutlicher als in jeder Werbebroschüre. Wer in dieser Zeit schnell, offen und konkret antwortet, gewinnt Vertrauen, und wer ausweicht, liefert eine Information, die bei der nächsten Vertragsverlängerung hilft.

Wer die Antworten des Hosters einordnen möchte, kann sie mit dem Bericht des Basis-Scans abgleichen. Dem Bericht liegt eine Vorlage für die Rückfrage bei.

Was die Meldung für Entscheidungen in der Geschäftsleitung bedeutet

Technische Meldungen erreichen Geschäftsführer meist in gefilterter Form: als besorgte Nachricht eines Mitarbeiters oder als Rundmail des Hosters. Dahinter stehen unternehmerische, keine technischen Entscheidungen.

Die erste Entscheidung betrifft die Priorität. Ein Sicherheitsvorfall kostet im Zweifel mehr als die Maßnahmen, die ihn verhindern, und trotzdem konkurriert die Aufgabe mit dem Tagesgeschäft. Wird die Priorität früh festgelegt, entfallen später Diskussionen unter Zeitdruck. Die zweite Entscheidung gilt der Verantwortung. Es genügt nicht, dass sich „irgendwie“ jemand kümmert, es muss einen Namen geben, der die Antwort schuldet und dem die Antwort gegeben wird.

Die dritte Entscheidung betrifft die Kommunikation. Betriebe, die personenbezogene Daten verarbeiten, müssen damit rechnen, im Ernstfall binnen kurzer Frist Rede und Antwort zu stehen. Eine Geschäftsleitung, die den Sachstand kennt, spricht ruhiger und genauer als eine, die erst im Moment des Vorfalls beginnt zu recherchieren. Die vierte Entscheidung ist die über Unterstützung von außen: Wann holt man Fachleute dazu, und nach welchen Kriterien wählt man sie aus? Beides gehört in den ruhigen Moment und nicht in die Krise.

Aus dieser Sicht ist PHP2Shell weniger ein technisches Ereignis als ein Test für die Organisation. Betriebe, die in dieser Woche ruhig und geordnet reagieren, haben ihre Zuständigkeiten vorher geklärt. Betriebe, die hektisch werden, merken, dass sie es nicht getan haben.

Für Entscheider ist die Frage selten technisch. Sie lautet, was eine belastbare Auskunft kostet. Beim Basis-Scan ist die Antwort ein Festpreis von 99 €, ohne Stundenabrechnung.

Rechtliche Folgen: Datenschutz, Meldepflicht und Sorgfalt

Ein erfolgreicher Angriff auf eine Website, die personenbezogene Daten verarbeitet, ist rechtlich mehr als ein technisches Problem. Die Datenschutz-Grundverordnung verpflichtet Verantwortliche in Artikel 32 dazu, ein dem Risiko angemessenes Schutzniveau durch technische und organisatorische Maßnahmen sicherzustellen. Das Einspielen eines verfügbaren Sicherheitsupdates für eine bekannte, kritische Lücke gehört in der Praxis zu den Maßnahmen, die eine Aufsichtsbehörde als selbstverständlich erwartet.

Kommt es zu einer Verletzung des Schutzes personenbezogener Daten, verlangt Artikel 33 grundsätzlich eine Meldung an die zuständige Aufsichtsbehörde innerhalb von 72 Stunden, nachdem die Verletzung bekannt wurde, sofern ein Risiko für die betroffenen Personen besteht. Dieser Zeitraum beginnt mit Ihrer Kenntnis, nicht mit dem Zeitpunkt des Angriffs. Bei einem Verdacht gehen durch Abwarten wertvolle Stunden verloren.

Diese Hinweise ersetzen keine Rechtsberatung. Sie zeigen aber, warum sich eine dokumentierte Reaktion lohnt: Das Datum der Auskunft Ihres Hosters, die Versionsnummer nach dem Update und die Uhrzeit des Neustarts belegen im Zweifel, dass Sie zügig und sorgfältig gehandelt haben.

Wie Blackthorn Sie bei PHP2Shell unterstützt

Die Blackthorn GmbH hat ihren Hauptsitz in Stuttgart und untersucht Websites im gesamten Bundesgebiet aus der Ferne. Im Mittelpunkt steht der Basis-Scan zum Festpreis von 99 €. Er ermittelt, welche Hinweise auf die PHP-Version Ihre Website nach außen preisgibt, und vergleicht sie, sofern sie erkennbar ist, mit den korrigierten Ständen zu CVE-2026-109618 und CVE-2026-109619. Außerdem sucht er an typischen Stellen nach öffentlich erreichbaren Hintertüren und untersucht Ihre Seiten auf eingeschleusten Schadcode. Sie erhalten einen Bericht in verständlicher Sprache mit einer Gesamteinschätzung und Empfehlungen nach Dringlichkeit.

Zur Ehrlichkeit gehört, was ein solcher Scan nicht leistet. Er sieht Ihren Server von außen. Bleibt die Version verborgen, melden wir das als „nicht feststellbar“ und nicht als Entwarnung. Ob eine Korrektur über ein Update Ihrer Distribution eingearbeitet wurde, kann nur der Betreiber des Servers belegen. Was die Prüfung im Einzelnen untersucht und wie der Bericht aufgebaut ist, beschreiben wir ausführlich in den vier Bausteinen des Scans. Welche Schutzmaßnahmen über dieses eine Ereignis hinaus zählen, steht im Beitrag Website vor Hackerangriff schützen: Strategie statt Checkliste.

Bei einem konkreten Verdacht erreichen Sie uns über die Kontaktseite. Das Angebot im Überblick finden Sie auf der Seite Website-Sicherheit, die Konditionen in der Preisübersicht.

Häufige Fragen zu PHP2Shell

Quellen und weiterführende Informationen

Die Angaben in diesem Beitrag beruhen auf den folgenden öffentlichen Veröffentlichungen. Prüfen Sie bei Entscheidungen immer die aktuelle Fassung, weil sich die Lage kurz nach einer solchen Meldung laufend ändert.

• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Datadog Security Labs: PHP2Shell, Erkennung, Analyse und Behebung
• Google Cloud: Responding to core PHP vulnerabilities
• Fastly: Wie PHP2Shell erkannt wurde
• CERT-EU: Critical Vulnerabilities in PHP (Sicherheitshinweis 2026-018)
• Bundesamt für Sicherheit in der Informationstechnik: PHP, Kritische Schwachstellen bedrohen Webanwendungen weltweit
• PHP-Projekt: Ankündigungen und Sicherheitsmeldungen 2026