Magento Sicherheitslücke CVE-2026-71362: fremde Kundensitzung ohne eigenes Konto

Die Magento Sicherheitslücke CVE-2026-71362 steht seit dem 24. September 2026 im Katalog der bekannt ausgenutzten Schwachstellen der US-Behörde CISA. Sie erlaubt es, eine Sitzung auf ein fremdes Kundenkonto umzuschalten – ohne eigenes Konto, ohne Adminrechte, ohne Zutun des Opfers. Neu ist nicht die Lücke, sondern der Nachweis der Ausnutzung. Wer einen Adobe-Commerce- oder Magento-Shop betreibt, sollte heute den Patch-Stand prüfen.

Was die Magento Sicherheitslücke technisch macht

CVE-2026-71362 ist eine fehlerhafte Autorisierungsprüfung (Incorrect Authorization, CWE-863) in Adobe Commerce, Adobe Commerce B2B und Magento Open Source. Adobe hat sie bereits am 11. August 2026 im Bulletin APSB26-92 behandelt. Der CVSS-Wert von 9.1 (Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) stammt von Adobe als zuständiger CNA; die NVD hat den Eintrag bislang nicht eigenständig bewertet.

Das auf E-Commerce spezialisierte Sicherheitsunternehmen Sansec hat Ausnutzungsversuche schon kurz nach dem August-Advisory beobachtet und blockiert. Der Ablauf laut Sansec: Die eigene Sitzung wird auf ein anderes Kundenkonto umgeschaltet, womit der Angreifer Zugriff auf dieses Konto und die dort gespeicherten privaten Kundendaten bekommt. Ein bestehendes Konto, Adminrechte oder eine Nutzerinteraktion braucht er dafür nicht.

Betroffen ist mehr, als auf den ersten Blick sichtbar wird. Bei Magento Open Source sind es die Juli-Sicherheitszüge 2.4.6-2026-jul bis 2.4.9-2026-jul und früher. Adobe Commerce reicht laut Advisory zwei Versionslinien weiter zurück – 2.4.4, 2.4.5, 2.4.6, 2.4.7, 2.4.8 und 2.4.9-2026-jul und früher –, dazu kommt Adobe Commerce B2B in den Linien 1.3.3 bis 1.5.3-2026-jul. Behoben ist es jeweils im passenden -2026-aug-Release; alternativ steht ein isolierter Patch bereit. Für US-Bundesbehörden setzte CISA als Frist den 27. September 2026 – ein Maßstab, den man als Shopbetreiber ruhig übernehmen darf. Im selben KEV-Schwung landete CVE-2026-5430, eine Lücke in WSO2-Produkten; einen Tag später folgte die WordPress-Lücke CVE-2026-87902, über die ich hier geschrieben habe.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Was die Magento Sicherheitslücke für dich bedeutet

Diese Klasse von Lücken wird systematisch unterschätzt, und das hat einen einfachen Grund: Es ist keine Remote-Code-Execution. Keine Webshell, kein fremder Prozess, kein auffälliger Ausgang aus dem Server. Genau deshalb ist sie für einen Shop besonders unangenehm.

Erstens sieht der Angriff im Logfile aus wie normaler Kundenverkehr. Wer nur nach klassischen Angriffsmustern sucht, findet nichts. Zweitens ist der Schaden sofort datenschutzrechtlich relevant: In einem Kundenkonto stehen Name, Adresse, Bestellhistorie, oft Telefonnummer und Teilinformationen zur Zahlung. Ein bestätigter fremder Zugriff darauf ist eine Verletzung des Schutzes personenbezogener Daten im Sinne der DSGVO – mit Meldepflicht nach Artikel 33 binnen 72 Stunden und, je nach Risiko, Benachrichtigung der Betroffenen nach Artikel 34. Der technische Schaden ist klein, der organisatorische groß.

Drittens, und das ist hier der eigentliche Befund: Zwischen Adobes Patch vom 11. August und der KEV-Aufnahme am 24. September liegen sechs Wochen, in denen bereits angegriffen wurde. Wer erst patcht, wenn eine Behörde eine Frist setzt, arbeitet strukturell zu spät. Und wer den Shop bei einem Dienstleister hosten lässt, trägt die Verantwortung trotzdem selbst – „der Provider macht Updates“ ist keine Antwort, sondern eine Annahme.

Praxis: vier Schritte für heute

• Version feststellen, nicht schätzen. bin/magento --version zeigt nur die Basisversion ohne Sicherheitszug. Verlässlich ist composer show magento/product-community-edition beziehungsweise magento/product-enterprise-edition bei Adobe Commerce. Ziel ist der -2026-aug-Zug. Ob ein isolierter Patch aktiv ist, zeigt ./vendor/bin/magento-patches status.
• Nach dem Patch alle Sitzungen invalidieren. Solange alte Sitzungen gültig bleiben, bleibt ein bereits übernommener Zugang bestehen. Session-Store leeren und Kunden neu anmelden lassen – unbequem, aber notwendig.
• Rückwärts prüfen. Da Angriffe seit August laufen, reicht „jetzt gepatcht“ nicht. Sieh dir Kontoänderungen, neue Lieferadressen und Bestellungen aus August und September an und lass einen Shop-Scanner über die Installation laufen.
• Meldung vorbereiten, bevor du sie brauchst. Findest du Belege für fremde Kontozugriffe, läuft die 72-Stunden-Frist. Halte Datenkategorien, Betroffenenzahl und den Kontaktweg zur Aufsichtsbehörde bereit, statt das im Ernstfall zu improvisieren.

Es ist die zweite ernste Magento-Baustelle innerhalb eines Monats – im September war es CVE-2026-75650. Wer beide Male hinterherhinkt, hat kein Lückenproblem, sondern ein Patch-Prozess-Problem.

Quellen

• Adobe: Security update available for Adobe Commerce (APSB26-92, 11.08.2026)
• CISA: Adds Two Known Exploited Vulnerabilities to Catalog (24.09.2026)
• NVD: CVE-2026-71362
• Sansec: Adobe Commerce account takeover (APSB26-92)
• The Hacker News: WSO2 and Adobe Commerce Flaws Exploited in Attacks, Added to CISA KEV