Shopware Security Check: Schwachstellen erkennen und Risiken verstehen

Warum ein Security Check für deinen Shop wichtig ist – gerade jetzt

Mit Vibe Coding lässt sich Software entwickeln, indem man einer KI beschreibt, was sie umsetzen soll. Das eröffnet neue Möglichkeiten. Es bedeutet aber auch: Funktionen können im Shop landen, deren Programmcode niemand ausreichend auf Sicherheit geprüft hat. Dass eine Funktion funktioniert, bedeutet noch nicht, dass sie sicher ist. 

Diese Entwicklung hat eine zweite Seite: KI erleichtert nicht nur die Entwicklung von Software, sondern auch die Suche nach Schwachstellen und die Vorbereitung von Angriffen. Sie kann Programmcode analysieren und dabei helfen, Angriffscode zu erstellen. Dadurch wird nicht automatisch jeder zum erfahrenen Hacker. Aber bestimmte Aufgaben, die früher viel Spezialwissen und Zeit erfordert haben, werden deutlich zugänglicher.

Gleichzeitig steigt der Druck, bekannte Sicherheitslücken schnell zu schließen. Das britische National Cyber Security Centre warnt davor, dass KI die Entdeckung und Ausnutzung von Schwachstellen einfacher, schneller und günstiger macht. Für Betreiber bedeutet das: Weniger Zeit, um auf ein bekannt gewordenes Problem zu reagieren.

Auch bei Shopware gibt es konkrete Sicherheitsrisiken. Im August und September 2026 veröffentlichte Shopware mehrere Sicherheitshinweise, darunter als hoch oder kritisch eingestufte Schwachstellen. Das bedeutet nicht, dass Shopware grundsätzlich unsicher ist. Es zeigt aber, warum die Sicherheit eines Shops regelmäßig überprüft werden sollte.

Wie wichtig dieser Blick auf den gesamten Betrieb ist, zeigen die am 21. Oktober 2026 veröffentlichten PHP2Shell-Sicherheitslücken CVE-2026-109618 und CVE-2026-109619. Sie können es Angreifern ermöglichen, ohne vorherige Anmeldung Schadcode auf einem verwundbaren Server auszuführen. Da Shopware auf PHP basiert, ist das auch für Shopbetreiber relevant: Neben dem Shopware-Stand müssen die eingesetzte PHP-Version und die Serverumgebung geprüft werden. Ob und wie ein System betroffen ist, hängt von der eingesetzten Version und den Betriebsbedingungen ab. Das PHP-Projekt hat Sicherheitsupdates veröffentlicht und fordert zur umgehenden Aktualisierung auf. Die Details stehen im offiziellen PHP-Sicherheitshinweis.

Für einen Security Check ergeben sich daraus zwei Fragen: Ist die Sicherheitslücke geschlossen – und gibt es Hinweise darauf, dass ein Angreifer bereits im System war? Ein Sicherheitsupdate behebt die zugrunde liegende Schwachstelle. Eine zuvor eingeschleuste Schadsoftware oder Hintertür wird dadurch jedoch nicht automatisch entfernt. Deshalb stimmen wir mit dir und deinem Hosting-Anbieter die notwendigen Updates ab und planen zusätzlich die Suche nach Angriffsspuren ein.

Updates bleiben unverzichtbar - sie sind aber nicht die einzige Aufgabe. Auch die Verringerung unnötiger Angriffsmöglichkeiten und das Erkennen verdächtiger Aktivitäten gehören zu einem sicheren Betrieb. Welche Rechte besitzen deine Anbindungen? Ist eine alte Testumgebung noch öffentlich erreichbar? Wurden individuelle Plugins auf Sicherheitsprobleme geprüft? Gibt es bereits verdächtige Veränderungen an Dateien oder in der Datenbank?

Genau hier setzen wir mit einem Security Check an. Gemeinsam mit dir klären wir, welche Risiken für deinen Shop besonders relevant sind und wie tief die Prüfung gehen soll. Ziel ist, frühzeitig zu erkennen, wo im geprüften Umfang Handlungsbedarf besteht, welche Auswirkungen gefundene Schwachstellen haben könnten und welche Maßnahmen sinnvoll sind.

So gehen wir bei einem Security Check vor

