Am 17. Oktober 2026 geht auf einem Server, den niemand legitimerweise ansprechen sollte, eine Anfrage ein. Sie folgt dem Muster eines Exploits für PHP2Shell, eine Schwachstelle, die zu diesem Zeitpunkt noch unter Verschluss ist. Der Sensor, auf dem die Anfrage landet, gehört zu MadPot, dem Ködernetz von Amazon Threat Intelligence, und er protokolliert, was hereinkommt. Vier Tage später, am 21. Oktober, wird die Lücke öffentlich. In einem Beitrag im AWS Security Blog beschreibt CJ Moses, wie die Bedrohungsanalyse des Konzerns den Versuch bereits vorher in ihrer Telemetrie fand – und was daraus für Offenlegungsfristen folgt.
Für die Patch-Planung verschiebt das die Frage: nicht nur, wann eine Lücke bekannt wird, sondern wann sie zuerst ausprobiert wurde. Bei PHP2Shell liegen dazwischen fast eine Woche. Was beobachtet wurde, wo der Befund endet und was daraus für den Betrieb folgt.
MadPot: Köder ohne echten Zweck
Warum ein einzelner Request eine Meldung wert ist, zeigt der Aufbau von MadPot: Musterwohnungen, in denen niemand wohnt. Kein Licht, kein Name an der Klingel, aber Bewegungsmelder und Kameras in jedem Raum. Wer dort eindringt, ist kein Handwerker und kein Besucher; es gibt nichts zu besuchen. Ein Honeypot hat keinen echten Zweck. Seine Aufgabe ist, angesprochen zu werden.
Niemand hat legitimen Grund, mit so einem System zu sprechen. Die Fehlalarmquote ist deshalb niedrig, und jede Interaktion liefert Daten. Amazon Threat Intelligence sammelt Anfragen, Nutzlasten, Quelladressen und Zeitverläufe. Aus vielen Beobachtungen entsteht ein Bild davon, welche Schwachstellen gerade ausprobiert werden – oft bevor ein Patch öffentlich ist. MadPot verhindert keinen Angriff. Es beschreibt ihn.
Der Fund vom 17. Oktober und die Sperrfrist
Der Exploit-Versuch datiert auf den 17. Oktober 2026, vier Tage vor der öffentlichen Offenlegung von CVE-2026-109618 und CVE-2026-109619, zusammen PHP2Shell genannt. Die Anfrage kam von einer IP-Adresse aus einem kommerziellen Anonymisierungsnetzwerk. Solche Dienste leiten Verbindungen über Zwischenstationen und verschleiern die Herkunft. Das ist legal und für Privacy-Produkte sinnvoll, in der Praxis aber auch ein Werkzeug für Angreifer.
Die Schwachstelle war zu diesem Zeitpunkt noch unter Embargo, also unter einer Sperrfrist mit begrenztem Kreis Eingeweihter. Ein Angriff auf einen Honeypot aus einem anonymisierten Netz spricht in dieser Phase eher für einen Akteur als für einen Forscher, der versehentlich scannt. Wie der Akteur an die Exploit-Informationen kam, bleibt offen – eigene Analyse, Weitergabe aus dem Umfeld der Meldestelle oder ein Zwischenhändler sind denkbar. Amazon benennt diese Lücke und spekuliert nicht.
Was am Offenlegungstag zwischen 02:00 und 08:00 UTC geschah
Die Sperrfrist sollte am 21. Oktober 2026 um 14:00 UTC fallen. Schon gegen 02:00 UTC fand Amazon Threat Intelligence erste Proof-of-Concept-Exploits. Ein Proof of Concept ist funktionierender Testcode, der zeigt, dass eine Schwachstelle ausnutzbar ist. Aus dieser Vorlage wurden in den Stunden danach Werkzeuge für den breiten Einsatz. Zwischen 02:00 und 08:00 UTC gingen weitere Ausnutzungsversuche gegen die MadPot-Sensoren ein, erneut aus anonymisierter Infrastruktur.
Die Nutzlasten unterschieden sich, ebenso die gewählten Verschleierungsdienste. Das spricht nicht für eine einzelne Kampagne, sondern für mehrere Akteure, die dieselbe Lücke unabhängig ausprobiert haben. Ob ein Versuch auf einem echten, ungepatchten System erfolgreich gewesen wäre, ist offen; die technische Analyse dauert an. Ein Honeypot verhält sich anders als ein gewachsener Produktivserver, und nicht jede Payload zündet auf jeder Version.
Die Sperrfrist schützt nicht vor Ausnutzung
Eine Sperrfrist schützt Verteidiger nur so lange, bis jemand anders denselben Fehler findet. Koordinierte Offenlegung bleibt das richtige Modell; daran lässt CJ Moses keinen Zweifel. Sie ist aber eine Vereinbarung über Informationen, keine Garantie über Angriffe. Der Tag, an dem ein CVE veröffentlicht wird, ist nicht automatisch der Tag, an dem die Ausnutzung beginnt. Bei PHP2Shell lagen dazwischen mindestens vier Tage.
Für die Planung zählt deshalb ein anderer Zeitraum: nicht „Offenlegung bis Patch“, sondern „erste Ausnutzung bis Patch“. Wer nur den ersten misst, unterschätzt die eigene Exposition. Ein Patch drei Tage nach der Offenlegung kann in diesem Fall bereits mehrere Tage zu spät kommen. Das ändert die Priorität von Change-Prozessen und die Frage, wie lange ein System ohne Not exponiert bleibt.
Was daraus für Patchmanagement und Erkennung folgt
Erstens: anonymisierte Infrastruktur ist ein schwaches, aber brauchbares Signal. Nicht jede Anfrage aus einem VPN ist bösartig, und kein Filter sollte allein darauf reagieren. Als Zusatzindiz neben auffälligen Request-Mustern gegen PHP-Endpunkte taugt es. Zweitens: Erkennung sollte sich an Verhalten orientieren, nicht nur an Signaturen. Wer erst nach dem CVE nach Indikatoren sucht, hat die Tage davor schon vergeben.
Drittens: CVE-Feeds allein sind kein guter Auslöser für Dringlichkeit. Wer Telemetrie, Honeypots oder Threat-Intelligence-Feeds hat, sieht Ausnutzung oft vor der Veröffentlichung. Kleine Köder im eigenen Netz sind dafür billig: ein exponierter Endpunkt, ein attraktiv aussehender Login, ein Server ohne echte Daten. Viertens: miss die Patch-Latenz pro Systemklasse, nicht im Durchschnitt. Ein Durchschnitt verdeckt die Systeme, die dauerhaft hinten liegen.
Wie belastbar ist der Befund?
Der Befund bleibt begrenzt. Es ist eine einzelne Beobachtung in Telemetrie, kein Beweis für einen erfolgreichen Einbruch. Amazon schreibt selbst, dass unklar ist, ob die Versuche auf realen Systemen funktioniert hätten. Eine Zuordnung zu einer bestimmten Gruppe gibt es nicht, nur die Beobachtung anonymisierter Herkunft. Der Beitrag kommt aus dem Haus, das die eigene Plattform als Erkennungsinstrument zeigt; das gehört bei der Lektüre dazu.
Die Chronologie bleibt aussagekräftig: Versuch am 17. Oktober, erste PoCs in der Nacht zum 21., weitere Versuche im Stundenrhythmus, dann mit Fall der Sperrfrist um 14:00 UTC und dem Patch zusätzliche Proofs of Concept innerhalb von Stunden. Laut Amazon wird PHP2Shell inzwischen breit in freier Wildbahn ausgenutzt. Der Zeitraum, in dem du ungepatcht erreichbar bist, beginnt also früher als im Kalender markiert.
Der Bericht belegt dabei vor allem, was Amazons eigene Sensorik gesehen hat. Er beweist weder, dass jede beobachtete Anfrage auf einem realen System erfolgreich gewesen wäre, noch erklärt er, woher der Akteur die Schwachstellenkenntnis hatte. MadPot ist ein absichtlich exponiertes Ködernetz und damit eine starke Frühwarnquelle, aber kein repräsentativer Querschnitt aller PHP-Installationen. Für Verteidiger bleibt die praktische Folgerung trotzdem klar: Internet-erreichbare Dienste sollten über Inventar, vorgeschaltete Regeln, Protokollierung und einen getesteten Notfallprozess verfügen, bevor eine Sicherheitsmeldung erscheint. Dann beginnt die Reaktion mit einem bekannten Systembestand statt mit der Suche danach, wo die betroffene Software überhaupt läuft.
Quelle: aws.amazon.com
