Eine Lücke mit 10 von 10 Punkten in Magento und Adobe Commerce: Was wirklich passiert ist

Zuerst die direkte Antwort: Am 4. September 2026 begannen Angreifer, eine ungepatchte Lücke in Magento Open Source und Adobe Commerce auszunutzen, geführt als CVE-2026-75650 mit einem Schweregrad von 10.0 – dem höchstmöglichen Wert. Die Lücke erlaubt das Ausführen von Befehlen auf dem Server des Shops ohne Anmeldung und ganz ohne Berechtigungen, und Adobe veröffentlichte die Korrektur am Abend des 7. September. Damit bleiben drei volle Tage, in denen Shops völlig ungeschützt offenlagen. Genau deshalb reicht es nicht, den Patch einzuspielen: Läuft Ihr Shop auf dieser Plattform, sollten Sie sicherheitshalber annehmen, dass Sie kompromittiert worden sein könnten, bevor es die Korrektur überhaupt gab. Die richtige Reaktion ist, nach Einbruchsspuren zu suchen und Ihre Verschlüsselungsschlüssel sowie sämtliche Zugangsdaten zu rotieren – nicht, das Update zu installieren und zur Tagesordnung überzugehen.

Wer genau betroffen ist

Die Liste ist ungewöhnlich lang, denn sie umfasst auch die neueste zum Zeitpunkt der Entdeckung verfügbare Version:

  • Magento Open Source und Adobe Commerce: Versionen 2.4.4 bis 2.4.9, einschließlich aller Patch-Updates bis August 2026.
  • Adobe Commerce B2B: Versionen 1.3.3 bis 1.5.3, bis zum Update vom August 2026.
  • Alles, was älter als 2.4.4 ist: ohnehin nicht mehr unterstützt und die gefährlichste Kategorie, weil der offizielle Hotfix sie nicht abdeckt.

Klar gesagt: Wer am 1. September ein vollständig aktualisiertes Magento betrieb, war angreifbar. Das ist nicht das bekannte Nachlässigkeitsszenario, vor dem wir sonst warnen – es ist ein echter Zero-Day, dem niemand zuvorkommen konnte.

Wie der Angriff ohne Passwort funktioniert

Der Angriff läuft in zwei Stufen ab und missbraucht die Fähigkeit von Magento, E-Mail-Vorlagen zu erstellen. In der ersten Stufe schickt der Angreifer eine präparierte Anfrage an einen Pfad für Zahlungsrückmeldungen, und der vollständige Inhalt dieser Anfrage wird in eine Fehlerberichtsdatei auf dem Server geschrieben. In der zweiten Stufe verweist eine Anfrage an den GraphQL-Endpunkt auf diese vergiftete Datei, und ihr Inhalt wird ausgeführt, während eine Erinnerungs-E-Mail zu einer fehlgeschlagenen Zahlung vorbereitet wird.

Was für Unternehmer zählt, ist nicht das technische Detail, sondern das, was es zeigt: Öffentliche Pfade, die völlig harmlos aussehen – die Rückmeldung eines Zahlungsanbieters, ein Abfrage-Endpunkt für die Storefront, eine automatische E-Mail –, ergeben zusammen einen vollständigen Weg in den Server. Schwere Sicherheitslücken sind selten eine einzige sperrangelweit offene Tür; viel häufiger sind sie eine Kette kleiner Türen, von denen jede für sich genommen völlig vernünftig wirkt.

Was die Angreifer nach dem Eindringen platzierten

Hier zeigt sich der Unterschied zwischen einem Vandalen und einer organisierten Operation. Die beobachteten Schadprogramme waren keine lauten Ransomware-Botschaften, sondern leise Werkzeuge, um sich dauerhaft festzusetzen:

  • Eine in Rust geschriebene Hintertür, die sich als einer der Kernel-Prozesse des Betriebssystems tarnt und deshalb niemandem auffällt, der eine Prozessliste nur überfliegt.
  • Getarnter Command-and-Control-Verkehr über den Port für die Zeitsynchronisation, sodass die Aktivität in den Netzwerkprotokollen wie routinemäßiges Uhrzeitstellen aussieht.
  • PHP-Webshells, abgelegt in den Cache-Ordnern für Produktbilder – Orte, die normalerweise niemand kontrolliert, weil sie voller temporärer Dateien sind.
  • Zusätzliche Fernzugriffswerkzeuge eines zweiten Angreifers mit davon unabhängigen Tools – die Lücke wurde also von mehr als einer Gruppe gleichzeitig ausgenutzt.

Ziel solcher Schadprogramme in einem bekannten Onlineshop ist es, lange zu bleiben und Bestell- und Zahlungsdaten mitzulesen, während sie durchlaufen – nicht, die Website lahmzulegen. Ein infizierter Shop arbeitet ganz normal weiter, und genau das ist das Beunruhigende.

Warum das Update allein nicht reicht

Weil ein Angreifer, der vor dem 7. September eingedrungen ist, jetzt eine Kopie Ihrer Verschlüsselungsschlüssel und gespeicherten Zugangsdaten besitzt. Der Patch schließt die Tür, durch die er gekommen ist; er wirft ihn nicht hinaus. Adobes eigene Empfehlung war in diesem Punkt eindeutig: die Korrektur einspielen und danach Verschlüsselungsschlüssel, Passwörter für das Admin-Panel, API-Tokens, Zugangsdaten des Zahlungsanbieters, Datenbankpasswörter und Serverzugangsschlüssel rotieren.

