StyleSmuggler: Magento-Notfallpatch ist da — was Händler und Entwickler jetzt tun müssen

Update vom 8. September 2026: Adobe hat reagiert. Seit dem 7. September, 22:20 Uhr, gibt es einen Notfall-Patch — Bulletin APSB26-146, die Lücke heißt jetzt offiziell CVE-2026-75650 und trägt den Schweregrad 10.0 von 10. Spielen Sie ihn ein, heute noch. Alles Weitere dazu steht im Abschnitt zur Lage und in den häufigen Fragen; der Rest dieses Beitrags gilt unverändert, denn die Angriffe laufen weiter und ein Patch heilt keinen Shop, in dem bereits jemand sitzt.

Am Freitagabend, dem 4. September 2026, um 22:20 Uhr UTC wurde der erste Magento-Shop übernommen. Der Betreiber wusste zu diesem Zeitpunkt nichts davon. Sein Shop lief auf einer aktuellen Version, alle Sicherheitspatches vom Juli und August waren eingespielt, die Prüfung meldete keine fehlenden Updates. Genau das ist der Punkt, an dem dieser Vorfall sich von allem unterscheidet, was Sie in den letzten Jahren über Magento-Sicherheit gelesen haben.

Die Lücke heißt StyleSmuggler. Sie erlaubt es Angreifern, ohne jede Anmeldung eigenen Programmcode auf Ihrem Server auszuführen. Betroffen sind alle aktuellen Ausgaben von Magento Open Source und Adobe Commerce, einschließlich der brandneuen 2.4.9. Drei Tage lang gab es dagegen kein Update — angegriffen wurde trotzdem, in der Breite. Seit dem Abend des 7. September liegt ein Notfall-Patch vor, und die Bewertung mit dem Höchstwert 10.0 sagt alles über den Ernst der Lage.

Dieser Beitrag ist zweigeteilt. Der erste Teil erklärt in Klartext, was passiert ist, wie Sie erkennen, ob es Sie getroffen hat, und was heute zu tun ist. Der zweite Teil richtet sich an Entwicklerinnen, Entwickler und Serveradministratoren und liefert Signaturen, Prüfkommandos und die Sperren, die tatsächlich greifen. Wir haben die Angriffswelle vom 5. September in einem von uns betreuten Shop selbst mitgeschnitten — was dort passiert ist, steht weiter unten.

Was seit dem 4. September passiert

Entdeckt und benannt hat die Lücke das niederländische Sicherheitsunternehmen Sansec, das sich seit Jahren ausschließlich mit Angriffen auf E-Commerce-Systeme beschäftigt. Veröffentlicht wurde der Befund am 5. September 2026 — ausdrücklich vor Abschluss der eigenen Analyse, weil zu diesem Zeitpunkt bereits Shops übernommen wurden. Die vollständige technische Aufarbeitung finden Sie in der Originalveröffentlichung von Sansec zur StyleSmuggler-Schwachstelle.

Die Zahlen dazu sind unangenehm nüchtern. Ein spezialisierter Dienstleister meldete innerhalb der ersten Tage zwei bestätigt übernommene und einen angegriffenen, aber nicht durchbrochenen Shop — bei insgesamt 26 unterschiedlichen Absenderadressen, überwiegend gekaperte Privatanschlüsse in den USA. Das ist kein gezielter Angriff auf einzelne Marken. Das ist ein Netz, das flächendeckend ausgeworfen wird, und Ihr Shop ist darin genau ein Eintrag in einer Liste.

Der Zeitplan zeigt, wie eng es war. Der letzte reguläre Sicherheitshinweis von Adobe stammt vom 11. August. Wer damals alles eingespielt hat, war bis zum 4. September in dem Glauben, sauber zu sein. Drei Tage lang stand danach jeder erreichbare Shop ohne Update im Netz.

Der Notfall-Patch: APSB26-146

