Magento-Lücke mit Patch seit Juli steht im KEV-Katalog der CISA

Betroffen ist jeder Magento-Shop, der die Juli-Updates von Adobe nicht eingespielt hat. Die CISA hat CVE-2026-48356 am 27. Oktober in ihren KEV-Katalog aufgenommen und damit als ausgenutzt eingestuft. Adobe hatte die Lücke mit dem Bulletin APSB26-73 am 14. Juli geschlossen. Betroffen sind unter anderem Adobe Commerce 2.4.9 und 2.4.8-p5 sowie ältere Stände, außerdem Magento Open Source bis zurück zu 2.4.6-p15. Behoben ist sie in den Builds mit der Endung „-2026-jul“.

Zwischen Patch und Katalogeintrag liegen gut drei Monate. Wer in dieser Zeit keinen Updatetermin hatte, sollte den Patchstand klären (dm-Einordnung). Unterschieden werden muss dabei sauber: Die Schwachstelle ist seit Juli bekannt, die Ausnutzung belegt die CISA seit Oktober. Zu Umfang und Urhebern liegen keine Angaben vor.

Der Eintrag der CISA vom 27. Oktober

Die US-Behörde CISA (Cybersecurity and Infrastructure Security Agency) hat am 27. Oktober 2026 zwei Schwachstellen in ihren Katalog bekannter ausgenutzter Lücken aufgenommen. Das steht im Alert der CISA. Die erste ist CVE-2026-48356 in Adobe Commerce und Magento Open Source, die zweite CVE-2026-111497 in Brotli. Für Shops ist nur die erste Nummer relevant.

Zur Einordnung der Begriffe, als dm-Einordnung: CVE steht für Common Vulnerabilities and Exposures. Es ist ein weltweit genutztes Verzeichnis, das jeder bekannten Schwachstelle eine eindeutige Kennung gibt, damit Herstellerhinweise, Warnungen und Prüfwerkzeuge dieselbe Lücke meinen. Der KEV-Katalog (Known Exploited Vulnerabilities) ist eine Liste der CISA. Sie führt nur Lücken auf, deren Ausnutzung die Behörde als belegt ansieht. Das unterscheidet ihn von der riesigen Menge theoretisch möglicher Schwachstellen. Ein Eintrag ist also ein Signal, dass das Risiko über die Theorie hinausgeht.

Zum Eintrag zu CVE-2026-48356 gehören zwei Felder. Das Fälligkeitsdatum lautet 10. November 2026. Das Feld zur Nutzung in Ransomware-Kampagnen („knownRansomwareCampaignUse“) steht auf „Unknown“. Das bedeutet, dass die CISA keinen Zusammenhang mit Erpressungstrojanern angibt. Es ist keine Entwarnung, sondern schlicht eine fehlende Angabe.

Die Frist vom 10. November gilt ausdrücklich nur für US-Bundesbehörden, genauer für die zivilen Bundesbehörden der Exekutive. Dafür steht die Abkürzung FCEB (Federal Civilian Executive Branch). Grundlage ist die verbindliche Anweisung BOD 26-04. BOD bedeutet Binding Operational Directive, eine Weisung der CISA an diese Behörden, gelistete Lücken bis zu einem festen Termin zu beheben. Für Shops oder Unternehmen in Deutschland ist das Datum keine rechtliche Frist. Als dm-Einordnung taugt es höchstens als Orientierung: Wenn schon Behörden unter Zeitdruck patchen müssen, spricht wenig dafür, dass ein Shop sich mehr Zeit lassen sollte.

Dass Magento-Lücken im Katalog bekannter ausgenutzter Schwachstellen landen, ist nicht neu: Schon die Aufnahme von Magento und WSO2 betraf diese Software.

Nicht im Alert steht, wie viele Shops betroffen sind, wer die Lücke ausnutzt oder wann der erste Angriff stattfand. Diese Angaben sollten Sie auch nicht aus Gerüchten ableiten.

Die Aufnahme sagt nichts darüber, wie lange die Ausnutzung schon läuft. Sie belegt nur, dass sie zum Zeitpunkt der Aufnahme als nachgewiesen gilt.

Die Lücke im Adobe-Bulletin

Adobe hat die Schwachstelle am 14. Juli 2026 im Security-Bulletin APSB26-73 beschrieben. Ein Security-Bulletin ist die offizielle Mitteilung eines Herstellers zu behobenen Sicherheitsproblemen. Es nennt betroffene Versionen, Schweregrad und Korrekturstände. Zuletzt aktualisiert wurde dieses Bulletin am 11. August 2026.

Adobe ordnet CVE-2026-48356 der Schwächenklasse CWE-434 zu. CWE (Common Weakness Enumeration) ist ein Katalog typischer Fehlerarten in Software, im Gegensatz zu CVE, die einzelne konkrete Lücken benennt. CWE-434 steht für „Unrestricted Upload“, also das Hochladen von Dateien ohne ausreichende Einschränkung. Wie der Fehler in Magento konkret aussieht, nennt die Quelle nicht, und hier wird es auch nicht ergänzt.