Der Patch stoppt die Blutung. Erst das Rotieren der Schlüssel bringt den ungebetenen Gast aus dem Haus.

Ein praktischer Aktionsplan für Shopbetreiber

  • Erstens – bestätigen Sie, dass die Korrektur tatsächlich installiert ist, und nicht nur, dass jemand das behauptet hat. Verlangen Sie von Ihrem Team einen Nachweis aus dem Patch-Protokoll auf dem Server selbst, keine beruhigende Nachricht.
  • Zweitens – suchen Sie nach Einbruchsspuren: verdächtige laufende Prozesse mit Namen, die Systemprozesse nachahmen, PHP-Dateien in Medien- und Bildordnern sowie ungewöhnliche Fehlerberichtsdateien.
  • Drittens – prüfen Sie das Protokoll ausgehender E-Mails. Ein plötzlicher Anstieg von Erinnerungs-E-Mails zu fehlgeschlagenen Zahlungen ist ein direkter Hinweis auf Ausnutzungsversuche, und jede Betriebsleitung kann ihn ohne tiefes Sicherheitswissen erkennen.
  • Viertens – rotieren Sie jeden Schlüssel, ohne Ausnahme, allen voran die Zugangsdaten des Zahlungsanbieters. Das braucht ein geplantes Wartungsfenster, keine improvisierte Entscheidung zur Hauptgeschäftszeit.
  • Fünftens – wenn Ihre Version älter als 2.4.4 ist, warten Sie nicht länger auf einen offiziellen Patch, der nicht kommen wird. Legen Sie einen Upgrade-Plan mit einem echten Datum fest und stellen Sie den Shop bis dahin hinter eine Web Application Firewall.
  • Sechstens – dokumentieren Sie, was Sie getan haben. Sollte sich herausstellen, dass Kundendaten abgeflossen sind, brauchen Sie eine Zeitleiste dessen, was Sie wann getan haben.

Der regulatorische Aspekt in Saudi-Arabien: Kundendaten sind nicht nur eine technische Angelegenheit

Ein Onlineshop, der Namen, Adressen, Mobilnummern und Bestellhistorien von Kunden speichert, verarbeitet personenbezogene Daten, die unter das Gesetz zum Schutz personenbezogener Daten fallen. Ein Datenleck bleibt keine interne Angelegenheit zwischen Shop und Hosting-Anbieter; es begründet Pflichten gegenüber der zuständigen Behörde und gegenüber den betroffenen Personen selbst. Die Frage, die sich ein Shopbetreiber heute stellen sollte, lautet deshalb nicht nur „Ist der Server gepatcht?“, sondern „Kann ich nachweisen, dass die Daten meiner Kunden nicht angetastet wurden?“.

Läuft Ihr Shop auf einer verwalteten Cloud-Plattform wie Salla oder Zid, fallen Sie nicht unter diese konkrete Lücke, weil das Patchen der Plattform nicht Ihre Aufgabe ist. Dieselbe Lehre gilt aber für jede Erweiterung oder Drittanbieter-Integration, die Sie an Ihren Shop angebunden haben: Die Verantwortung fürs Patchen liegt bei dem, dem der Server gehört.

Wie wir bei Origami mit solchen Vorfällen umgehen

Das Prinzip, nach dem wir Kundensysteme bauen, lautet: Ein Sicherheitsvorfall ist keine entfernte Möglichkeit, sondern ein aufgeschobenes Ereignis. In der Praxis heißt das dreierlei: Zugangsdaten liegen nicht im Code, sondern in einem separaten Tresor, sodass ihre Rotation eine Sache von Minuten ist und kein wochenlanges Projekt; Betriebsprotokolle werden außerhalb des Servers gespeichert, damit ein Angreifer seine Spuren nicht löschen kann; und Backups werden tatsächlich durch Wiederherstellung getestet, statt nur eingeplant zu sein.

Und wenn Sie einen Magento-Shop ohne eigenes Technikteam betreiben, ist der richtige Schritt heute einfach: Bitten Sie Ihren Hosting-Anbieter oder technischen Partner um einen schriftlichen Bericht, der nur drei Fragen beantwortet – wann genau die Korrektur installiert wurde, was die Prüfung auf Kompromittierung ergeben hat und ob die Schlüssel rotiert wurden. Diese drei Fragen verraten mehr über die Einsatzbereitschaft eines technischen Partners als jede Präsentation.

Quellen

  • Offizielle Ankündigung von Adobe Commerce zum Sicherheitsupdate APSB26-146 und zum dringenden Hotfix: experienceleague.adobe.com
  • Technische Analyse von Sansec zu CVE-2026-75650 und den Kompromittierungsindikatoren: sansec.io/research/stylesmuggler-0day
  • CISA-Katalog bekannter ausgenutzter Schwachstellen: cisa.gov
  • Gesetz zum Schutz personenbezogener Daten (PDPL) – Saudische Behörde für Daten und künstliche Intelligenz (SDAIA): sdaia.gov.sa