Am 7. September um 22:20 Uhr hat Adobe geliefert — außer der Reihe, mit der höchsten Dringlichkeitsstufe. Was Sie darüber wissen sollten:

• Die Schwachstelle heißt jetzt CVE-2026-75650 und ist mit 10.0 von 10 Punkten bewertet. Höher geht die Skala nicht.
• Es ist ein Hotfix, kein vollständiges Release. Sie laden ihn aus dem Magento-Repository und wenden ihn als Patch an — Ihre Version bleibt, wo sie ist.
• Abgedeckt sind 2.4.4 bis 2.4.9, bei Adobe Commerce, Magento Open Source und der B2B-Erweiterung. Auch ältere Installationen bekommen also eine Lösung.
• Nach dem Einspielen lässt sich am Patch-Status prüfen, ob er wirklich sitzt. Tun Sie das — ein stillschweigend fehlgeschlagener Patch ist schlimmer als keiner, weil er in Sicherheit wiegt.

Ein Punkt, den Adobe ausdrücklich betont und der leicht überlesen wird: Der Hersteller empfiehlt, nach dem Patch den Verschlüsselungsschlüssel des Shops zu wechseln — und mit ihm sämtliche Zugangsdaten, die dieser Schlüssel geschützt hat: Administratorkonten, Schnittstellen-Token, Zugänge zu Zahlungsdienstleistern, Datenbank, Server-Schlüssel, Erweiterungs-Zugänge. Und zwar nicht erst bei nachgewiesenem Einbruch. Der Grund ist unbequem: Ein Angreifer, der in den vergangenen Tagen Code ausführen konnte, hatte Zugriff auf alles, was der Schlüssel schützt. Ein Wechsel danach macht nicht ungeschehen, was bereits gelesen wurde — er verhindert nur, dass es weiter benutzt wird.

Wie weit Sie diese Empfehlung umsetzen, ist eine Abwägung: Bei einem Shop mit belegtem Einbruch führt daran nichts vorbei. Bei einem nachweislich abgewehrten Angriff ohne Kartendaten im System kann man anders entscheiden — aber bewusst, und nicht aus Bequemlichkeit.

Warum „alles gepatcht“ diesmal nichts bedeutet

Hier liegt die eigentliche Nachricht, und sie ist unbequem. Der erste bestätigte Fall lief auf Magento Open Source 2.4.6-p15, mit den isolierten Patches vom Juli und August 2026, und der Befehl zur Patch-Prüfung meldete eine leere Liste. Vollständig aktuell also. Übernommen wurde der Shop trotzdem, und zwar genauso mühelos wie eine seit zwei Jahren vergessene Installation.

Patchstand und Sicherheit sind nicht dasselbe. Das ist der Satz, den Händlerinnen und Händler aus diesem Vorfall mitnehmen sollten. Updates schließen bekannte Lücken. Sie tun nichts gegen die, die noch niemand kennt — und genau in diesem Fenster bewegen sich die Leute, die es auf Ihren Shop abgesehen haben. Was in dieser Situation trägt, sind Maßnahmen, die unabhängig von der konkreten Schwachstelle wirken: gesperrte Upload-Wege, restriktive Verzeichnisrechte, ein Wächter über den Systemdateien, eine Ausgangssperre für den Webserver.

Das klingt nach Aufwand, den man sich spart, solange nichts passiert. In der Woche vom 4. September hat sich dieser Aufwand für einen unserer Shops in barer Münze ausgezahlt. Dazu gleich mehr.

Wie der Angriff funktioniert — zwei Stufen, kein Klick

StyleSmuggler ist keine plumpe Einbruchsmethode, sondern nutzt zwei ganz normale Funktionen von Magento nacheinander aus. Das macht ihn so schwer zu entdecken: An keiner Stelle passiert etwas, das für sich genommen verdächtig aussieht.

Stufe eins: Der Code wird eingeschmuggelt

