Magento-Sicherheitslücke CVE-2026-103849: Was Shopbetreiber jetzt tun müssen

Wer einen Shop auf Magento 2 oder Adobe Commerce betreibt, sollte diese Woche nicht auf das nächste reguläre Wartungsfenster warten. Adobe hat mit dem Security Bulletin APSB26-153 elf Schwachstellen geschlossen, fünf davon als „kritisch“ eingestuft. Im Mittelpunkt steht CVE-2026-103849: eine Lücke in der Template-Verarbeitung, die sich aus dem Internet heraus, ohne Benutzerkonto und ohne Zutun eines Admins ausnutzen lässt.

Auch Hoster wie maxcluster informieren ihre Kunden gerade aktiv und raten, alle Magento-2-Stores zeitnah zu prüfen. Wir fassen zusammen, was gesichert bekannt ist, welche Versionen betroffen sind und in welcher Reihenfolge du vorgehst.

Was ist CVE-2026-103849?

CVE-2026-103849 ist eine sogenannte Template Injection (CWE-1336: unzureichende Neutralisierung von Sonderzeichen in einer Template-Engine). Vereinfacht gesagt: Eingaben von außen können in die Template-Verarbeitung von Magento gelangen und dort als Code interpretiert werden.

Die wichtigsten Eckdaten laut Adobe:

• Schweregrad: kritisch, CVSS 3.1 Base Score 10,0 – der höchstmögliche Wert
• Angriffsvektor: über das Netzwerk, geringe Komplexität
• Voraussetzungen: keine Authentifizierung, keine Benutzerinteraktion
• Folge: Ausführung von beliebigem Code (Remote Code Execution)
• Veröffentlicht: 13.10.2026, Adobe-Priorität 2
• Ausnutzung: Adobe sind keine Angriffe in freier Wildbahn bekannt, ein öffentlicher Proof of Concept existiert bislang nicht (Stand 16.10.2026)

Technische Details zur betroffenen Komponente hat Adobe bewusst nicht veröffentlicht. Das ist üblich, ändert aber nichts an der Dringlichkeit – im Gegenteil: Sobald ein Patch öffentlich ist, können Angreifer ihn analysieren und die Lücke rekonstruieren.

Warum „kein Exploit bekannt“ keine Entwarnung ist

Magento hat in dieser Hinsicht eine unrühmliche Geschichte. Die ebenfalls template-bezogene Lücke CVE-2022-24086 wurde 2022 kurz nach Veröffentlichung in großem Stil ausgenutzt (Kampagne „TrojanOrders“). Und erst im September 2026 musste Adobe mit APSB26-146 eine Zero-Day-Lücke schließen: CVE-2026-75650 wurde laut Adobe bereits aktiv gegen Händler ausgenutzt – ebenfalls ohne Login, ebenfalls mit Codeausführung.

Online-Shops sind für Angreifer attraktiv, weil dort Kundendaten, Zahlungsflüsse und API-Schlüssel zu Payment- und Versanddienstleistern zusammenlaufen. Ein Checkout-Skimmer, der unbemerkt Kreditkartendaten mitliest, ist für Betreiber nicht nur ein technisches, sondern auch ein DSGVO- und Haftungsproblem.

Welche Magento- und Adobe-Commerce-Versionen sind betroffen?

Betroffen sind alle folgenden Versionslinien bis einschließlich zum September-2026-Stand („2026-sep“ und älter):

• Adobe Commerce 2.4.4 bis 2.4.9 – gepatcht in 2.4.4-2026-oct bis 2.4.9-2026-oct sowie 2.4.10-alpha1
• Adobe Commerce B2B 1.3.3, 1.3.4, 1.4.2, 1.5.2 und 1.5.3 – gepatcht in der jeweiligen 2026-oct-Version sowie 1.5.4-alpha1
• Magento Open Source 2.4.6 bis 2.4.9 – gepatcht in 2.4.7-2026-oct bis 2.4.9-2026-oct sowie 2.4.10-alpha1

Achtung bei Magento Open Source 2.4.6: Die Version ist laut Bulletin betroffen, Adobe nennt aber keine gepatchte Open-Source-Version für 2.4.6. Isolated Patches können Open-Source-Nutzer laut Adobe nur ab 2.4.7 herunterladen. Wer noch auf 2.4.6 läuft, braucht also ein Upgrade auf eine unterstützte Version – nicht nur einen Patch.

Und Hyvä? Hyvä ersetzt das Frontend-Theme, nicht den Magento-Core. Die Lücke steckt im Core – ein Hyvä-Shop ist deshalb genauso betroffen wie ein Shop mit Luma-Theme und muss ebenso gepatcht werden.

Die weiteren Lücken in APSB26-153

Neben CVE-2026-103849 schließt das Update zehn weitere Schwachstellen, darunter:

• CVE-2026-92909 (CVSS 9,8, ohne Login, Codeausführung) – betrifft nur Adobe Commerce B2B
• CVE-2026-91013 und CVE-2026-100133 (je CVSS 9,3) – Stored XSS ohne Login, führen zu Rechteausweitung
• CVE-2026-92464 (CVSS 9,1) – Codeausführung, setzt aber eine Anmeldung voraus
• mehrere Lücken mit hohem und mittlerem Schweregrad (Stored XSS, Schreibzugriff aufs Dateisystem, Umgehung von Sicherheitsfunktionen)

Shops ohne B2B-Modul sind damit vor allem über CVE-2026-103849 und die beiden XSS-Lücken angreifbar.

