Shopware CVE-2026-48014: Autorisierungsumgehung in der Admin-API

Schritt für Schritt
So lief der Angriff ab
Klicken Sie auf eine Phase für Details – oder lassen Sie die Animation durchlaufen.
PHASE 1/4 · Erstzugriff

Ein Angreifer nutzt ein gültiges, niedrig privilegiertes API-Konto, um Zugriff auf die Admin-API von Shopware zu erhalten.

T1190 – Exploit Public-Facing Application T1078 – Valid Accounts
  • Voraussetzung: gültige API-Sitzung mit beliebigem, auch sehr eingeschränktem Konto
  • Häufig genutzt: Integrationskonten für ERP, Fulfillment oder Support-Tools
  • Betroffen sind ca. 30.089 Shops weltweit, davon über 20.000 in Deutschland
  • Angriff läuft über direkte API-Aufrufe, unabhängig von UI-Beschränkungen
PHASE 2/4 · Ausführung

Der Angreifer sendet einen versteckten API-Aufruf an die Zustandsübergangs-Endpunkte für Bestellungen.

T1106 – Native API
  • Angriff auf drei ungeschützte Routen: /api/_action/order/{orderId}/state/{transition} u.a.
  • Benötigt lediglich eine bekannte oder erratene Bestell-ID
  • Normales order-update-API liefert 403, die Übergangs-Aktion antwortet mit 200
  • CVE-2026-48014 / EUVD-2026-45241, CVSS 6.5 (Medium)
PHASE 3/4 · Rechteausweitung

Durch fehlende ACL-Metadaten und ein Fail-Open-Verhalten umgeht der Nutzer die Autorisierungsgrenze.

T1068 – Exploitation for Privilege Escalation T1548 – Abuse Elevation Control Mechanism
  • Vertikale Autorisierungsumgehung (Broken Access Control)
  • Drei Routen fehlt die ACL-Rechte-Kennzeichnung in den Route-Metadaten
  • AclAnnotationValidator bricht bei fehlenden Annotationen ab und lässt durch (Fail-Open)
  • Rechte order:update, order_transaction:update, order_delivery:update werden umgangen
PHASE 4/4 · Auswirkung

Der Zustandswechsel wird mit Systemrechten (SYSTEM_SCOPE) in die Datenbank geschrieben und manipuliert Bestellzustände.

T1565 – Data Manipulation T1565.001 – Stored Data Manipulation
  • Bestellungen können storniert, als bezahlt oder als versendet markiert werden
  • Ausführung im SYSTEM_SCOPE ohne weitere Berechtigungsprüfung
  • Folgen: Verlust operativer Integrität, Missbrauch von Automatisierung, Störung von Fulfillment/Abrechnung/Support
  • Spuren nachweisbar in der Tabelle state_machine_history
Kurz & knapp beantwortet
Häufige Fragen zu diesem Vorfall
Bin ich von CVE-2026-48014 betroffen?
Betroffen sind alle Shopware-Installationen vor Version 6.6.10.18 (im 6.6.x-Zweig) sowie alle Versionen von 6.7.0.0 bis einschließlich 6.7.10.0. Ihre Version finden Sie im Adminbereich unter Einstellungen > System > Versionsinformationen oder per Konsole mit php bin/console --version. Auch ältere Zweige wie 6.5.x gelten als anfällig, da sie keine Sicherheitspatches mehr erhalten.
Was muss ich jetzt tun, um die Lücke zu schließen?
Erstellen Sie zuerst ein vollständiges Backup und aktualisieren Sie dann sofort auf Version 6.6.10.21 (6.6.x) oder 6.7.12.2 (6.7.x); der Fix ist bereits ab 6.6.10.18 bzw. 6.7.10.1 enthalten. Das Update läuft über Einstellungen > System > Shopware-Konto > Updates oder via Composer mit composer update shopware/core shopware/platform. Prüfen Sie anschließend alle API-Konten nach dem Least-Privilege-Prinzip.
Wie gefährlich ist diese Sicherheitslücke wirklich?
Die Lücke ist mit einem CVSS-Wert von 6.5 als mittel (Medium) eingestuft und ermöglicht es niedrig privilegierten Nutzern, Bestellzustände zu ändern – etwa Bestellungen als bezahlt oder versendet zu markieren, obwohl ihnen die Rechte fehlen. Es sind bislang keine bestätigten Angriffe in freier Wildbahn bekannt (EPSS-Score nur 0,23 %, nicht in der CISA-KEV-Liste). Dennoch kann die Ausnutzung erhebliche operative Schäden verursachen, etwa in Fulfillment- oder Abrechnungsprozessen.
Wie erkenne ich, ob mein Shop bereits angegriffen wurde?
Prüfen Sie die Datenbanktabelle state_machine_history auf auffällige Statuswechsel, zum Beispiel mit SELECT * FROM state_machine_history WHERE created_at > '2026-01-01' ORDER BY created_at DESC LIMIT 100;. Durchsuchen Sie zudem Ihre Nginx- oder Apache-Logs nach POST-Anfragen an /api/_action/order/*/state/*, die von nicht privilegierten API-Nutzern stammen und mit HTTP-Status 200 beantwortet wurden. Auffällige Änderungen deuten auf eine mögliche Ausnutzung hin.
Was kann ich tun, wenn ich nicht sofort updaten kann?
Als Notbehelf können Sie die betroffenen Routen auf Netzwerkebene absichern, indem Sie den Zugriff auf /api/_action/order/*/state/*, /api/_action/order_transaction/*/state/* und /api/_action/order_delivery/*/state/* nur für vertrauenswürdige Admin-IP-Adressen erlauben (z. B. per Nginx allow/deny-Regel). Dies ist jedoch ausdrücklich nur eine Übergangslösung und kein Ersatz für das eigentliche Update. Führen Sie das Update so schnell wie möglich nach.
Weitere Security-News
Das könnte Sie auch interessieren
Kritische Elementor-Pro-Lücke: Angreifer können WordPress-Seiten komplett übernehmen
Ein Datei-Upload-Bug in Elementor Pro bis 4.2.1 erlaubt RCE ohne Login. Version 4.2.2 schließt die Lücke – jetzt aktualisieren!
Pods-Plugin: Kritische Lücke erlaubt Admin-Übernahme ohne Login
Eine kritische Schwachstelle im WordPress-Plugin Pods lässt Angreifer ohne Login Admin-Passwörter überschreiben. Über 100.000 Sites betroffen.
miniOrange SAML SSO: Kritischer Bypass macht Angreifer zu WordPress-Admins
Zwei kritische Auth-Bypässe im miniOrange SAML SSO Plugin erlauben gefälschte SAML Assertions – bis hin zum vollen Admin-Zugriff.