Die 5 Sicherheitslücken, die fast jeder WooCommerce-Shop hat

Die meisten WooCommerce-Shops sind nicht durch einen genialen Hacker gefährdet, sondern durch fünf langweilige Standard-Fehler. Und anders als bei einem Blog steht hier echtes Geld im Feuer: Ein kompromittierter Shop verliert nicht nur Umsatz, sondern Kundendaten, komplette Bestellhistorien und im schlimmsten Fall Payment-Gateway-Keys — mit DSGVO- und PCI-Folgen.

Die gute Nachricht: Es sind fast immer dieselben fünf Lücken. Hier sind sie — jede mit einem 30-Sekunden-Check und dem Fix.

1. Tote & veraltete Extensions

Das Risiko: Rund 60 % der Shop-Hacks beginnen in einem veralteten Plugin. Bei WooCommerce sitzt die Gefahr selten im Core (gut gewartet), sondern in den Drittanbieter-Erweiterungen — Payment, Versand, Marketing. Auch ein deaktiviertes Plugin liegt mit ausnutzbarem Code auf dem Server.

Check: Plugins-Übersicht → gibt es inaktive oder seit Monaten nicht aktualisierte Erweiterungen?

Fix: Ungenutztes komplett deinstallieren (nicht nur deaktivieren), den Rest auf Auto-Update.

2. Über-berechtigte REST-API-Keys

Das Risiko: WooCommerce stellt Produkte und Bestellungen über die REST-API bereit. Oft existieren alte, vergessene Keys mit Read/Write-Rechten, obwohl ein Tool nur lesen müsste — ein geleakter Key ist dann ein offenes Scheunentor zu Kundendaten.

Check: WooCommerce → Einstellungen → Erweitert → REST-API: alte Keys oder unnötige Schreibrechte?

Fix: Least-Privilege (nur „Read", wo möglich), ungenutzte Keys löschen, ausschließlich über HTTPS, ungenutzte Endpoints sperren.

3. Öffentliche debug.log

Das Risiko: Steht WP_DEBUG_LOG auf einen web-erreichbaren Pfad, landet die debug.log unter deinshop.de/wp-content/debug.log — und die enthält im Shop-Betrieb gern Bestelldaten, Kunden-Mails, Pfade und sogar Gateway-API-Keys.

Check: deinshop.de/wp-content/debug.log im Browser aufrufen — kommt eine Datei?

Fix: WP_DEBUG_LOG aus bzw. das Log außerhalb des Web-Roots schreiben; die Datei per Server-Regel sperren.

4. Offene Datenbank

Das Risiko: Die DB enthält jede Kundenadresse und jede Bestellung (DSGVO/PCI). Ist der MySQL-Port 3306 von außen erreichbar oder steckt noch der Standard-Prefix wp_ drin, sinkt die Hürde für SQL-Injection und Brute-Force drastisch.

Check: Ist Port 3306 von außen offen? Läuft die DB noch unter Prefix wp_?

Fix: DB nur auf localhost binden, Firewall davor, eigenen Tabellen-Prefix + frische Security-Keys/Salts.

5. Kein Admin-Hardening

Das Risiko: CVE-2026-3589 — eine CSRF-Lücke in WooCommerce (5.4.0–10.5.2) erlaubte unautorisierten Angreifern, einen Admin-Account anzulegen. Ohne Updates, 2FA und Login-Rate-Limit ist die Übernahme des Shops (Bestellungen, Rückerstattungen, Auszahlungen, Kundendaten) nur eine Frage der Zeit.

Check: WooCommerce aktuell? 2FA aktiv? Login-Versuche limitiert? XML-RPC noch offen?

Fix: Update auf ≥ 10.5.3, 2FA für alle Admins, Login-Rate-Limit, XML-RPC deaktivieren.

---

Keine dieser Lücken braucht ein teures Security-Plugin — nur 30 Minuten und die richtige Reihenfolge. Aber: Bei einem Shop mit echten Bestellungen ist „später" der falsche Zeitpunkt.

Willst du die nächsten Build-/Audit-Guides — mit allen Stolperfallen? Abonniere den „Built with AI"-Newsletter und verpass keine.

Lieber done-for-you? Wenn ich deinen Shop absichern soll (Audit, Härtung, Migration auf einen eigenen Server, Custom-Plugins & MCP-Connectoren) statt DIY: Schreib mir kurz — das ist mein Tagesgeschäft.