Der Angreifer schickt eine Anfrage an die GraphQL-Schnittstelle Ihres Shops — die Adresse, über die moderne Frontends, Apps und Schnittstellen mit Magento sprechen. In dieser Anfrage stecken präparierte Parameter mit dem Namen styles. Über diesen Umweg gelangt PHP-Code in eine Datei, die Magento im normalen Betrieb selbst schreibt, zum Beispiel in einen Fehlerbericht unter var/report/. Der Name der Lücke kommt genau daher: Der Schadcode reist als Formatierungsangabe getarnt mit.

Stufe zwei: Magento führt ihn selbst aus

Der interessante Teil. Der eingeschmuggelte Code liegt jetzt zwar auf der Platte, tut aber nichts. Also bringt der Angreifer Magento dazu, eine ganz gewöhnliche Systemmail zu erzeugen: die Erinnerung an eine fehlgeschlagene Zahlungstransaktion. Beim Zusammenbauen dieser Mail liest Magento die vergiftete Datei ein — und führt den Code dabei aus. Niemand muss diese Mail öffnen. Es genügt, dass der Server sie erzeugt.

Was danach passiert, ist Routine für die Angreifer: Ein Zwischenlader probiert der Reihe nach sechs verschiedene PHP-Funktionen durch, um einen Prozess zu starten. Klappt eine davon, lädt er ein in Rust geschriebenes Programm von einem fremden Server nach und startet es. Dieses Programm tarnt sich in der Prozessliste als [kworker/u:8:0], also als harmloser Bestandteil des Linux-Kerns, legt sich in ein unauffälliges Verzeichnis im Heimatordner und trägt sich in die Zeitsteuerung ein, damit es einen Neustart übersteht. Anschließend liest es unter anderem die Sitzungsdaten Ihrer Kundschaft aus dem Zwischenspeicher.

Ab diesem Moment ist es kein Shop-Problem mehr, sondern ein Serverproblem: Kundendaten, Bestellungen, Zugangsdaten des Backends, Datenbankinhalte — und die Möglichkeit, Ihren Bezahlvorgang mit einem Kartendaten-Abgreifer zu versehen. Eine deutschsprachige Einordnung mit denselben Befunden hat Günter Born in seinem IT-Blog zusammengetragen.

Das Warnsignal liegt vermutlich schon in Ihrem Postfach

Und jetzt kommt der Teil, den Sie wirklich brauchen, weil er nichts kostet und keine Technikkenntnisse verlangt.

Weil Stufe zwei ausgerechnet die Zahlungsfehler-Mail als Zündschnur benutzt, erzeugt jeder Ausnutzungsversuch genau diese Benachrichtigungen. Massenhaft. Eine ungewöhnliche Häufung von Nachrichten mit dem Betreff „Erinnerung Transaktion fehlgeschlagen“ ist deshalb kein Schönheitsfehler Ihres Shops — sie ist der sichtbarste Hinweis darauf, dass gerade jemand an Ihrer Tür rüttelt.

Typisch sind dabei drei Merkmale, an denen Sie es ohne Serverzugang erkennen: Die Mails kommen in dichter Folge über mehrere Stunden. Sie enthalten weder einen Kundennamen noch Artikel. Und der Betrag steht auf null. Wenn Sie so etwas in den letzten Tagen gesehen und als Softwarefehler abgetan haben, holen Sie die Mails bitte aus dem Papierkorb zurück und sehen Sie sich die Uhrzeiten an.

Zwei Dinge sollten Sie dabei nicht tun. Erstens: die Benachrichtigungen abschalten, weil sie stören. Sie schalten damit Ihre einzige kostenlose Alarmanlage ab. Richten Sie stattdessen ein eigenes Postfach dafür ein, das nicht im Tagesgeschäft mitgelesen wird. Zweitens: davon ausgehen, dass ein leeres Postfach Entwarnung bedeutet. Es heißt nur, dass niemand es bei Ihnen versucht hat — oder dass die Mails woanders landen.

Aus der Praxis: ein Angriff, der ins Leere lief