Schritt für Schritt: So schließt du die Lücke

1. Version und Patchstand ermitteln

Entscheidend ist nicht nur die Hauptversion (z. B. 2.4.8), sondern der genaue Patchstand. Adobe empfiehlt dafür das Commerce Version Tool, das du im Projektverzeichnis mit php vendor/bin/patch-status aufrufst. Es zeigt installierte und fehlende Patches sowie pro CVE den Status PROTECTED, VULNERABLE oder UNKNOWN. Das Tool ist erst ab dem Isolated Patch von Juli 2026 enthalten – fehlt es, ist das bereits ein Hinweis darauf, dass Patches nachzuholen sind.

Vergiss dabei Staging-, Test- und Demo-Instanzen nicht. Sie laufen oft mit demselben Code, sind aber deutlich seltener gepflegt – und häufig öffentlich erreichbar.

2. Voraussetzungen schaffen

Der Oktober-Isolated-Patch setzt voraus, dass

• dein Shop auf dem neuesten Security-Patchstand (-p-Version) seiner Release-Linie ist und
• alle vorherigen monatlichen Isolated Patches in chronologischer Reihenfolge eingespielt wurden – sie bauen aufeinander auf.

3. September-Hotfix für CVE-2026-75650 prüfen

Adobe weist ausdrücklich darauf hin, dass zusätzlich zum Oktober-Update der Hotfix für CVE-2026-75650 (APSB26-146) installiert sein muss. Da diese Lücke bereits aktiv ausgenutzt wurde, ist sie mindestens genauso dringend.

4. Oktober-Patch einspielen

• Selbst gehostet / On-Premises: Isolated Patch für deine Version aus dem Adobe-Repository laden und in der von Adobe vorgegebenen Reihenfolge anwenden (Core vor Enterprise vor B2B). Composer-Pakete gibt es für diesen Monat bewusst nicht.
• Adobe Commerce Cloud: Der Fix ist im aktuellen Cloud-Patches-Update enthalten. Den Isolated Patch dann nicht zusätzlich anwenden – das kann zu Installationsfehlern führen.

Wie immer gilt: erst auf Staging testen, dann im Wartungsfenster live einspielen.

5. Schlüssel und Zugangsdaten rotieren

Adobe empfiehlt ausdrücklich, als Teil der Behebung den Encryption Key und die zugehörigen Zugangsdaten zu rotieren. Hintergrund: Wurde ein Shop vor dem Patch kompromittiert, sind abgeflossene Schlüssel auch nach dem Update weiter gültig. Rotiere deshalb an der Quelle:

• Admin-Passwörter
• REST-, SOAP- und GraphQL-Integrationstoken sowie OAuth-Secrets
• API-Schlüssel von Zahlungs-, Versand- und Steuerdienstleistern
• SSH- und Deploy-Keys, Cron- und Service-Accounts
• Datenbank- und CDN-Zugangsdaten

6. Auf Spuren eines Angriffs prüfen

• Checkout- und Zahlungsseiten auf fremde, eingeschleuste Skripte kontrollieren
• Admin-Konten und Integrationen auf unbekannte Einträge prüfen
• Logs auf ungewöhnliche Template-Fehler und unerwartete Prozesse durchsehen

Findest du Auffälligkeiten, ist ein Patch allein nicht genug – dann geht es um forensische Aufarbeitung und gegebenenfalls Meldepflichten nach DSGVO.

Was der Fall über Shop-Betrieb lehrt

Kritische Magento-Lücken im Monatsabstand zeigen: Ein Online-Shop ist kein Projekt, das mit dem Go-live abgeschlossen ist. Wer Sicherheitsupdates nur „bei Gelegenheit“ einspielt, trägt ein reales Geschäftsrisiko. Drei Punkte machen in der Praxis den Unterschied:

1. Feste Patch-Prozesse: monatliche Sicherheitsupdates mit Staging-Test und definiertem Wartungsfenster – nicht erst, wenn eine Warnmail kommt.
2. Hosting, das mitdenkt: Ein Managed-Hosting-Partner mit Monitoring, Web Application Firewall und Backups verschafft dir Reaktionszeit. Worauf es dabei ankommt, haben wir in Performance & Sicherheit: Was professionelles Hosting leisten muss zusammengefasst – und warum Sparen hier teuer wird, in Die Risiken von Billig-Hosting.
3. Versionsstrategie: Wer auf einer auslaufenden Version wie Magento Open Source 2.4.6 festhängt, bekommt irgendwann schlicht keine Patches mehr. Spätestens dann stellt sich die Frage nach Upgrade oder Replatforming.

Unterstützung beim Patchen und im laufenden Betrieb

Wir betreuen Magento- und Hyvä-Shops technisch und spielen Sicherheitsupdates mit Staging-Test und Rollback-Plan ein. Wenn du unsicher bist, wie es um deinen Shop steht, prüfen wir im Shop-Health-Check Patchstand, Erweiterungen, Hosting und Performance. Für langfristig stabilen Betrieb findest du unter Hosting & Infrastruktur unsere Betriebsmodelle.

Und wenn die aktuelle Lage der Anlass ist, grundsätzlich über die Plattform nachzudenken: Im Hyvä-Migrations-Workshop klären wir den Weg auf ein modernes Magento-Frontend, in der agnostischen Systemempfehlung prüfen wir neutral, ob Magento, Shopware oder Shopify langfristig besser passt.

Akuter Handlungsbedarf? Melde dich direkt bei uns – wir prüfen deinen Shop kurzfristig.