Kurz gesagt: Ist Ihr Onlineshop gehackt oder läuft er auf einer ungepatchten PHP-Version, geht es um drei Dinge zugleich: Kundendaten, den Checkout und Ihren Umsatz. Nehmen Sie den Shop kontrolliert in den Wartungsmodus, sichern Sie Logs ab dem 20.10.2026 und klären Sie, wer PHP auf Ihrem Server aktualisiert und neu startet.
Was in einem Onlineshop auf dem Spiel steht
Ein Shop ist mehr als eine Website. Er verwaltet Kundenkonten mit Passwort-Hashes, Liefer- und Rechnungsadressen, Bestellhistorien, Gutscheine und oft auch Schnittstellen zu Warenwirtschaft, Versanddienstleistern und Marktplätzen. Wer Code auf dem Server ausführen kann, kommt in der Regel an die Datenbank und an die dort hinterlegten API-Schlüssel.
Kartendaten liegen meist nicht bei Ihnen, sondern beim Zahlungsanbieter. Das beruhigt nur zum Teil: Ein Angreifer kann JavaScript in den Bestellprozess einschleusen, das Eingaben im Browser mitliest. Solche Skimming-Skripte fallen im Shopbetrieb kaum auf, weil Bestellungen ganz normal durchlaufen.
Hinzu kommen die Schnittstellen. Ein Shop, der Bestellungen an Warenwirtschaft, Versanddienstleister und Marktplätze übergibt, speichert die Zugangsschlüssel dafür meist in Konfigurationsdateien auf dem Server. Wer sie kopiert, kann im Namen des Händlers Versandlabels erzeugen, Bestände ändern oder Marktplatzkonten missbrauchen.
Typische Shopsysteme und warum PHP2Shell sie trifft
Die verbreiteten Shopsysteme im deutschen Mittelstand laufen auf PHP: Shopware 6, WooCommerce, Magento, OXID, PrestaShop und viele ältere Shopware-5-Installationen. PHP2Shell (CVE-2026-109618 und CVE-2026-109619, je CVSS 9.2) liegt in PHP selbst. Angreifer brauchen kein Kundenkonto und keinen Admin-Zugang.
Für Händler heißt das: Das neueste Shop-Update schützt nicht. Entscheidend ist, ob PHP auf dem Server auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 steht oder der Hoster einen Backport eingespielt hat, und ob danach alle PHP-Prozesse neu gestartet wurden. Bei alten Shops auf PHP 8.1 oder älter gibt es keine offiziellen Updates mehr vom PHP-Projekt. Dann steht neben dem Notfall eine Migration an, die Sie nicht unter Zeitdruck in der Hochsaison erledigen wollen.
Onlineshop gehackt: Was ein Vorfall konkret bedeutet
Ein kompromittierter Shop verursacht Schaden auf mehreren Ebenen, die sich gegenseitig verstärken:
- Umsatz: Jede Stunde Wartungsmodus kostet Bestellungen. Ein Shop, der unbemerkt weiterläuft, kann aber deutlich teurer werden.
- Kundendaten: Abgeflossene Adressen und Bestellungen werden für gezielte Phishing-Mails genutzt, die echt wirken, weil sie echte Bestellungen nennen.
- Sichtbarkeit: Erkennt Google Schadcode, erscheint eine Warnung in den Suchergebnissen. Wie Sie die wieder loswerden, steht im Ratgeber Google-Warnung entfernen.
- Partner: Zahlungsanbieter und Marktplätze haben eigene Vorgaben für Sicherheitsvorfälle. Wer zu spät meldet, riskiert Ärger bei der Abrechnung.
Wer ist zuständig: Agentur, Hoster oder Händler?
In vielen Shops fällt die Frage nach PHP zwischen alle Stühle. Die Agentur hat den Shop gebaut und pflegt Plugins, der Hoster betreibt den Server, und der Händler geht davon aus, dass sich einer der beiden kümmert. Bei Managed Hosting patcht meist der Hoster, bei einem eigenen vServer niemand automatisch.
| Aufgabe | Typischerweise zuständig | Prüfen Sie |
|---|---|---|
| PHP-Paket aktualisieren | Hoster oder Serverbetreuer | Schriftliche Bestätigung mit Paketstand |
| PHP-Prozesse neu starten | wer den Server verwaltet | Zeitpunkt des Neustarts |
| Shop und Plugins | Agentur | Wartungsvertrag und Zugänge |
| Zahlungsanbieter informieren | Händler | Vertragliche Meldepflichten |
Ein PHP-Patch beweist nicht, dass vorher nichts passiert ist. Wurde der Shop zwischen dem 17.10. und dem Patch-Zeitpunkt angegriffen, kann eingeschleuster Code weiterlaufen. Lassen Sie das prüfen, bevor Sie Entwarnung geben.
Die ersten Stunden: Reihenfolge für Händler
- Shop in den Wartungsmodus setzen oder, wenn das nicht geht, vorübergehend vom Netz nehmen.
- Webserver-, PHP- und Shop-Logs ab dem 20.10.2026 sichern, bevor Rotation sie löscht.
- Beim Hoster den PHP-Paketstand und den Neustart schriftlich bestätigen lassen.
- Admin-Passwörter, API-Schlüssel für Zahlung, Versand und Marktplätze sowie Datenbankzugänge erneuern, und zwar erst nach der Bereinigung.
- Checkout, Zahlungs-Plugins und eingebundene Skripte auf Änderungen prüfen.
Liegen Hinweise auf einen Datenabfluss vor, läuft die 72-Stunden-Frist der DSGVO. Die rechtliche Bewertung treffen Sie mit Ihrem Datenschutzbeauftragten und gegebenenfalls Ihrem Anwalt.
Wie hilft PHP SOS konkret?
- Wir prüfen remote den tatsächlichen PHP-Paketstand, die Betriebsart (etwa mod_php oder PHP-FPM) und ob alle Worker neu gestartet wurden.
- Wir untersuchen Shop-Dateien, Datenbank und Checkout auf Webshells, Skimming-Code und neue Admin-Konten und entfernen gefundene Schadsoftware.
- Wir stimmen uns mit Ihrer Agentur und Ihrem Hoster ab, damit Shop-Wartung und Serverbetrieb nicht aneinander vorbeilaufen.
- Wir dokumentieren Befunde und Maßnahmen so, dass Sie sie Zahlungsanbieter, Versicherer und Datenschutzbeauftragtem vorlegen können.
- Danach härten wir den Server und übernehmen auf Wunsch die laufende Überwachung.
Häufige Fragen
Muss ich meinen Shop wegen PHP2Shell vom Netz nehmen?
Das BSI empfiehlt, Webserver vorübergehend vom Netz zu nehmen, wenn das PHP-Update nicht sofort möglich ist. Für einen Shop ist ein Wartungsmodus mit Hinweisseite oft der bessere Weg als eine Fehlermeldung. Sobald PHP gepatcht und alle Prozesse neu gestartet sind, kann der Shop wieder öffnen.
Sind Kreditkartendaten in meinem Shop gefährdet?
In den meisten Shops liegen Kartendaten nicht auf dem eigenen Server, sondern beim Zahlungsanbieter. Gefährlich ist aber manipulierter Code im Checkout, der Eingaben abgreift, bevor sie den Anbieter erreichen. Deshalb gehört der Checkout bei jeder Prüfung nach einem Angriff dazu.
Reicht es, Shopware oder WooCommerce zu aktualisieren?
Nein. PHP2Shell betrifft PHP selbst, nicht das Shopsystem. Ein Shop-Update schließt die Lücke nicht, und ein PHP-Patch entfernt keinen bereits eingeschleusten Schadcode.
Wen muss ich nach einem Datenabfluss informieren?
Bei personenbezogenen Daten kommt die Meldung an die Datenschutzaufsicht innerhalb von 72 Stunden in Betracht, je nach Risiko auch die Information der Betroffenen. Hinzu kommen vertragliche Pflichten gegenüber Zahlungsanbieter und Versicherer. Die Bewertung im Einzelfall treffen Sie mit Datenschutzbeauftragtem und Anwalt.