Shopware-Shop nach dem Security-Update prüfen: Woran du eine Kompromittierung erkennst

1. Was am 25. August tatsächlich geschlossen wurde

Shopware hat an diesem Tag zwei reine Sicherheits-Releases veröffentlicht: 6.7.13.1 und 6.6.10.23. Die Release Notes listen zehn GitHub-Advisories auf; im Abstract darüber ist von neun Schwachstellen die Rede, was eine kleine Unstimmigkeit der Zusammenfassung ist — maßgeblich ist die Liste.

Drei Einträge sind die relevanten. Der schwerste ist ein Ausbruch aus der Sandbox des App-Scriptings: Skripte installierter Apps laufen normalerweise abgeschottet, diese Abschottung ließ sich umgehen, und damit waren beliebige PHP-Funktionen und Betriebssystembefehle ausführbar. Das ist Remote Code Execution, und die Lücke reicht laut Advisory bis Version 6.5.4.0 zurück. Dazu kommt eine Übernahme von Admin-Konten über den Passwort-Reset — ein manipulierter Host-Header lenkt den Link in der Wiederherstellungsmail auf eine fremde Domain — und eine SQL-Injection über Feldnamen von Custom Entities aus App-Manifesten, die bis in die Tabellendefinition durchschlug.

In der Kategorie darunter stehen unter anderem eine SQL-Injection über Aggregationsnamen der Store API, die ohne jede Anmeldung ausnutzbar war, und ein Path Traversal im Medienbereich, bei dem Dateien außerhalb des vorgesehenen Verzeichnisses landen konnten. Die vollständige Liste mit allen Advisories steht in den Security Advisories auf GitHub.

2. Warum der Patch allein keine Entwarnung ist

Die Logik ist unangenehm einfach. Zwischen dem Tag, an dem ein Advisory veröffentlicht wird, und dem Tag, an dem ein einzelner Shop aktualisiert, liegt ein Fenster. In diesem Fenster ist die Lücke öffentlich dokumentiert und der Shop noch verwundbar — das ist erfahrungsgemäß genau der Zeitraum, in dem automatisierte Scans anlaufen. Wer am 26. August aktualisiert hat, hat dieses Fenster praktisch geschlossen. Wer am 5. September aktualisiert hat, hatte es elf Tage lang offen.

Und ein Update stellt keinen vorherigen Zustand wieder her. Wenn in diesem Fenster ein zusätzliches Admin-Konto angelegt, eine Integration mit eigenem Access Key erzeugt oder eine Datei ins Medienverzeichnis geschrieben wurde, ist das nach dem Update immer noch da. Der Patch verhindert nur, dass es noch einmal auf demselben Weg passiert. Deshalb gehört zu einem spät eingespielten Sicherheitsupdate immer ein zweiter Schritt, und der ist Handarbeit.

Ein Hinweis vorweg zur Einordnung: Es gibt Berichte über tatsächlich kompromittierte selbst gehostete Shops im Umfeld dieses Updates. Belastbar bestätigt und im Detail zugeordnet ist das öffentlich bisher nicht. Für die Prüfung unten ändert das nichts — sie kostet eine halbe Stunde und ist unabhängig davon sinnvoll.

3. Schritt 1: Versionsstand und Zeitachse klären

Bevor du suchst, brauchst du zwei Daten: auf welchem Stand der Shop heute ist und wann er dorthin gekommen ist. Der Versionsstand steht in der Administration unter Einstellungen → System → Systeminformationen, im Deployment sauberer über composer show shopware/core. Der Zeitpunkt des Updates ergibt sich aus dem Deployment-Log oder dem Git-Verlauf des Projekts.

Daraus ergibt sich dein Suchfenster: vom 25. August bis zum Update-Zeitpunkt. Alles, was in diesem Zeitraum an sicherheitsrelevanten Objekten entstanden ist, sieht du dir an. Bei einem Shop, der bereits am 25. oder 26. August aktualisiert wurde, ist die Prüfung in fünf Minuten erledigt.

Wenn du noch gar nicht aktualisiert hast: Für die Zweige 6.6 und 6.7 gibt es die genannten Patch-Releases, das sind Patch-Versionen ohne Schnittstellen- oder Template-Änderungen. Für 6.5 existiert zu diesem Bündel kein Patch-Release — dort bleibt das kostenlose Security-Plugin der Weg, das die Fixes in eine bestehende Installation zurückportiert. Es wird für 6.5, 6.6 und 6.7 in je einem eigenen Zweig gepflegt, ist aber ausdrücklich als Überbrückung gedacht und deckt Lücken in Drittanbieter-Bibliotheken wie Symfony oder Twig nicht ab. Wer auf 6.4 oder älter läuft, bekommt auch das nicht mehr — dort ist der Versionssprung die einzige belastbare Antwort.

4. Schritt 2: Admin-Konten und Integrationen

Das ist die erste und wichtigste Anlaufstelle, weil ein zusätzlicher Zugang für einen Angreifer der bequemste Weg ist, den Zugriff über einen Patch hinweg zu behalten. In der Administration findest du die Benutzer unter Einstellungen → System → Benutzer & Rechte, die technischen Zugänge unter Einstellungen → System → Integrationen. Beide Listen gehst du einmal vollständig durch und beantwortest pro Eintrag eine einzige Frage: Weiß ich, wer das ist und warum es existiert?

Direkt in der Datenbank geht es schneller und lückenloser, weil du dort nach Anlagedatum sortieren kannst:

SELECT username, email, admin, created_at, updated_at
FROM user ORDER BY created_at DESC;

SELECT label, admin, created_at, updated_at
FROM integration ORDER BY created_at DESC;