Nicht jede Fragestellung erfordert dieselbe Untersuchung. Möchtest du zunächst wissen, ob die Grundlagen stimmen? Gibt es individuelle Erweiterungen, deren Sicherheit geprüft werden soll? Oder möchtest du untersuchen lassen, welche Schwachstellen sich tatsächlich ausnutzen lassen?

Wir gliedern die Untersuchung in vier aufeinander aufbauende Stufen. Welche Stufen wir durchgehen und wie umfangreich wir jeweils prüfen, stimmen wir gemeinsam mit dir ab. Die Stufen geben unserem Vorgehen eine Struktur:

• Stufe 1 – Focus: Sind die grundlegenden Einstellungen und Zugänge sicher eingerichtet?
• Stufe 2 – Insight: Gibt es zusätzlich versteckte Risiken, verdächtige Veränderungen oder Angriffsspuren?
• Stufe 3 – Deep Dive: Entstehen durch individuell entwickelte Plugins zusätzliche Sicherheitslücken?
• Stufe 4 – Pentest: Welche Schwachstellen lassen sich unter den vereinbarten Testbedingungen tatsächlich ausnutzen?

Bevor wir starten: Ziele und Prüfumfang gemeinsam festlegen

Im ersten Gespräch klären wir deine Ausgangslage: Geht es um eine allgemeine Bestandsaufnahme, um bestimmte Eigenentwicklungen oder um konkrete Auffälligkeiten? Daraus leiten wir ab, welche Systeme, Umgebungen und Funktionen wir untersuchen, welche Zugänge wir benötigen und welcher Zeitrahmen sinnvoll ist.

In der Regel beginnen wir mit den Grundlagen und vertiefen die Prüfung bei Bedarf. Die Erkenntnisse einer Stufe fließen in die nächste ein. Nach den vereinbarten Prüfschritten besprechen wir die Ergebnisse mit dir und entscheiden gemeinsam, ob weitere Untersuchungen sinnvoll sind. Eine vertiefende Prüfung erfolgt nach Absprache; nicht jeder Shop benötigt alle vier Stufen.

Die folgenden Beispiele veranschaulichen mögliche Risiken. Es handelt sich nicht um bereits festgestellte Sicherheitslücken in deinem Shop.

Stufe 1 – Focus: Sind die Grundlagen deines Shops sicher eingestellt?

Nicht jedes Sicherheitsproblem beginnt mit einer komplizierten Angriffsmethode. Manchmal reicht ein Zugang mit zu vielen Berechtigungen oder eine Entwicklerfunktion, die versehentlich im laufenden Shop aktiviert geblieben ist.

In der ersten Stufe prüfen wir, ob grundlegende Einstellungen deinen Shop unnötig angreifbar machen. So lässt sich feststellen, wo bereits auf Konfigurationsebene Handlungsbedarf besteht.

Was prüfen wir?

Ein Ausgangspunkt sind die Zugänge und Berechtigungen deines Shops. Welche Benutzer dürfen auf die Verwaltung zugreifen? Welche externen Anwendungen und KI-Anbindungen sind verbunden? Welche Rechte haben diese Zugänge – und passen sie zu ihrer jeweiligen Aufgabe?

Außerdem kontrollieren wir die eingesetzten Softwarestände. Dazu gehören Shopware, das gegebenenfalls eingesetzte Security-Plugin sowie technische Komponenten im Hintergrund, beispielsweise die Datenbank und das Betriebssystem. Welche Komponenten wir einsehen können und wo wir deinen Hosting-Anbieter einbeziehen, klären wir vorab.

Weitere Prüfpunkte sind die Einstellungen für die Verarbeitung von Hintergrundaufgaben sowie Entwickler- und Debug-Funktionen, die nicht unbeabsichtigt im produktiven Shop aktiv sein sollten.

Bei Headless-Shops, deren Oberfläche getrennt vom eigentlichen Shopsystem betrieben wird, betrachten wir zusätzlich, wie Zugangsdaten hinterlegt und verwendet werden.

Beispiel: Eine Anbindung darf mehr als nötig

Eine externe Anwendung soll ausschließlich Lagerbestände aktualisieren. Ihr Zugang besitzt aber vollständige Administratorrechte.

Solange die Anwendung wie vorgesehen arbeitet, fällt diese Berechtigung möglicherweise nicht auf. Werden ihre Zugangsdaten jedoch gestohlen, steht einem Angreifer deutlich mehr offen als die Bestandsverwaltung.