Adobe stuft die Lücke als kritisch („Critical“) ein und vergibt einen CVSS-Wert von 9,6. Der vollständige Vektor aus dem Adobe-Bulletin lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L. CVSS (Common Vulnerability Scoring System) bewertet Schwachstellen auf einer Skala von 0 bis 10. Als dm-Einordnung zu den Metriken: AV:N heißt, dass die Lücke über das Netzwerk erreichbar ist. AC:L steht für geringe Komplexität des Angriffs, es braucht also keine besonderen Bedingungen. PR:N bedeutet, dass keine Berechtigungen nötig sind, also keine Anmeldung. UI:R steht für „User Interaction Required“, es muss also eine Person etwas tun, etwa eine Aktion auslösen. S:C („Scope Changed“) heißt, dass die Auswirkung über die verwundbare Komponente hinausreichen kann. C:H und I:H bedeuten hohe Auswirkungen auf Vertraulichkeit und Integrität, also auf den Schutz und die Unverändertheit von Daten. A:L steht für eine geringe Auswirkung auf die Verfügbarkeit.

Bei der Auswirkung weichen die Quellen in der Beschreibung voneinander ab. Adobe nennt „Privilege escalation“, also eine Rechteausweitung. Die CISA beschreibt Codeausführung. Beides sind unterschiedliche Folgen, und beide Angaben stehen nebeneinander. Es ist nicht geklärt, welche in der Praxis eintritt. Das lässt sich aus den Quellen nicht entscheiden.

Besonders wichtig ist die zeitliche Trennung. Die Schwachstelle ist seit Juli öffentlich dokumentiert. Das Bulletin sagt mit Stand 11. August weiterhin, Adobe sei kein Exploit bekannt. Die CISA hingegen stuft die Lücke am 27. Oktober als ausgenutzt ein. Das ist kein Widerspruch im strengen Sinn: Ein Herstellerhinweis hält den Wissensstand seiner letzten Aktualisierung fest, die KEV-Aufnahme markiert einen späteren Stand. Wer nur das Bulletin liest, kommt zu einem überholten Bild. Wer nur den Katalogeintrag liest, übersieht, dass der Fix seit Monaten bereitliegt.

Dass die Ausnutzung Nutzerinteraktion erfordert, sollten Shopbetreibende nicht als Beruhigung lesen. Es beschreibt eine Voraussetzung, aber keine Hürde, die Sie selbst beeinflussen können.

Als dm-Einordnung: Für die Priorisierung im Shopbetrieb ist dieser Unterschied zweitrangig. Entscheidend ist die Kombination aus drei Punkten: Die Lücke gilt als kritisch, sie lässt sich ohne Anmeldung erreichen, und sie steht im KEV-Katalog, der Schwachstellen mit bekannter Ausnutzung führt. Es genügt, die eigene Version zu prüfen und das Update einzuplanen.

Welche Versionen betroffen sind

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptIT administrator applying an update on a laptop next to a server, a checklist on a clipboard beside it, calm focused atmosphere, daylight office. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Das Bulletin listet betroffene Stände für zwei Produkte. Adobe Commerce ist die kommerzielle Variante mit Support und zusätzlichen Funktionen, Magento Open Source die freie Community-Version. Beide teilen sich einen Code-Grundstock, haben aber getrennte Versionslinien und Patchzyklen.

• Adobe Commerce: 2.4.9, 2.4.8-p5 und älter, 2.4.7-p10 und älter, 2.4.6-p15 und älter, 2.4.5-p17 und älter, 2.4.4-p18 und älter; behoben in 2.4.9-2026-jul bis 2.4.4-2026-jul
• Magento Open Source: 2.4.9, 2.4.8-p5 und älter, 2.4.7-p10 und älter, 2.4.6-p15 und älter; behoben in 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul und 2.4.6-2026-jul

Behoben ist die Lücke in den Versionen mit dem Zusatz „-2026-jul“. Das Kürzel steht für einen Patch-Build vom Juli 2026. Als dm-Einordnung: Solche Builds sind Stände, die ein sicherheitsrelevantes Update bereits enthalten. Eine Versionsnummer allein zeigt daher nicht immer, ob die Korrektur drin ist. Entscheidend ist, ob der Build den Juli-Zusatz trägt.

Auffällig an der Liste ist, dass die Versionsbereiche der beiden Produkte unterschiedlich weit zurückreichen. Bei Adobe Commerce nennt das Bulletin die Linien 2.4.4 bis 2.4.9, bei Magento Open Source nur die Linien 2.4.6 bis 2.4.9, jeweils mit eigenem Juli-Build. Warum, sagt die Quelle nicht.