Am Samstag, dem 5. September, meldete sich der Betreiber eines von uns betreuten Magento-Shops mit rund 140 dieser Mails im Postfach, eingegangen zwischen 07:00 und 11:26 Uhr. Alle ohne Kunde, ohne Artikel, über 0,00 Euro. Seine eigene Vermutung — jemand versuche, als Gast zu bestellen — war halb richtig und in der Konsequenz deutlich harmloser als das, was wir dann in den Protokollen fanden.

In den Fehlerprotokollen standen 138 abgelehnte Transaktionen, die letzte um 11:26:03 Uhr. Das passte auf die Sekunde zur letzten Mail. Daneben 184 abgewiesene Versuche eines Gast-Bezahlvorgangs, der in diesem Shop überhaupt nicht freigeschaltet ist. Die Zugriffe kamen von rund 20 verschleierten US-Anschlüssen, alle mit derselben maschinellen Kennung im Browserfeld. Und in den Anfragen steckten exakt die Parameter, die Sansec einen Tag zuvor als Signatur veröffentlicht hatte.

Der Angriff ist an vier voneinander unabhängigen Stellen gescheitert, und keine davon war ein Patch:

• Der erste Upload-Weg über die Kundenadressen-Funktion lief gegen eine Sperre, die seit April vor der Anwendung sitzt: abgewiesen mit Fehlercode 403.
• Der zweite Weg über die Produkt-Zusatzoptionen scheiterte an den Verzeichnisrechten — das Zielverzeichnis ist nicht beschreibbar.
• Der Aufruf der Hintertür, deren Dateiname übrigens identisch war mit dem aus einer Angriffswelle im April, lief ins Leere: Die Datei lag nie auf der Platte.
• Die eigentliche Ausführungskette scheiterte an der aktuellen Version samt der isolierten Patches von Juli und August.

Ein Nachsatz, der uns selbst nachdenklich gemacht hat: Bei der anschließenden Durchsuchung fanden wir 762 Schaddateien, die seit April in einem Zwischenspeicher-Verzeichnis lagen — eine Ebene oberhalb des Bereichs, den unser eigener Wächter durchsucht hat. Sie waren von außen nicht erreichbar und nie ausgeführt worden. Trotzdem: Sie lagen dort monatelang, und wir haben sie nicht gesehen. Der Prüfbereich ist inzwischen erweitert, die Dateien sind beweissicher archiviert und entfernt. Wer eigene Prüfroutinen betreibt, sollte an dieser Stelle einmal nachrechnen, wo sein Suchbereich endet und wo das Dateisystem weitergeht.

Was Sie als Händlerin oder Händler heute tun sollten

E-News für ambitionierte Entwickler - lesen Sie sich fit 🎬 Wie kann Renderforest mit seinen AI-Tools im E-Commerce ein nützlicher Helfer sein? 🛒

In dieser Reihenfolge, weil die Reihenfolge einen Unterschied macht.

Erstens: nachsehen, ob es Sie schon getroffen hat. Eine Lücke zu schließen ist sinnlos, wenn jemand längst drin ist — die Hintertür bleibt, auch wenn der Weg dorthin zugemauert wird. Diese Prüfung gehört auf den Server, nicht ins Backend, und sie sollte heute stattfinden. Wenn Sie dabei Unterstützung brauchen: Wir haben das Vorgehen bei einer Bereinigung in einem eigenen Beitrag über das Befreien eines Magento-Shops von Schadsoftware beschrieben.

Zweitens: den Patch einspielen. Seit dem 7. September gibt es ihn — als Hotfix, nicht als Versionssprung, für alle Ausgaben ab 2.4.4. Das ist seit gestern die wichtigste Einzelmaßnahme, und sie gehört heute erledigt, nicht nächste Woche. Lassen Sie sich danach den Patch-Status zeigen, statt darauf zu vertrauen, dass es geklappt hat.