Die mögliche Folge: Er könnte Kundendaten einsehen oder wichtige Shop-Einstellungen verändern. Ein Zugang für eine klar begrenzte Aufgabe wird damit zu einem Risiko für wesentlich größere Teile des Shops.

Mit dieser ersten Stufe untersuchen wir solche unnötig weitreichenden Zugänge und andere problematische Grundeinstellungen. Die Ergebnisse bilden eine Grundlage, um gemeinsam die nächsten Maßnahmen und eine mögliche Vertiefung der Prüfung festzulegen.

Stufe 2 – Insight: Gibt es versteckte Risiken oder Hinweise auf Angriffe?

Eine unauffällige Konfiguration beantwortet noch nicht jede Sicherheitsfrage. Auf dem Server können alte Datenbankkopien liegen. Eine vergessene Testumgebung kann weiterhin erreichbar sein. Dateien könnten verändert worden sein, ohne dass sich das im normalen Shopbetrieb unmittelbar bemerkbar macht.

Wenn wir die Untersuchung gemeinsam auf diese Bereiche ausweiten, suchen wir in der zweiten Stufe nach gefährlichen Altlasten, verdächtigen Veränderungen und Hinweisen auf Angriffe.

Was prüfen wir?

Aufbauend auf der Bestandsaufnahme untersuchen wir weitere öffentlich erreichbare Adressen und Umgebungen rund um deinen Shop. Dazu gehören beispielsweise Testshops auf eigenen Subdomains. Welche Umgebungen einbezogen werden, legen wir mit dir fest.

Wir suchen außerdem nach vorhandenen Datenbankkopien und untersuchen, ob dadurch vertrauliche Informationen gefährdet sein könnten.

Für die Suche nach Hinweisen auf Schadsoftware in Dateien und der Datenbank setzen wir Myleware, unseren auf Shopware ausgelegten Malware-Scanner, ein. Myleware scannt dabei auch gezielt nach sogenannten Webshells. Das sind eingeschleuste Skripte, über die Angreifer aus der Ferne auf den Server zugreifen und dort beispielsweise Dateien verändern oder weiteren Schadcode ausführen können.

Damit kann Myleware Hinweise auf einen bereits kompromittierten Shop sichtbar machen, auch wenn dieser nach außen weiterhin normal funktioniert. Wird eine Webshell erkannt, untersuchen wir den Fund und stimmen mit dir die nächsten Schritte zur Aufklärung und Bereinigung ab. Gerade im Zusammenhang mit PHP2Shell ist diese Prüfung relevant: Eine bereits abgelegte Webshell kann auch nach dem Schließen der ursprünglichen Sicherheitslücke als Hintertür bestehen bleiben.

Ergänzend untersuchen wir die verfügbaren Server-Protokolle – also Aufzeichnungen über Zugriffe und Fehler – auf Hinweise auf Angriffe und gleichen die Ergebnisse mit den Scanner-Funden ab.

Beispiel: Eine Datenbankkopie ist öffentlich erreichbar

Nach einer Wartung bleibt eine Sicherung der Shop-Datenbank auf dem Server liegen. Sie befindet sich versehentlich in einem Verzeichnis, aus dem sie über eine öffentliche Adresse heruntergeladen werden kann.

Die mögliche Folge: Unbefugte könnten je nach Inhalt Kundenadressen, Bestellungen und andere vertrauliche Informationen auslesen. Eine Anmeldung im Shop wäre dafür nicht erforderlich.

Die Sicherung war ursprünglich als Schutzmaßnahme gedacht. Durch ihren Ablageort wird sie selbst zum Sicherheitsrisiko.

Beispiel: Eine Shop-Datei wurde manipuliert

Eine veränderte Datei leitet Besucher unter bestimmten Bedingungen auf eine fremde Website weiter. Beim normalen Durchklicken des Shops tritt die Weiterleitung nicht auf.

Die mögliche Folge: Kunden könnten auf einer betrügerischen Seite landen, ihren Einkauf abbrechen oder das Vertrauen in deinen Shop verlieren. Gleichzeitig sieht der Shop für dein Team weiterhin unauffällig aus.

Diese Stufe erweitert den Blick auf Risiken, die sich nicht allein aus den aktuellen Einstellungen erkennen lassen. Welche Auffälligkeiten weiter untersucht werden sollten und ob individuelle Erweiterungen dabei eine Rolle spielen, besprechen wir anschließend mit dir.