Auffällig ist alles, was im Suchfenster entstanden ist und nicht zu einem bekannten Vorgang gehört. Genauso auffällig: ein bekanntes Konto mit einem updated_at aus diesem Zeitraum, ohne dass jemand daran gearbeitet hat — das kann eine geänderte Mailadresse oder ein gesetztes Admin-Flag sein. Wirf denselben Blick auf acl_role: Eine der geschlossenen Lücken erlaubte es, ACL-Rollen über ungeprüft übernommene Request-Felder zu setzen, also Rechte auszuweiten, ohne ein neues Konto anzulegen.

Ein durchsuchbarer Audit-Trail über alle Admin-Änderungen gehört nicht zum Standardumfang von Shopware; dafür gibt es Erweiterungen im Store. Ohne eine solche Erweiterung sind die Zeitstempel der Entitäten das, was du hast — sie reichen für diese Prüfung aus.

5. Schritt 3: Apps, App-Skripte und Webhooks

Die schwerste Lücke saß im App-System, also sieht man dort besonders genau hin. Unter Einstellungen → System → Erweiterungen beziehungsweise im Extension-Manager gleichst du die Liste der installierten Apps und Plugins mit dem ab, was im Projekt dokumentiert ist. Bei einem Composer-basierten Deployment ist das einfach: Was nicht in der composer.json steht und trotzdem installiert ist, gehört erklärt.

Apps bringen zwei Dinge mit, die über die App selbst hinaus wirken. Erstens Webhooks: Ein Webhook schickt Ereignisse aus dem Shop an eine externe URL, und eine fremde Ziel-URL ist ein Datenabfluss, der beim Blick auf die Extension-Liste leicht übersehen wird. Zweitens Custom Entities aus dem App-Manifest — genau der Weg der SQL/DDL-Injection. Ein Blick in die Datenbank auf Tabellen, die niemand kennt, ist deshalb kein Übermaß an Vorsicht.

Wenn ein Ausbruch aus der App-Sandbox gelungen ist, konnten Betriebssystembefehle laufen. Das heißt: Der Blick bleibt nicht in der Datenbank. Auf dem Server sind veränderte oder neue PHP-Dateien im Projektverzeichnis relevant, insbesondere solche mit einem Änderungsdatum aus dem Suchfenster, sowie neue Einträge in Cronjobs. Bei einem Deployment aus Git ist das angenehm eindeutig: Ein git status auf dem Produktivsystem sollte nichts zeigen, was dort nicht hingehört.

6. Schritt 4: Twig-Vorlagen und das Medienverzeichnis

Diese Stelle ist die unauffälligste, und sie steht so in der offiziellen Security-Referenz von Shopware: Einige Funktionen legen die darunterliegende Technologie bewusst offen. Mail-Templates, SEO-URL-Templates und Produktexport-Templates werden mit Twig gerendert. Wer die entsprechenden Rechte hat, hat damit Zugriff auf die Template-Engine selbst — Shopware weist ausdrücklich darauf hin, dass diese Berechtigungen nur an Personen gehen sollten, die verstehen, was daraus folgt.

Für die Prüfung heißt das: Ein Angreifer mit einem übernommenen Admin-Konto muss keine Datei auf den Server legen, um dauerhaft etwas auszuführen. Es genügt, ein Mail-Template zu bearbeiten. Also sieh dir unter Einstellungen → Shop → E-Mail-Templates die zuletzt geänderten Vorlagen an und prüfe die Produktexporte auf Ziele und Templates, die du nicht angelegt hast.

Das Medienverzeichnis ist der zweite Ort. Der geschlossene Path Traversal konnte Dateien außerhalb des vorgesehenen Verzeichnisses ablegen, im schlechtesten Fall als ausführbaren Code. Suche im Public-Verzeichnis nach allem, was dort inhaltlich nichts zu suchen hat — PHP-Dateien unterhalb von public/media sind das eindeutigste Signal, das es in dieser Prüfung gibt. Unabhängig davon lohnt ein Blick auf die Konfiguration: Shopware validiert URLs beim Medien-Upload standardmäßig über shopware.media.enable_url_validation. Wenn diese Validierung in eurem Projekt irgendwann abgeschaltet wurde, gehört sie zurück auf den Standard.

7. Wenn du fündig wirst — und was danach anders laufen sollte

Bei einem konkreten Fund gilt eine Regel, die man ungern hört: nicht selbst aufräumen und weitermachen. Ein gelöschtes Fremdkonto beseitigt einen Zugang, nicht den Weg dorthin — und es vernichtet gleichzeitig die Spur, mit der sich rekonstruieren ließe, was sonst noch passiert ist. Der richtige Ablauf ist, den Zustand zu sichern (Datenbank und Dateisystem, unverändert), den Hosting-Anbieter einzubinden und erst dann zu bereinigen. Bei Verdacht auf Abfluss personenbezogener Daten kommt zusätzlich die Meldefrist der DSGVO ins Spiel, und da zählen Stunden.

Ohne Fund gibt es trotzdem zwei Aufräumarbeiten, die sich lohnen. Erstens: Admin-Passwörter erneuern und ungenutzte Integrationen abschalten. Shopware invalidiert die Sessions eines Benutzers, sobald dessen Passwort geändert wird — das ist genau der Effekt, den man an dieser Stelle will. Zweitens: die Zuständigkeit klären. In der Praxis scheitern Sicherheitsupdates fast nie an der Technik, sondern daran, dass niemand die Advisories liest. Ein Patch-Release ohne Breaking Changes ist eine Sache von einer Stunde; die zwei Wochen davor sind das eigentliche Risiko.

Wenn du nur eine Sache aus diesem Beitrag mitnimmst, dann diese: Der Zeitpunkt, an dem du deinen Shop aktualisiert hast, ist eine Zahl, die du kennen solltest. Alles andere in dieser Prüfung ergibt sich daraus.