Drittens: den Angriffsweg trotzdem dichtmachen. Ein Patch schützt vor dieser Lücke, nicht vor der nächsten. Wenn Ihr Shop GraphQL nach außen anbietet, ohne es zu brauchen, schalten Sie es ab — prüfen Sie vorher an den Zugriffsprotokollen, ob wirklich niemand es nutzt. Dazu kommen Sperrregeln im Webserver und zwei Einstellungen in der PHP-Konfiguration, die Angriffe dieser Bauart generell ins Leere laufen lassen. Die Einzelheiten stehen im nächsten Abschnitt.

Viertens: Zugangsdaten wechseln. Backend-Konten, Datenbank, Verschlüsselungsschlüssel, Schnittstellen-Token, Zugänge zu Zahlungsdienstleistern. Adobe empfiehlt das inzwischen ausdrücklich für alle betroffenen Shops, nicht erst bei nachgewiesenem Einbruch — die Begründung steht weiter oben. Ein Angreifer, der Sitzungsdaten mitgelesen hat, braucht Ihr Passwort ohnehin nicht mehr. Wichtig dabei: Wechseln Sie die Zugänge an der Quelle, also beim Zahlungsdienstleister und beim Hoster selbst, nicht nur im Shop.

Fünftens: an die Meldefristen denken. Sind personenbezogene Daten abgeflossen, läuft eine Frist von 72 Stunden für die Meldung an die zuständige Datenschutzaufsicht. Das Bundesamt für Sicherheit in der Informationstechnik erklärt auf seiner Seite zum Melden eines IT-Sicherheitsvorfalls, welche Wege Unternehmen dafür offenstehen. Wichtig: Ein abgewehrter Angriff ohne Datenzugriff ist kein meldepflichtiger Vorfall. Ein erfolgreicher ist es.

Sechstens: die Alarmanlage anlassen. Siehe oben — ein eigenes Postfach für die Zahlungsfehler-Mails, aber kein Abschalten.

Sie haben etwas gefunden — und jetzt?

Dieser Fall verdient einen eigenen Absatz, weil er häufiger eintritt, als man denkt, und weil er meistens weniger schlimm ist, als er im ersten Moment aussieht.

Wenn Ihre Prüfung Schadcode in den Protokolldateien oder Fehlerberichten zutage fördert, heißt das: Die erste Stufe ist durchgekommen. Es heißt nicht, dass Ihr Shop übernommen wurde. Beides sind getrennte Ereignisse, und genau diese Trennung ist der Grund, warum eine erste Einschätzung so oft danebengeht.

In dem Shop, über den wir hier berichten, lag der Code in 23 Einträgen auf der Platte — ausgeführt wurde er nie. Drei Dinge standen dem im Weg, und die sollten Sie bei sich ebenfalls prüfen, bevor Sie den Notfallplan auslösen:

• Die Verfallszeit. Der eingeschleuste Code trug ein Zeitfenster von rund drei Minuten. Wer ihn Tage später findet, findet etwas Totes.
• Das Kennwort. Der Code verlangt einen bestimmten Wert in der Anfrage, den nur der Angreifer kennt. Ohne ihn passiert nichts.
• Das Dateiformat. Steckt der Code als Textbaustein in einer sonst intakten Berichtsdatei, wird er beim normalen Betrieb nicht als Programm behandelt.

Entscheidend für die Frage „übernommen oder nicht“ sind deshalb nicht die Funde in den Logs, sondern die Spuren der zweiten Stufe: ein fremder Prozess, ein Eintrag in der Zeitsteuerung, eine unbekannte Datei im Zwischenspeicher, eine ausgehende Verbindung. Fehlen die, wurde der Code abgelegt, aber nie gestartet. Was Sie dann trotzdem tun sollten: die belasteten Einträge beweissicher sichern und entfernen — und den Weg schließen, über den sie hereinkamen.

Für Entwickler und Administratoren: prüfen, sperren, härten