Stufe 3 – Deep Dive: Wie sicher sind deine individuellen Erweiterungen?

Individuelle Plugins machen deinen Shop passend für dein Geschäftsmodell. Sie können besondere Bestellabläufe, Schnittstellen, Kundenfunktionen oder Dokumentenbereiche bereitstellen.

Mit diesen Funktionen entsteht aber auch eigener Programmcode, dessen Sicherheit nicht allein durch die Shopware-Konfiguration oder ein Shopware-Update beurteilt werden kann.

In der dritten Stufe untersuchen wir deshalb gezielt den Programmcode deiner Eigenentwicklungen auf Sicherheitsprobleme. Gemeinsam wählen wir aus, welche Plugins und Funktionen für deinen Shop besonders relevant sind.

Was prüfen wir?

Wir prüfen den Programmcode der vereinbarten individuellen Plugins. Bei der Auswahl berücksichtigen wir beispielsweise, welche Erweiterungen sensible Daten verarbeiten, wichtige Geschäftsabläufe steuern oder von außen erreichbar sind.

Dabei geht es um Sicherheitsprobleme in den Funktionen dieser Erweiterungen: Ermöglicht der Code beispielsweise Zugriffe auf Daten oder Aktionen, die für den jeweiligen Benutzer nicht erlaubt sein sollten?

Prüftiefe und Zeitbedarf richten sich nach Umfang und Komplexität der ausgewählten Erweiterungen. Beides stimmen wir vorab mit dir ab. Zeigt die Untersuchung, dass weitere Funktionen oder Plugins einbezogen werden sollten, besprechen wir den zusätzlichen Aufwand, bevor wir den Prüfumfang erweitern.

Beispiel: Ein Kunde kann fremde Rechnungen abrufen

Ein individuell entwickeltes Plugin stellt Rechnungen im Kundenkonto bereit. Es prüft, ob ein Benutzer angemeldet ist. Allerdings kontrolliert es nicht zuverlässig, ob die angeforderte Rechnung tatsächlich zu diesem Kunden gehört.

Die mögliche Folge: Ein angemeldeter Kunde könnte Rechnungen anderer Kunden einsehen – einschließlich Namen, Adressen, bestellten Produkten und Preisen.

Die Anmeldung funktioniert in diesem Beispiel korrekt. Das Problem liegt in einer zusätzlichen Berechtigungsprüfung, die im individuellen Programmcode fehlt oder fehlerhaft umgesetzt ist.

Deshalb setzen wir in dieser Stufe direkt im individuellen Programmcode an: Korrekte Grundeinstellungen allein beheben keine fehlerhafte Zugriffsprüfung innerhalb einer Eigenentwicklung. Bei gefundenen Schwachstellen besprechen wir mit dir, wie sie behoben werden können und ob ein aktiver Test zusätzliche Erkenntnisse liefern kann.

Stufe 4 – Pentest: Wie weit könnte ein Angreifer tatsächlich kommen?

Eine auffällige Einstellung oder eine mögliche Schwachstelle ist ein wichtiger Befund. Eine weitere Frage lautet jedoch: Lässt sich daraus unter realistischen Testbedingungen tatsächlich ein unerlaubter Zugriff herstellen?

Wenn wir diese vertiefende Prüfung gemeinsam vereinbaren, ergänzen wir die bisherigen Erkenntnisse in der vierten Stufe um einen aktiven Penetrationstest. Dabei betrachten wir deinen Shop aus der Perspektive eines Angreifers und versuchen, Schwachstellen innerhalb des freigegebenen Umfangs kontrolliert auszunutzen.

Was prüfen wir?

Wir untersuchen aktiv, ob sich unerlaubte Zugriffe oder Aktionen erreichen lassen. Dabei berücksichtigen wir unter anderem die OWASP Top 10, eine Übersicht wichtiger Sicherheitsrisiken für Webanwendungen.

Wir betrachten auch, ob mehrere Probleme zusammen einen Angriffsweg ermöglichen. Denn die Auswirkungen einer einzelnen Schwachstelle können sich verändern, wenn sie mit anderen Schwachstellen oder ungünstigen Einstellungen kombiniert wird.

