Der Patch ist draußen, die Schlagzeilen sind geschrieben, und viele hakten das Thema am Abend des 21. Oktober ab. Das ist der Moment, in dem solche Vorfälle gefährlich werden. Bei PHP2Shell liegt die eigentliche Welle nicht hinter uns, sondern vor uns: Das BSI rechnet in Version 1.1 seiner Warnung mit kurzfristiger Ausnutzung verwundbarer Systeme und breiten Massenscans, und die Fachpresse titelt mit „Mass Exploitation Looms".
Dieser Beitrag beschreibt, was in den kommenden drei Tagen erfahrungsgemäß passiert – und woran Sie merken, dass es Sie betrifft.
Warum die Welle jetzt erst kommt
Zwischen einer veröffentlichten Lücke und dem flächendeckenden Angriff liegen üblicherweise drei Schritte, und sie brauchen unterschiedlich lange.
Zuerst wird gesucht, nicht angegriffen. Automatische Suchläufe fragen harmlose Dinge ab: Welche Software läuft dort, welche Version, reagiert der Server auf bestimmte Anfragen eigentümlich. Das erzeugt Treffer in Protokollen, aber keinen Schaden. Diese Phase läuft bereits.
Dann wird sortiert. Aus Millionen erreichbarer Server wird eine Liste derer, bei denen es sich lohnt. Das kostet Rechenzeit, nicht Geschick.
Zuletzt wird zugegriffen – und zwar zuerst dort, wo etwas zu holen ist: Shops mit Kundendaten, Server mit erkennbarer Unternehmensbindung, Systeme mit Zugang zu anderen Systemen.
Die Sicherheitsfirma Sansec rechnete damit, dass die Massenausnutzung binnen fünfzehn Minuten nach Veröffentlichung des Patches beginnt. Das betrifft die erste Stufe. Die dritte erreicht einzelne Unternehmen Stunden bis Tage später.
Was in den nächsten drei Tagen zu erwarten ist
Tag eins: Scans in der Breite
Ihre Webserver-Protokolle füllen sich mit ungewöhnlichen Anfragen. Sicherheitsforscher nennen als typisches Muster ungewöhnliche multipart-Anfragen, gefolgt von Fehlern wegen überschrittener Speichergrenze – genau der Zustand, über den die Lücke funktioniert.
Das allein ist kein Alarm. Es heißt: Sie wurden gefunden, wie Millionen andere auch. Interessant wird es, wenn aus den Anfragen ein Muster wird, das sich wiederholt und verfeinert.
Tag zwei: Webshells
Wer Erfolg hatte, legt sich einen zweiten Weg an – meist eine kleine Datei im Verzeichnis der Website, über die sich später bequem Befehle absetzen lassen. Das ist der Punkt, an dem der Patch zu spät kommt: Die Lücke ist zu, der Zugang bleibt.
Deshalb ist die Frage nach neuen oder veränderten Dateien im Website-Verzeichnis in diesen Tagen die wichtigste, die Sie stellen können. Wie man das prüft, steht in PHP2Shell-Angriff erkennen.
Tag drei und danach: die zweite Welle
Die ersten Zugriffe sind opportunistisch – automatisiert, breit, ohne Interesse an einem bestimmten Unternehmen. Was danach kommt, ist gezielter: Jemand sieht sich an, was er da eigentlich übernommen hat, und entscheidet, ob es sich lohnt.
Zwischen dem ersten Zugriff und dem sichtbaren Schaden liegen bei solchen Fällen regelmäßig Wochen. Wer jetzt nachsieht, hat diesen Vorsprung. Wer wartet, bis etwas auffällt, hat ihn verspielt.
Wofür der Webserver dann benutzt wird
Ein übernommener Webserver wird selten um seiner selbst willen angegriffen. Er ist ein Mittel. Die üblichen Verwendungen, nach Häufigkeit:
- Versand von Nachrichten über Ihre Domain. Das trifft Ihre Zustellbarkeit und Ihren Ruf, oft bevor Sie es merken.
- Weiterverkauf des Zugangs. Es gibt einen Markt für übernommene Server; der Käufer bringt sein eigenes Vorhaben mit.
- Sprungbrett nach innen. Wenn der Webserver Verbindungen ins Firmennetz hat oder dort dieselben Zugangsdaten gelten, ist das der teuerste Fall – dazu Vom Webserver ins Firmennetz.
- Unauffällige Manipulation Ihrer Seite. Eingeschleuste Weiterleitungen oder versteckte Verweise, die nur Suchmaschinen sehen. Bemerkt wird das oft erst, wenn die Platzierungen fallen.
Wer in dieser Welle zuerst drankommt
Nicht alle werden gleichzeitig angegriffen. Die Reihenfolge ergibt sich daraus, was sich mit wenig Aufwand finden lässt.
Zuerst: Server, die ihre Version nennen. Wer `X-Powered-By: PHP/8.2.31` ausliefert, steht auf jeder Liste, die in den letzten Tagen erstellt wurde – ohne dass jemand etwas ausprobieren musste. Das ist der Grund, warum diese Angabe abgeschaltet gehört, auch wenn sie für sich genommen keine Lücke ist.
Dann: große, bekannte Systeme. Für WordPress, Magento und Joomla gibt es fertige Werkzeuge, die den Angriff automatisiert durchprobieren. Eine Eigenentwicklung erfordert Handarbeit und ist deshalb später dran – was kein Schutz ist, nur ein Aufschub.
Dann: alles, was lange nicht angefasst wurde. Testsysteme unter Unteradressen, die alte Projektseite, das Archiv von 2019. Solche Systeme sind doppelt attraktiv: Sie sind meist verwundbar, und es fällt niemandem auf, wenn sich dort etwas ändert.
Zuletzt: alles andere. Nicht weil es sicher wäre, sondern weil Angreifer wirtschaftlich denken.
Daraus folgt die unangenehmste Erkenntnis für viele Unternehmen: Das System, das zuerst übernommen wird, ist selten die gepflegte Hauptwebsite. Es ist das vergessene daneben.
Was Sie in diesen drei Tagen konkret tun sollten
Heute: Patchstand aller Systeme bestätigen lassen – schriftlich, mit vollständiger Versionsnummer. Nicht nur für die Hauptwebsite, sondern auch für Test-, Alt- und Nebensysteme.
Morgen: Die Protokolle des Zeitraums ab dem 20. Oktober durchsehen und den Dateibestand des Website-Verzeichnisses mit der letzten bekannt guten Sicherung vergleichen.
Übermorgen: Administratorkonten in allen Systemen durchzählen, zeitgesteuerte Aufgaben prüfen, und – falls nicht ohnehin geschehen – die Zugangsdaten erneuern, die auf dem Webserver lesbar waren.
Durchgehend: Ausgehende Verbindungen beobachten. Ein Webserver, der plötzlich von sich aus Verbindungen nach außen aufbaut, ist auffällig.
Was Sie in diesen Tagen nicht tun sollten
Nicht beruhigen lassen durch Stille. Ein erfolgreicher Zugriff macht kein Geräusch. Die meisten Unternehmen, die wir nach einem Vorfall sehen, hatten wochenlang keinen Hinweis.
Nicht aufräumen, bevor geprüft wurde. Wer eine verdächtige Datei löscht, vernichtet das Beweismittel und warnt den Angreifer.
Nicht auf die Meldung in der Presse warten. Dass über eine Angriffswelle berichtet wird, heißt, dass sie ihren Höhepunkt überschritten hat.
Checkliste: erste Schritte
- Patchstand aller PHP-Systeme schriftlich bestätigen lassen, mit vollständiger Versionsnummer
- Webserver-Protokolle ab dem 20. Oktober auf ungewöhnliche multipart-Anfragen mit Speicherfehlern durchsehen
- Dateibestand des Website-Verzeichnisses gegen die letzte Sicherung vergleichen
- Administratorkonten in CMS, Shop und Webmail durchzählen
- Zeitgesteuerte Aufgaben auf Neuzugänge prüfen
- Auf dem Webserver lesbare Zugangsdaten erneuern
- Ausgehende Verbindungen die nächsten Tage beobachten
- Zuständigkeit für das Wochenende klären
Wie DAVINCI unterstützt
Wir sehen uns die Protokolle des kritischen Zeitraums an, vergleichen den Dateibestand gegen eine saubere Sicherung und sagen Ihnen schriftlich, was belegt ist und was offen bleibt – als Quick-Check für 49 Euro oder als vollständige Aufarbeitung über Incident Response. Einen ersten Eindruck liefert der kostenlose PHP-Sicherheitscheck. Akut erreichen Sie uns rund um die Uhr über IT-Notfall.
Häufige Fragen
Wir sind gepatcht. Können wir das Thema abhaken?
Den Teil mit der Lücke ja. Offen bleibt, ob zwischen dem 20. Oktober und Ihrem Update jemand hereingekommen ist. Diese Frage beantwortet nur ein Blick in die Protokolle – und sie wird mit jedem Tag schwerer zu beantworten, weil Protokolle überschrieben werden.
Wie lange sollten wir besonders aufmerksam sein?
Die akute Phase dauert erfahrungsgemäß eine bis zwei Wochen. Die Nachwirkungen – jemand sieht sich einen übernommenen Server in Ruhe an – können Monate dauern. Wer nach zwei Wochen nichts gefunden hat und seitdem ordentlich protokolliert, kann die Aufmerksamkeit zurückfahren.
Unsere Website ist klein und uninteressant. Betrifft uns die Welle?
Die erste Stufe trifft jeden, der erreichbar ist – dort wird nicht nach Interessantem gesucht, sondern nach Verwundbarem. Ob jemand die zweite Stufe auf Sie anwendet, hängt davon ab, was er vorfindet. Ein funktionierender Mailversand über Ihre Domain ist für viele schon Grund genug.
Woran erkennen wir, dass die Scans uns betreffen?
Gar nicht zuverlässig, wenn niemand hinsieht. Deshalb ist die Durchsicht der Protokolle in diesen Tagen die lohnendste halbe Stunde, die Sie investieren können.
Sollten wir die Website vorsichtshalber offline nehmen?
Nur wenn Sie nicht patchen können. Ist die aktuelle Fassung eingespielt, bringt Abschalten nichts mehr – dann zählt die Durchsicht. Falls Sie bereits abgeschaltet haben: Website vom Netz genommen.
Verwandte Themen: Wer hier weiterdenkt, liest bei PHP-Sicherheitslücke, Remote Code Execution und Webserver kompromittiert weiter.
Im Text erwähnt
Quellen
- PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit, Cybersicherheitswarnung 2026-297981-1032, Version 1.1 (21.10.2026) · BSIamtlich
- PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws · SecurityWeek
- PHP2Shell: AI uncovers critical RCE vulnerabilities · Wiz Research
- Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities · Huntress