Ab hier wird es technisch. Alle Angaben stammen aus der Veröffentlichung von Sansec und aus unserer eigenen Auswertung; prüfen Sie sie gegen den aktuellen Stand, die Lage bewegt sich täglich.

Erkennung: Läuft bei Ihnen schon etwas?

Vier Spuren hinterlässt das Implantat zuverlässig. Suchen Sie nach Prozessen, deren Name in eckigen Klammern steht und die trotzdem nicht dem Systemnutzer gehören — der Tarnname lautet kworker, beobachtet wurden auch fc-cache und chronyd. Sehen Sie in der Zeitsteuerung des Webserver-Nutzers nach Einträgen, die dort nichts zu suchen haben; dokumentiert ist ein zweimal stündlicher Aufruf. Prüfen Sie den Heimatordner auf ein verstecktes Verzeichnis namens .gvfsd sowie den Zwischenspeicher auf Dateien nach dem Muster .kw_ mit Zufallsanhang. Und durchsuchen Sie var/report/ sowie var/log/ nach der Zeichenfolge X_TRACE_ und nach PHP-Eröffnungszeichen — dort liegt die vergiftete Datei aus Stufe eins.

E-Commerce News - Tipps & Tricks 🔒 How-to: Magento von Malware befreien und in Zukunft schützen 🛡️