Vor einem solchen Test legen wir gemeinsam fest, welche Zielsysteme geprüft werden dürfen, wann die Tests stattfinden und welche Grenzen gelten. Aktive Tests erfolgen nur mit vorheriger Freigabe und innerhalb dieses vereinbarten Rahmens.

Beispiel: Ein alter Testshop wird zum Zugang zum Live-Shop

Eine ältere Testumgebung lässt sich über eine Sicherheitslücke kompromittieren. Dort befinden sich Zugangsdaten, die auch für den produktiven Shop gültig sind.

Für sich betrachtet wirkt der Testshop möglicherweise wenig relevant: Dort kaufen keine Kunden ein, und aktuelle Bestellungen laufen über ein anderes System.

Die mögliche Folge: Die Testumgebung könnte trotzdem zum Einstiegspunkt in den Live-Shop werden. Dadurch wären nicht nur Testdaten betroffen, sondern möglicherweise auch Kundendaten, Bestellungen und der laufende Verkauf.

Ein aktiver Test kann innerhalb des freigegebenen Umfangs untersuchen, ob dieser Angriffsweg tatsächlich funktioniert. Er liefert damit zusätzliche Erkenntnisse gegenüber der bloßen Feststellung, dass eine alte Testumgebung existiert oder Zugangsdaten mehrfach verwendet werden.

Ob ein Pentest für deinen Shop sinnvoll ist und welche Fragen er beantworten soll, entscheiden wir anhand deiner Ziele und der bisherigen Erkenntnisse gemeinsam.

So bereiten wir die Ergebnisse auf und stimmen die nächsten Schritte ab

Die Ergebnisse der vereinbarten Prüfungen dokumentieren wir in einem Bericht: mit den gefundenen Auffälligkeiten, einer verständlichen Erklärung ihrer möglichen Auswirkungen und Empfehlungen für die Behebung. Dabei halten wir auch fest, welche Bereiche untersucht wurden und welche Fragen offenbleiben.

Du sollst nicht nur erfahren, dass eine Einstellung problematisch ist. Du sollst nachvollziehen können, welches Risiko daraus entsteht und welche Maßnahme dagegen hilft.

Gemeinsam priorisieren wir die Befunde nach Risiko und Handlungsbedarf. Für die empfohlenen Behebungen schätzen wir den Aufwand ein und bündeln zusammengehörige Maßnahmen bei Bedarf. So entsteht eine Grundlage, auf der du die nächsten Schritte planen kannst.

Anschließend stimmen wir ab, welche Maßnahmen wir übernehmen sollen und wo beispielsweise dein Hosting-Anbieter einbezogen werden muss. Prüfen, Beheben und das Kontrollieren der umgesetzten Änderungen sind eigene Arbeitsschritte, deren Umfang wir mit dir festlegen.

Du erhältst damit eine Entscheidungsgrundlage für deinen Shop. Welche Maßnahmen umgesetzt werden und ob weitere Prüfungen folgen, entscheiden wir gemeinsam auf Basis der Ergebnisse.

Was ein Sicherheitscheck leisten kann - und was nicht

Ein Security Check ist eine zeitlich begrenzte Untersuchung im vereinbarten Umfang. Wie tief wir in den einzelnen Stufen prüfen und welche Systeme, Umgebungen und Funktionen einbezogen werden, richtet sich nach deiner Ausgangslage und unseren gemeinsamen Absprachen.

Ein Audit ist eine Bestandsaufnahme zum Prüfzeitpunkt. Es ist keine laufende Überwachung und keine Garantie für vollständige Sicherheit. Auch wenn bei einer Prüfung keine Schwachstelle gefunden wird, beweist das nicht, dass keine vorhanden ist. Nicht geprüfte Bereiche gelten außerdem nicht automatisch als sicher.

Ein Malware-Check und die Untersuchung vorhandener Protokolle ersetzen bei einem bestätigten Angriff auch keine vollständige Aufarbeitung des Sicherheitsvorfalls.

Der Nutzen eines Sicherheitschecks liegt in einer belastbaren Entscheidungsgrundlage: Welche Risiken wurden im geprüften Umfang gefunden, welche Folgen könnten sie haben und welche Schritte sind erforderlich, um sie zu beheben?

Du möchtest die Sicherheit deines Shops prüfen lassen? Meld dich gern bei uns. Gemeinsam besprechen wir deine Ausgangslage und die passenden nächsten Schritte: https://www.8mylez.com/kontakt/