Am 7. September 2026 um 22:20 Uhr MESZ, an einem Montagabend, veröffentlichte Adobe außer der Reihe einen Hotfix für Magento 2. Die Lücke „StyleSmuggler“ (CVE-2026-75650) erreicht den Höchstwert von 10.0 auf der CVSS-Skala und wurde da schon seit drei Tagen ausgenutzt. Der Hotfix war allerdings nur gegen die Patch-Stände vom August 2026 getestet. Wer seinen Shop aktuell hatte, konnte noch in derselben Nacht patchen. Wer drei Releases hinten lag, musste erst ein Update-Projekt fahren, während die Angriffe weiterliefen. Genau dieser Abstand zwischen „Patch existiert“ und „Patch ist live“ entscheidet, ob dein Magento 2 sicher ist. In diesem Artikel zeigen wir, wie der Patch-Rhythmus von Adobe 2026 aussieht, was die DSGVO und PCI-DSS von dir als Shopbetreiber konkret verlangen und wie du das im Alltag umsetzt, ohne dass jedes Update zum Nervenkrimi wird.
Wie Adobe Magento 2 seit 2026 patcht
Bis Ende 2025 kamen Sicherheitsupdates für Magento grob im Quartalstakt, gebündelt in Versionen wie 2.4.7-p7. Seit Jänner 2026 gilt ein neues Modell. Adobe veröffentlicht isolierte Security-Patches bei Bedarf jeden Monat am zweiten Dienstag, dem sogenannten Patch Tuesday. Allein zwischen Mai und September 2026 gab es Security-Termine am 12. Mai, 14. Juli, 11. August und 8. September. Dazu kommt einmal im Jahr, jeweils im Mai, ein Feature-Release (2026 war das 2.4.9) und ein bis zwei gesammelte Patch-Releases pro Jahr. Brennt es wie bei StyleSmuggler, gibt es zusätzlich außerplanmäßige Hotfixes.
Für dich als Shopbetreiber hat das eine Konsequenz, die in der Adobe-Dokumentation eher beiläufig steht. Die monatlichen Patches sind ZIP-Dateien ohne Composer-Paket, und sie lassen sich nur einspielen, wenn dein Shop bereits auf dem aktuellsten -pN-Stand seiner Versionslinie läuft. Wer also bei 2.4.7-p3 stehen geblieben ist, kann den Juli-Patch nicht einfach nachschieben. Er muss erst sieben Patch-Releases aufholen.
Wir halten das für die wichtigste Änderung der letzten Jahre im Magento-Betrieb. Rückstand war früher ärgerlich. Heute sperrt er dich von akuten Fixes aus.
Welche Versionen Adobe aktuell noch mit Patches versorgt:
| Version | Erschienen | Regulärer Support bis | Hinweis |
|---|---|---|---|
| 2.4.9 | 12. Mai 2026 | 31. Mai 2029 | aktueller Standard-Pfad |
| 2.4.8 | 8. April 2025 | 31. Mai 2028 | |
| 2.4.7 | 9. April 2024 | 31. Mai 2027 | erste Version mit SRI und Checkout-CSP |
| 2.4.6 | 14. März 2023 | 11. August 2026 (beendet) | Extended Support nur für Adobe-Commerce-Lizenzen |
Läuft dein Shop auf 2.4.6 oder älter, beschreibt unser Aktionsplan zum Magento 2.4.6 End-of-Life die realistischen Upgrade-Pfade.
Warum ein Patch-Rückstand so teuer wird
Drei kritische Lücken in gut zwei Jahren zeigen, wie schnell es geht:
| Lücke | CVE | CVSS | Was passiert ist |
|---|---|---|---|
| CosmicSting | CVE-2024-34102 | 9,8 | Patch im Juni 2024, bis Oktober zählte Sansec rund 4.275 gehackte Shops, etwa 5 % aller Installationen |
| SessionReaper | CVE-2025-54236 | 9,1 | Patch im September 2025, sechs Wochen später aktive Angriffe, laut Sansec drei von fünf Shops noch verwundbar |
| StyleSmuggler | CVE-2026-75650 | 10,0 | Angriffe ab 4. September 2026, Hotfix erst drei Tage später, erstes Opfer lief auf 2.4.6-p15 mit allen Patches bis August |
StyleSmuggler ist dabei der unbequemste Fall. Hier half selbst ein perfekter Patchstand in den ersten drei Tagen nichts. Gegen das Patchen spricht das trotzdem nicht. Nur wer aktuell war, konnte den Hotfix sofort einspielen, und nur wer ein Monitoring hatte, wusste am 5. September überhaupt, dass er handeln muss. Patchen allein genügte trotzdem nicht. Adobe schreibt nach StyleSmuggler zusätzlich eine Prüfung auf Kompromittierung und die Rotation aller Zugangsdaten vor, vom Encryption-Key bis zu den Payment-Credentials. Die Details stehen in unserem Leitfaden zu StyleSmuggler.
Nach so einem Einbruch läuft der Shop meist äußerlich ganz normal weiter, während ein eingeschleustes Skript im Checkout Kartendaten mitliest. Davon merkst du oft erst etwas, wenn die Bank oder der Payment-Provider anruft.
Dass Shops trotzdem lange ungepatcht bleiben, hat selten mit Nachlässigkeit zu tun. Meistens fehlt eine Staging-Umgebung, oder es gab schon einmal ein Update, das den Checkout lahmgelegt hat. Seitdem traut sich niemand mehr ran. Das ist nachvollziehbar, aber es dreht das Risiko um. Wie man Patches so einspielt, dass genau das nicht passiert, haben wir ausführlich in unserem Beitrag zum sicheren Update- und Patch-Management für Magento beschrieben.
DSGVO: Was Sicherheit nach dem Stand der Technik für deinen Shop heißt
Die DSGVO wird bei Magento meistens mit Cookie-Banner und Datenschutzerklärung verbunden. Für die Sicherheit ist aber ein anderer Artikel entscheidend. Art. 32 verpflichtet dich, personenbezogene Daten durch Maßnahmen „unter Berücksichtigung des Stands der Technik“ zu schützen. Was genau Stand der Technik ist, definiert die Verordnung nicht. Einen öffentlich bekannten, von Adobe als kritisch eingestuften Fehler monatelang offen zu lassen, wird man darunter aber kaum verbuchen können. (Wir sind keine Anwälte. Das ist unsere Einschätzung aus der Praxis, keine Rechtsberatung.)
Kommt es zur Datenpanne, läuft eine zweite Uhr. Bei StyleSmuggler war das sehr konkret: Wer am Montag den Hotfix einspielte und am Dienstag Spuren eines Einbruchs fand, musste bis Freitag die Behörde informiert haben. Nach Art. 33 musst du die Datenschutzbehörde „unverzüglich und möglichst binnen 72 Stunden“ informieren. Verstöße gegen Art. 32 und 33 können mit bis zu 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist.
In einem Magento-Shop sind es vor allem diese Stellen, an denen DSGVO und Technik aufeinandertreffen:
- Erweiterungen von Drittanbietern: Jedes Modul, das Kundendaten an einen externen Dienst schickt (Bewertungen, Newsletter, Tracking, Chat), braucht eine Rechtsgrundlage und meist einen Auftragsverarbeitungsvertrag.
- Admin-Zugänge: Seit Magento 2.4.0 ist die Zwei-Faktor-Authentifizierung für alle Admin-Benutzer standardmäßig aktiv. Adobe rät ausdrücklich davon ab, das Modul zu deaktivieren. Ob das Modul in deinem Shop noch aktiv ist, zeigt der Admin-Login: Fragt er nach einem zweiten Faktor, passt es.
- Datenaufbewahrung: Alte Warenkörbe, Gastbestellungen und Logdateien sammeln über Jahre Kundendaten an, die niemand mehr braucht.
- Backups und Hosting: Wo liegen deine Datenbank-Backups, und wer hat Zugriff? Für DSGVO-sensible Setups setzen wir auf Hosting in Österreich.
- Wiederherstellbarkeit: Art. 32 fordert ausdrücklich, dass du Daten nach einem Zwischenfall rasch wiederherstellen kannst. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung, kein Nachweis.
PCI-DSS 4.0: Warum der Checkout jetzt im Fokus steht
PCI-DSS ist der Sicherheitsstandard der Kreditkartenbranche. Er gilt für jeden Shop, der Kartenzahlungen annimmt, auch wenn die Zahlung technisch über Stripe, Adyen, Mollie oder PayPal läuft. Mit Version 4.0 sind seit dem 31. März 2025 zwei Anforderungen verpflichtend, die direkt auf das Angriffsmuster von CosmicSting und Co. zielen:
- 6.4.3: Jedes Skript, das auf der Zahlungsseite läuft, muss inventarisiert, autorisiert und auf Integrität geprüft sein.
- 11.6.1: Unerlaubte Änderungen an der Zahlungsseite müssen erkannt und gemeldet werden.
Magento hat darauf reagiert. Ab Version 2.4.7 prüft der Shop auf Checkout-Seiten per Subresource Integrity (SRI), ob JavaScript-Dateien unverändert sind. Die Content Security Policy läuft dort im „restrict“-Modus und blockiert nicht freigegebene Skripte, statt sie nur zu protokollieren. Das ist eine solide Basis. Sie hilft dir allerdings nur, wenn dein Shop auf einer unterstützten Version läuft und die CSP-Whitelist nicht aus Bequemlichkeit aufgeweicht wurde, weil ein Tracking-Pixel sonst nicht lädt.
Für viele kleinere Shops gibt es eine Erleichterung. Im Jänner 2025 hat das PCI Security Standards Council die Anforderungen 6.4.3 und 11.6.1 aus dem Fragebogen SAQ A gestrichen. SAQ A gilt für Shops, die Zahlungsdaten ausschließlich per Weiterleitung oder Iframe an einen zertifizierten Anbieter übergeben. Ersetzt wurde das durch eine Bestätigung, dass deine Seite nicht für Skript-Angriffe auf das E-Commerce-System anfällig ist. Kannst du das nicht bestätigen, landest du beim strengeren SAQ A-EP.
Ehrlich gesagt halten wir diese Bestätigung für schwer abzugeben, wenn der Shop mehrere Patch-Releases hinterherhinkt. PCI-DSS verlangt ohnehin unterstützte Software. Ein Magento ohne Security-Support ist damit auch payment-seitig ein offenes Thema.
In der Praxis: So spielen wir Magento-Patches ein
Patches, DSGVO und PCI-DSS hängen am Ende an derselben Frage: Läuft dein Shop auf einer Version, für die es noch Patches gibt, und sind die auch eingespielt? Genau dafür haben wir unseren Patch-Service für Magento 2 aufgebaut. Der Ablauf ist bei allen Kunden gleich:
- Monitoring: Wir verfolgen die Adobe Security Bulletins und CVE-Meldungen für Magento, PHP und gängige Erweiterungen. Den Versionsstand jedes betreuten Shops führen wir zentral, damit wir bei einem neuen Bulletin sofort sehen, wer betroffen ist.
- Testsystem: Reguläre Updates landen zuerst auf deinem Staging-System, niemals direkt live. Bei aktiv ausgenutzten Lücken wie StyleSmuggler ziehen wir vor und stimmen den Ablauf direkt mit dir ab.
- Deine Tests: Du bekommst eine Nachricht mit einer kurzen Prüfliste: Checkout und Bestellprozess, Login und Registrierung, Suche, Kategorien und Produktseiten, CMS-Inhalte und individuelle Funktionen. Für dein Feedback hast du sieben Tage Zeit.
- Live-Gang nach Freigabe: Wann das Update auf Produktion geht, entscheidest du. Meldest du dich nicht, gilt das Update nach 14 Tagen als freigegeben. So bleibt kein Patch monatelang auf Staging liegen.
Wie das konkret aussieht: Am 12. Mai 2026 erschien 2.4.8-p5. Bei einem unserer Handelskunden lag das Update am nächsten Tag auf dem Testsystem. Zwei Tage später kam die Rückmeldung: „Ich hab mich eine Zeit lang durch’s Staging geklickt, mir ist nichts Problematisches aufgefallen.“ Am darauffolgenden Dienstag war der Patch live. Unspektakulär, und genau so soll es sein.
Den Patch-Service gibt es in zwei Varianten:
| Standard | Pro | |
|---|---|---|
| Monitoring und Patch-Analyse | ✓ | ✓ |
| Einspielen auf Staging | ✓ | ✓ |
| Eigene Smoke-Tests vor der Übergabe | ✓ | |
| Fixes bei Konflikten mit Erweiterungen | nach Aufwand | fixes Stundenkontingent pro Patch |
| Preis | ab 159 € / Monat | auf Anfrage |
Auch wenn dein Shop von einer anderen Agentur betreut wird
Den Patch-Service übernehmen wir auch für Shops, die nicht wir entwickelt haben. Das gilt für Shopbetreiber, deren Agentur selbst keine Patches einspielt, genauso wie für Agenturen, die das Thema an uns auslagern wollen (für Agenturen auch als White-Label-Partner). Wir brauchen dafür lediglich Zugang zu eurem Git-Repository. Jeder Security-Patch und jedes Release kommt als eigener Merge Request, den eure Agentur prüft, mergt und deployt. Alles andere bleibt unangetastet: Custom-Code, Deployment-Prozess, Hosting und die Zusammenarbeit mit eurer bestehenden Agentur.
Wer die manuelle Testrunde ganz loswerden will, kombiniert den Patch-Service mit unseren automatisierten Shop-Tests. Dann prüft eine Testsuite Checkout, Login und Suche nach jedem Update selbst, und du schaust dir nur noch die Ergebnisse an.
Ein Moment, der hängengeblieben ist: die StyleSmuggler-Woche
Die Woche ab dem 4. September 2026 war für uns eine der aufwändigsten des Jahres. Wir wussten, dass da eine Lücke mit CVSS 10.0 draußen ist, die aktiv ausgenutzt wird. Einen Patch von Adobe gab es nicht. Also haben wir in der Magento-Community nachgefragt und parallel selbst analysiert, wie die Angriffe ablaufen. Noch am selben Tag kursierten die ersten Gegenmaßnahmen, teils als gehärtete nginx-Regeln, teils als WAF-Einträge. Die haben wir binnen Stunden bei unseren Kunden eingespielt, Shops mit Patch-Service zuerst. Bis Adobe am 7. September den offiziellen Hotfix nachlieferte, war der Großteil unserer Shops so abgesichert. Danach haben wir die provisorischen Regeln durch den echten Patch ersetzt. Drei Tage nach Bekanntwerden waren alle Shops gepatcht.
Zur Wahrheit gehört auch: Trotz dieser Geschwindigkeit waren einzelne Shops unserer Kunden betroffen, weil die Angriffe vor jedem verfügbaren Fix begonnen hatten. Dort haben wir nach dem Patch gemeinsam mit den Kunden nachgeprüft und die nötigen Schritte umgesetzt. Wir schreiben das hier, weil es die ehrlichste Antwort auf die Frage ist, ob regelmäßiges Patchen reicht. Es reicht nicht immer. Aber ohne aktuellen Stand hätten wir den Hotfix gar nicht sofort einspielen können.
Was du als nächstes tun kannst
Wenn du nicht sicher bist, wie es um deinen Shop steht, gibt es zwei pragmatische erste Schritte:
- Versionsstand prüfen: Im Magento-Admin steht unten rechts im Footer deine aktuelle Version. Vergleiche sie mit der Tabelle oben. Liegst du mehr als ein -pN-Release hinter dem aktuellen Stand deiner Linie, kannst du die monatlichen Patches nicht einspielen.
- Patch-Service besprechen: Wir schauen uns deinen Shop an, sagen dir ehrlich, wie groß der Rückstand ist, und übernehmen danach die laufenden Patches. Melde dich per office@copex.io oder über ein kostenloses Erstgespräch.
Verwandte Themen aus unserem Blog: StyleSmuggler: Hotfix, Kompromittierungs-Check und Credential-Rotation, Sicheres Update- und Patch-Management für Magento, Magento 2.4.6 End-of-Life.
Und falls du dich fragst, warum Adobe jetzt monatlich patcht: Weil die Angreifer es auch tun.
Quellen / Weiterlesen
- Adobe Experience League: Release-Zeitplan für Adobe Commerce und Lifecycle Policy
- Adobe Experience League: Isolierte Security-Patches
- Adobe Experience League: Release Notes Adobe Commerce 2.4.7 (SRI und CSP auf Zahlungsseiten)
- CopeX-Blog: StyleSmuggler (CVE-2026-75650) mit Zeitleiste und Adobe-Bulletin APSB26-146
- Sansec: CosmicSting und SessionReaper-Angriffe
- DSGVO: Art. 32, Art. 33, Art. 83
- SecurityMetrics: Änderungen am SAQ A 2025