Für die Prüfung ist das praktisch. Wenn Ihr Shop zum Beispiel auf Open Source 2.4.5 läuft, steht diese Linie weder in der Liste noch ist sie als gefixt ausgewiesen. Daraus lässt sich keine Entwarnung ableiten. Fehlende Angaben sind kein Beweis dafür, dass Ihr Stand sicher ist. Klären Sie das mit Adobe oder Ihrer Agentur.

Die Version finden Sie im Admin-Bereich Ihres Shops, meist unten auf der Seite, oder in der Dokumentation Ihrer Installation. Ihre Hosting-Firma oder Agentur kann sie ebenfalls nennen. Gleichen Sie die Angabe mit der Liste ab: Liegt Ihr Stand im genannten Bereich und trägt er keinen „-2026-jul“-Zusatz, ist das Update offen.

Erweiterungen und individuelle Anpassungen können ein Update erschweren. Als dm-Einordnung empfiehlt sich, das Update zuerst in einer Testumgebung durchzuspielen, die dem Live-Shop möglichst nahekommt. Dort lässt sich prüfen, ob Bestellvorgang, Zahlungsarten und eingesetzte Erweiterungen weiterhin funktionieren.

Vor dem Einspielen im Live-Betrieb sollte eine vollständige Sicherung von Dateien und Datenbank vorliegen, und die Rücksicherung sollte erprobt sein. Betreut eine Agentur den Shop, stimmen Sie Zeitfenster und Zuständigkeiten vorab mit ihr ab, damit niemand auf die Rückmeldung der anderen Seite wartet.

Als dm-Einordnung: Eine Version in der Liste betroffener Versionen bedeutet, dass sie verwundbar ist. Ob sie tatsächlich ausgenutzt wurde, ist eine andere Frage.

Prüfschritte für Shopbetreibende

Die folgenden Schritte sind dm-Einordnung und keine Vorgabe von Adobe oder der CISA. Sie nennen keine Angriffsmerkmale und keine Befehle.

1. Patchstand feststellen. Ermitteln Sie die genaue Version und den Build Ihrer Installation und vergleichen Sie sie mit der Versionsliste. Fehlt der Zusatz „-2026-jul“, hat Ihr Shop den Juli-Fix nicht.
2. Update einplanen. Spielen Sie den passenden Juli-Build ein, möglichst nach einem Test in einer Staging-Umgebung. Da der Fix seit dem 14. Juli vorliegt, ist ein weiteres Abwarten kaum zu begründen.
3. Hochgeladene Dateien prüfen. Die Schwächenklasse betrifft Uploads. Lassen Sie daher prüfen, ob in Upload-Bereichen Dateien liegen, die dort nicht hingehören oder die niemand kennt.
4. Integrität des Codes prüfen. Vergleichen Sie den Stand Ihrer Installation mit einem sauberen, offiziellen Auslieferungsstand und achten Sie auf Abweichungen, die keine Änderung Ihres Teams erklärt.
5. Zugänge kontrollieren. Sehen Sie nach, ob es Admin-Konten gibt, die niemand angelegt hat, und ob Berechtigungen ungewöhnlich erweitert wurden. Das passt zur von Adobe genannten Rechteausweitung.
6. Protokolle sichten lassen. Ihre Hosting-Firma oder Agentur kann auffällige Zugriffe auf Upload-Funktionen im fraglichen Zeitraum nachsehen, am besten ab dem Juli-Bulletin.

Der Zeitraum ist die eigentliche Unbekannte. Weil das Datum eines ersten Angriffs nicht bekannt ist, lässt sich nicht sagen, ab wann eine Prüfung zurückreichen sollte. Als dm-Einordnung ist der pragmatische Ansatz, ab dem Zeitpunkt zu prüfen, zu dem Ihr Shop verwundbar war. Das ist der Zeitraum seit Veröffentlichung des Bulletins am 14. Juli bis zum Einspielen des Fixes. Eine dm-Rechnung dazu: Vom 14. Juli bis zum 27. Oktober sind es 17 Tage im Juli (15. bis 31.), 31 im August, 30 im September und 27 im Oktober (1. bis 27.), also 17 + 31 + 30 + 27 = 105 Tage. Wer erst nach dem KEV-Eintrag patcht, hat also gut 100 Tage mit offener Lücke hinter sich. Das ist keine Aussage über einen Angriff, sondern über das Fenster, das Sie prüfen sollten.

Ist etwas Auffälliges aufgetaucht, hilft kein Aufräumen auf eigene Faust. Sichern Sie den Zustand, holen Sie Fachleute für Forensik hinzu und denken Sie über eine Meldung nach, wenn Kundendaten berührt sein könnten. Das ist als dm-Einordnung gemeint, nicht als Rechtsberatung.

Dass eine Korrektur schon bereitliegt, wenn die CISA eine Magento-Lücke als ausgenutzt listet, gab es auch bei der früheren Magento-Lücke mit Hotfix.