Ein Blick ins Zugriffsprotokoll rundet das Bild ab: Zählen Sie Anfragen, deren Abfragezeichenkette styles[, generatorClass oder with_resolved enthält. Wer dort auf mehr als null kommt, wurde zumindest angetastet. Vergessen Sie die rotierten Archive nicht — im tagesaktuellen Protokoll steht nur, was heute passiert ist.

Der zweite Einstiegsweg wird gern übersehen. Neben GraphQL wurde ein weiterer Pfad beobachtet: POST /paypal/transparent/response/ mit einem PHP-Eröffnungszeichen direkt in der Abfragezeichenkette. Auch darüber landet Code in einer Datei, die Magento selbst schreibt. Wer nur /graphql sperrt, lässt diesen Weg offen.

Warum Ihr Malware-Scanner das vermutlich nicht meldet

Diese Erfahrung haben wir selbst gemacht, und sie ist der unangenehmste Teil dieses Vorfalls. Unsere eigene Überwachung lief zum Zeitpunkt des Angriffs, alle fünfzehn Minuten, mit einem gepflegten Regelwerk — und hat nichts gemeldet.

Der Grund: Sie suchte nach Dateinamen. Nach *.php im Medienverzeichnis, nach Webshell-typischen Mustern, nach Archivdateien am falschen Ort. Die Magento-Fehlerberichte heißen aber schlicht nach ihrer Prüfsumme, ohne jede Endung — und fallen damit durch jedes dieser Muster hindurch. Der Code lag offen da und war formal unsichtbar.

Prüfen Sie Ihre eigene Überwachung auf genau diese Frage: Sucht sie nach Namen oder nach Inhalt? Und deckt ihr Suchbereich wirklich alles ab? Bei uns kam noch ein zweiter Befund dazu: ein Zwischenspeicher-Verzeichnis eine Ebene oberhalb des festgelegten Startpunkts, in dem seit Monaten unbemerkt Schaddateien lagen. Beides ist inzwischen geschlossen — die Prüfung läuft jetzt inhaltlich über Fehlerberichte und Protokolle, bei großen Dateien jeweils über das Ende, wo frisch Geschriebenes steht.

Sperren im Webserver — mit einer wichtigen Einschränkung

Für nginx kursieren Regeln, die Anfragen mit den bekannten Mustern in der Abfragezeichenkette hart abweisen: Parameternamen mit styles[, die Bezeichner generatorClass und with_resolved, Magento-Vorlagenanweisungen in doppelt geschweiften Klammern sowie PHP-Eröffnungszeichen in Abfrage oder Browserkennung. Sinnvoll ist das, aber diese Regeln haben ein Loch, das Sie kennen müssen: Webserver sehen nur die Abfragezeichenkette in der Adresse. Verschiebt der Angreifer dieselben Parameter in den Anfragekörper eines POST-Aufrufs, laufen sie an jeder dieser Regeln vorbei. Sperren im Webserver sind eine Verzögerung, keine Lösung.

Die Sperre, die wirklich trägt

Wirksamer ist ein Riegel an der Stelle, an der der eingeschmuggelte Code tatsächlich landet. Die betroffenen Klassen gehören zu den Abhängigkeits-Scannern im Setup-Verzeichnis und haben im Webbetrieb schlicht nichts verloren — sie sind für die Kommandozeile gedacht. Eine Prüfung am Anfang der jeweiligen Methode, die die Ausführung abbricht, sobald PHP nicht über die Kommandozeile läuft, schließt den Weg unabhängig davon, wie die Parameter transportiert werden. Betroffen sind der Array-Scanner, der XML-Interceptor-Scanner und der Klassen-Scanner. Beachten Sie dabei zweierlei: Ein Eingriff in Herstellerdateien geht beim nächsten Composer-Lauf verloren, und er will vorher auf einem Abzug getestet werden. Vermerken Sie ihn, und prüfen Sie nach jedem Update nach.

Zwei PHP-Einstellungen, die den Angriff ins Leere laufen lassen

Diese beiden Punkte halten wir für den wirksamsten Rat in diesem ganzen Beitrag — und sie werden fast nirgends genannt. Sie wirken ohne Patch, ohne Abschalten von GraphQL und ohne Eingriff in den Programmcode. Wer eine App oder ein modernes Frontend betreibt, das GraphQL wirklich braucht, hat hier die einzige verbleibende Möglichkeit.

Erstens: disable_functions füllen. Die zweite Stufe des Angriffs besteht darin, ein Programm nachzuladen und zu starten. Der Schadcode fragt dafür der Reihe nach ab, welche Funktionen zum Starten eines Prozesses zur Verfügung stehen — und nimmt die erste, die er bekommt. In beiden von uns geprüften Installationen war diese Liste vollständig leer, das ist der Auslieferungszustand vieler Hoster. Eine gefüllte Liste (exec, passthru, shell_exec, system, proc_open, popen, pcntl_exec) beendet die Kette an dieser Stelle. Magento braucht diese Funktionen im Webbetrieb nicht; für die Kommandozeile bleibt die Einstellung außen vor.

Zweitens: short_open_tag abschalten. Der zweite Angriffsweg über die Zahlungsschnittstelle beginnt mit einem verkürzten PHP-Eröffnungszeichen. Steht diese Einstellung auf Off, ist dieser Vektor wirkungslos — der eingeschleuste Text bleibt Text. Auch hier: In beiden geprüften Installationen stand sie auf On.

Beides lässt sich in der Regel nicht selbst setzen, weil die zentrale PHP-Konfiguration dem Systembetreiber gehört. Es ist eine kurze Anfrage an den Hoster — und die vermutlich lohnendste, die Sie diese Woche stellen. Nennen Sie dabei ruhig den Grund, sonst landet das Ticket in der Warteschlange. Fragen Sie im selben Zug nach einer Ausgangssperre für den PHP-Prozess: Sie verhindert das Nachladen und wirkt damit auch gegen die nächste Lücke, die noch niemand kennt.

Weitere Härtung, die unabhängig von dieser Lücke wirkt

• Ausgangssperre für PHP-Prozesse. Stufe zwei muss ein Programm von außen nachladen. Ein Webserver, der von sich aus keine Verbindungen ins Internet aufbauen darf, bricht die Kette genau hier — auch bei der nächsten, noch unbekannten Lücke.
• Keine ausführbaren Dateien im Medienverzeichnis. PHP-Dateien unterhalb von pub/media sind immer ein Befund, nie ein Zustand.
• Uploadwege schließen, die Sie nicht brauchen. In unserem Fall waren es die Kundenadressen-Uploads und die Produkt-Zusatzoptionen — zwei von vier Bruchstellen.
• Dateiwächter über die Systemdateien. Prüfsummen der zentralen Einstiegsdateien, regelmäßig verglichen, mit Alarm bei Abweichung. Und danach nachrechnen, ob der Suchbereich wirklich alles abdeckt.
• Ratenbegrenzung für die GraphQL- und REST-Adressen. Kein Frontend der Welt schickt hundert Anfragen pro Sekunde aus einer einzelnen Quelle.

Wer sich unsicher ist, ob die eigene Installation diese Grundlagen mitbringt: Ein strukturierter Durchgang durch Konfiguration, Rechte und Protokolle gehört bei uns zur laufenden Wartung und zum Support; für Magento im Besonderen finden Sie unser Leistungsbild auf der Seite der Magento-Agentur in Hamburg. Wie ein sauberer Prüfdurchgang im Backend aussieht, haben wir außerdem für das Testen des Magento-Backends aufgeschrieben.

Fazit: Die Lücke ist das Ereignis, die Härtung ist die Antwort

Zero-Day-Lücken sind kein Betriebsunfall, sondern ein wiederkehrender Zustand. Es hat CosmicSting gegeben, es hat SessionReaper gegeben, jetzt gibt es StyleSmuggler — und irgendwann im nächsten Jahr kommt der nächste Name. Was sich zwischen diesen Ereignissen ändern lässt, ist nicht die Existenz der Lücken, sondern die Frage, wie weit ein Angreifer kommt, bevor ihn etwas stoppt.

Der Patch vom 7. September beendet diesen Fall, und Sie sollten ihn heute einspielen. Er beendet aber nicht das Muster: Zwischen dem ersten Angriff am 4. September und dem Update lagen drei Tage, in denen kein Update der Welt geholfen hätte. Genau diese Lücke im Kalender ist der Grund, warum Härtung kein Ersatz für Updates ist — und Updates keiner für Härtung.

In dem Shop, über den wir hier berichtet haben, waren es vier voneinander unabhängige Stellen — und die entscheidende Erkenntnis ist, dass keine davon ein Patch war. Es waren Entscheidungen, die im April getroffen wurden, als der Druck längst weg war und niemand mehr hingesehen hat. Genau dort entscheidet sich, wie ein Samstagvormittag im September ausgeht: als 140 lästige Mails oder als Meldung an die Datenschutzaufsicht. Wenn es doch einmal so weit kommt, führt die Übersicht des Bundesbeauftragten für den Datenschutz zur Meldung von Datenschutzverstößen durch das Verfahren.

Und der ehrlichste Satz zum Schluss: Wir haben in derselben Prüfung 762 Schaddateien gefunden, die seit April unbemerkt herumlagen, weil unser eigener Suchbereich eine Verzeichnisebene zu tief ansetzte. Abgewehrt heißt nicht fehlerfrei. Es heißt nur, dass genug Schichten übrig waren.

Wie ist die Lage bei Ihnen?

Haben Sie am 4., 5. oder 6. September eine auffällige Menge an Zahlungsfehler-Mails bekommen? Läuft Ihr Shop auf einer der betroffenen Versionen, und ist GraphQL bei Ihnen von außen erreichbar? Haben Sie eine Prüfung auf dem Server bereits laufen lassen — und wissen Sie, wo Ihr Suchbereich endet?

Wenn Sie bei einer dieser Fragen ins Grübeln kommen, warten Sie damit nicht bis nach dem Wochenende. Schreiben Sie uns über unser Kontaktformular, was Sie beobachtet haben; wir sehen uns Ihre Protokolle an und sagen Ihnen, ob das Routine ist oder ob es eilt. Für bestehende Wartungskunden läuft die Prüfung ohnehin — bei allen anderen ist es eine Stunde, die sich in dieser Woche besonders lohnt.