Fehlerhafte Zugriffssteuerung im ilGhera-Supportsystem für WooCommerce (CVE-2025-14033) — Was Site-Besitzer jetzt tun müssen

Eine kürzlich bekannt gewordene Schwachstelle in der fehlerhaften Zugriffssteuerung betrifft das WordPress-Plugin “ilGhera Support System for WooCommerce” (Versionen ≤ 1.3.0). Das Problem ermöglicht es nicht authentifizierten Benutzern, auf sensible Informationen zuzugreifen, da Autorisierungsprüfungen fehlen. Die Schwachstelle wird als CVE­2025­14033 verfolgt und wurde in Version 1.3.1 behoben.

Als Sicherheitsteam von WordPress, das für den Schutz von Tausenden von WooCommerce-Shops verantwortlich ist, haben wir das Problem analysiert und einen praktischen, schrittweisen Leitfaden für Site-Besitzer, Entwickler und Hosting-Anbieter vorbereitet. Dieser Beitrag erklärt das Risiko, wie Angreifer es ausnutzen könnten, wie man versuchte Ausnutzung erkennt, sofortige Milderungsmaßnahmen, die Sie ergreifen können, und langfristige Härtung aus der Perspektive von Administratoren und Entwicklern.

Notiz: Dieser Artikel bietet keinen Exploit-Code oder Anweisungen, die einen Missbrauch ermöglichen würden. Das Ziel ist es, Ihnen zu helfen, Ihre Site schnell und verantwortungsbewusst zu schützen.

Zusammenfassung

• Betroffenes Plugin: ilGhera Support System for WooCommerce (Plugin-Slug: wc-support-system)
• Verwundbare Versionen: ≤ 1.3.0
• Gepatchte Version: 1.3.1
• CVE: CVE­2025­14033
• Problem: Fehlerhafte Zugriffssteuerung — fehlende Autorisierungs-/Nonce-Prüfungen in einem oder mehreren Endpunkten/Funktionen, die sensible Daten zurückgeben
• CVSS: 5.3 (Mittel / Niedrig, abhängig vom Kontext der Site)
• Erforderliches Privileg zum Auslösen: Nicht authentifiziert (öffentlich)
• Primäre Auswirkung: Offenlegung sensibler Informationen (Kunden-/Support-Ticket-Daten, potenziell Bestell- oder Benutzerdaten) — Risiko für Privatsphäre, Compliance und Vertrauen
• Sofortige Maßnahme: Plugin auf 1.3.1 oder höher aktualisieren. Wenn Sie nicht sofort aktualisieren können, wenden Sie die unten beschriebenen Milderungsmaßnahmen an (WAF-virtuelles Patchen, Zugriff einschränken, Plugin deaktivieren, wenn nicht benötigt).

Warum das für WooCommerce-Seiten wichtig ist

Unterstützungssysteme, die in E-Commerce-Shops eingebettet sind, verarbeiten oft Kundennamen, E-Mails, Bestell-IDs, private Nachrichten und andere PII. Ein Fehler in der Zugriffssteuerung, der nicht authentifizierten Anfragen erlaubt, solche Daten abzurufen, kann zu führen:

• Datenschutzverletzungen und GDPR/CCPA-Exposition.
• Kontenumeration und gezielte soziale Ingenieurkunst.
• Datenaggregation für größere Kampagnen gegen Shops.
• Sekundäre Angriffe (Credential Stuffing, Phishing) unter Verwendung von geleakten Informationen.

Selbst wenn die Schwachstelle von einem Bewertungssystem als “niedrig/mittel” eingestuft wird, kann die tatsächliche geschäftliche Auswirkung erheblich sein, abhängig davon, welche Daten offengelegt werden und wie viele Informationen zugänglich sind.

Wie sich die Schwachstelle verhält (hoch­gradig, nicht ausnutzbar)

Sicherheitsforscher entdeckten, dass das Plugin einen Endpunkt oder eine Funktion offenlegt, die Daten des Support-Systems zurückgibt, ohne zu überprüfen, ob der Anforderer autorisiert ist. Typische Ursachen sind:

• Fehlende Berechtigungsprüfungen: Der Code lässt current_user_can() oder äquivalente Berechtigungsprüfungen weg.
• Fehlende Authentifizierungsanforderungen: Der Endpunkt ist für nicht authentifizierte Anfragen zugänglich.
• Keine Nonce-Überprüfung: Entwickler haben wp_nonce oder ein ähnliches Anti-CSRF-Token nicht gefordert/validiert.
• Übermäßig permissive REST-Endpunkte: REST-Routen wurden ohne ordnungsgemäßen ‘permission_callback’ registriert.

Wenn ein Endpunkt keine Autorisierung hat, kann ein Angreifer ihn abfragen und Informationen erhalten, die nur für authentifizierte Mitarbeiter oder Site-Administratoren sichtbar sein sollten.

Risikoabschätzung und Ausnutzbarkeit

• Komplexität: Niedrig — der Angreifer benötigt keine Authentifizierung.
• Erforderliche Berechtigung: Keine (nicht authentifiziert).
• Umfang: Offenlegung sensibler Informationen — die Schwere hängt von der Art und Menge der zurückgegebenen Daten ab.
• Wahrscheinlichkeit der Ausnutzung: Hoch für nicht gepatchte, internet­gerichtete Shops, da diese Probleme häufig automatisiert und in großem Maßstab gescannt werden.

Obwohl der offizielle CVSS-Score bei etwa 5,3 liegt, kann der Kontext eines E-Commerce-Shops (PII, Bestellungen, Kunden-E-Mails) die Auswirkungen in der realen Welt erhöhen. Behandeln Sie dies als Priorität für WooCommerce-Seiten oder jede Seite, die das Plugin verwendet.

Sofortige Maßnahmen für Seiteninhaber (Schritt-für-Schritt)

1. Aktualisieren Sie das Plugin.
   – Der Anbieter hat Version 1.3.1 veröffentlicht, die die fehlerhafte Zugriffskontrolle behebt. Aktualisieren Sie sofort über das WordPress-Admin-Panel (Plugins → Installierte Plugins → Aktualisieren) oder Ihren bevorzugten Verwaltungsworkflow.
   – Wenn Sie viele Seiten verwalten, planen Sie ein Massenupdate und überwachen Sie die Aktualisierungsprotokolle.
2. Wenn Sie nicht sofort aktualisieren können — vorübergehende Minderung
   – Wenden Sie WAF / virtuelle Patch-Regeln an, um die anfälligen Endpunkte zu blockieren (Beispiele siehe unten).
   – Beschränken Sie den öffentlichen Zugriff auf Plugin-Pfade nach IP oder HTTP-Auth, wo möglich (siehe .htaccess/nginx-Beispiele unten).
   – Deaktivieren Sie das Plugin vorübergehend, wenn es nicht unbedingt erforderlich ist, die Funktionalität zu speichern.
   – Begrenzen Sie andere Plugins oder benutzerdefinierten Code, die den anfälligen Endpunkt von der Benutzeroberfläche aus aufrufen könnten.
3. Protokolle und Benutzer überprüfen
   – Überprüfen Sie die Webserver- und WordPress-Protokolle auf verdächtige Anfragen an Plugin-Endpunkte (suchen Sie nach ungewöhnlichen GET/POST-Anfragen im Verzeichnis des Support-System-Plugins).
   – Achten Sie auf Spitzen in den Zugriffs Mustern oder Anfragen, die 200 für Ressourcen zurückgeben, die eingeschränkt sein sollten.
   – Überprüfen Sie kürzlich erstellte Benutzerkonten und fehlgeschlagene Anmeldeversuche.
4. Ändern oder rotieren Sie Geheimnisse
   – Wenn das Support-System mit externen APIs oder Tokens integriert ist, rotieren Sie diese, wenn Sie Missbrauch vermuten.
   – Erwägen Sie, die Admin-Passwörter für kompromittierte oder verdächtige Konten zurückzusetzen.
5. Benachrichtigen Sie Ihre Kunden (wenn Daten offengelegt wurden)
   – Wenn Sie feststellen, dass Daten offengelegt wurden, befolgen Sie die Benachrichtigungspflichten bei Datenpannen in Ihrer Region und informieren Sie betroffene Kunden transparent.

Anzeichen von Ausnutzung erkennen

Suchen Sie nach den folgenden Indikatoren in den Zugriffsprotokollen und WordPress-Protokollen:

• Anfragen an Plugin-Endpunkte wie:
  • /wp-content/plugins/wc-support-system/*
  • /wp-json/wc-support-system/*
• Unauthentifizierte Anfragen, die 200 OK mit JSON-Nutzlasten erhalten, die Benutzernamen, E-Mail-Adressen, Bestell-IDs, Ticketinhalte oder andere PII enthalten.
• Übermäßige oder automatisierte Anfragen von einer kleinen Gruppe von IPs, die auf Support-Endpunkte abzielen.
• Anfragen, die gängige Fuzzing-Muster verwenden (z. B. ?id=*, ?ticket_id=*, usw.) gegen Support-URLs.

Beispiel grep in Serverprotokollen (Pfad und Dateinamen nach Bedarf ersetzen):

grep -i "wc-support-system" /var/log/nginx/access.log | tail -200

Oder suchen Sie nach JSON-Antworten, die E-Mail-Adressen enthalten:

grep -Eio "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}\b" /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Wenn Sie verdächtige Aktivitäten feststellen, bewahren Sie Protokolle auf und erstellen Sie ein Backup, bevor Sie Änderungen vornehmen.

Praktische WAF / virtuelle Patch-Regeln (Beispiele)

Wenn Sie nicht sofort aktualisieren können, fügen Sie WAF-Regeln hinzu, um den Zugriff auf die Endpunkte des anfälligen Plugins zu blockieren oder zu drosseln. Hier sind allgemeine Muster, die Sie verwenden können. Diese sind als Richtlinienbeispiele geschrieben – passen Sie sie an Ihre WAF-Syntax (ModSecurity, NGINX, Cloud WAF oder Ihr WP-Firewall-Management-Panel) an.

Wichtig: Blockieren Sie NICHT legitime Admin-/Service-Anfragen. Testen Sie die Regeln zuerst im Erkennungsmodus.

Beispielregeln im ModSecurity-Stil (konzeptionell):

# Blockieren Sie den direkten Zugriff auf die PHP-Endpunkte des Plugins von Nicht-Administratoren"

# Blockieren Sie REST-Routen, die vom Plugin registriert wurden

# Drosseln Sie hochfrequente Anfragen an die Support-Endpunkte

.NGINX-Beispiel zum Blockieren nach Standort (nur verwenden, wenn es für Ihre Konfiguration sicher ist):

location ~* /wp-content/plugins/wc-support-system/ {

.htaccess-Ausschnitt, um den öffentlichen Zugriff auf den Plugin-Ordner zu verweigern (Apache):

• # Schützen Sie die Dateien des ilGhera Support System Plugins.
• Diese Beispiele sind Vorlagen. Wenn Sie eine verwaltete WAF oder ein Sicherheitsplugin verwenden, erstellen Sie eine Regel, um:.
• Unauthentifizierte Aufrufe an die REST-Endpunkte des Plugins zu blockieren.

Zu verlangen, dass Anfragen an die Support-Endpunkte von authentifizierten Admin-Sitzungen stammen oder durch Referer/Nonce eingeschränkt sind.

Ratenlimits festzulegen und verdächtige Benutzeragenten oder IPs zu blockieren, die diese URLs missbrauchen.

1. Entwickler-Remediation-Checkliste (für Plugin-Autoren und Integratoren)
   Wenn Sie benutzerdefinierte Plugins pflegen oder mit dem Support-Plugin integrieren, bestätigen Sie die folgende Code-Hygiene:
       Berechtigungsprüfungen.
       – Jeder Endpunkt, der sensible Daten zurückgibt, muss die Fähigkeit des anfordernden Benutzers validieren:.
2. Authentifizierung und Nonce-Überprüfung
   – Authentifizierung für Endpunkte, die PII bereitstellen, erforderlich machen.
   – Bei Front-End-Formularen einen wp_verify_nonce() Wert validieren, bevor sensible Inhalte zurückgegeben werden.
3. Prinzip der geringsten Privilegierung
   – Die minimal erforderlichen Daten für die Anfrage zurückgeben.
   – Vermeiden, vollständige Benutzeraufzeichnungen zurückzugeben, wenn teilweise Details ausreichen würden.
4. Sichere REST-Registrierungen
   – Beim Registrieren von REST-Routen (register_rest_route) immer einen permission_callback definieren, der Berechtigungsprüfungen durchsetzt und bei Fehlern WP_Error zurückgibt.
5. Ausgabe-Sanitierung
   – Alle Ausgaben sanitieren und escapen, selbst für authentifizierte Benutzer; vermeiden, Serverpfade, Debug-Infos oder Stack-Traces preiszugeben.
6. Protokollierung und Fehler
   – Keine ausführlichen Fehlermeldungen zurückgeben, die Informationen an nicht authentifizierte Aufrufer offenbaren. Fehler serverseitig für Diagnosen protokollieren.
7. Automatisierte Tests und Code-Überprüfung
   – Fügen Sie Unit-/Integrationstests hinzu, die bestätigen, dass unautorisierte Anfragen 401/403 erhalten und nicht auf sensible Payloads zugreifen können.
   – Sicherheitsfokussierte Code-Überprüfungen für Routen und AJAX-Callbacks implementieren.

Wenn Sie ein Entwickler des ilGhera-Plugins sind oder auf es in benutzerdefinierten Integrationen angewiesen sind, wenden Sie diese Muster an, um sicherzustellen, dass es keine Regression gibt und dass neue Funktionen keine ähnlichen Probleme einführen.

Vorfallreaktion: Wenn Sie einen Verstoß vermuten

1. Enthalten:
   – Plugin sofort auf 1.3.1 aktualisieren.
   – WAF-Regeln anwenden oder das Plugin vorübergehend deaktivieren.
   – Alle mit dem Support-System verbundenen API-Schlüssel oder Tokens rotieren.
2. Beweise sichern:
   – Protokolle (Webserver-, Anwendungs-, Datenbankprotokolle) sicher für forensische Analysen archivieren.
   – Protokolle nicht überschreiben oder kürzen.
3. Bewerten Sie:
   – Bestimmen, welche Daten möglicherweise offengelegt wurden (Benutzermails, Ticketinhalte, Bestell-IDs).
   – Identifizieren Sie betroffene Kunden und den Zeitrahmen.
4. Genesen:
   – Stellen Sie kompromittierte Konten wieder her oder setzen Sie die Anmeldeinformationen nach Bedarf zurück.
   – Bereinigen Sie Malware, falls diese als sekundäre Maßnahme installiert wurde.
5. Benachrichtigen:
   – Benachrichtigen Sie betroffene Benutzer und Aufsichtsbehörden gemäß den geltenden Gesetzen.
   – Geben Sie den Kunden Anleitungen (z. B. Passwort ändern, verdächtige Nachrichten ignorieren).
6. Nach dem Vorfall:
   – Prozesse härten: regelmäßige Plugin-Prüfungen, kontinuierliches WAF-Tuning und geplante Sicherheitsüberprüfungen.
   – Ziehen Sie Penetrationstests kritischer Plugins und benutzerdefinierter Codes in Betracht.

Wie WP-Firewall Sie schützt (unser Ansatz erklärt)

Bei WP-Firewall betrachten wir gebrochene Zugriffskontrollen als einen der häufigsten Fehler von Entwicklern: Eine kleine Auslassung in einem Berechtigungs-Callback kann übergroße Auswirkungen haben. Unser Schutzansatz konzentriert sich auf mehrschichtige Verteidigungen:

• Verwaltetes WAF mit virtueller Patchung: Wir erstellen Regelsets, um neu offengelegte Schwachstellen (einschließlich fehlender Autorisierungsprobleme) abzudecken und wenden sie innerhalb von Minuten auf geschützte Seiten an – und blockieren Exploit-Versuche, bevor ein Update installiert wird.
• Verhaltensbasierte Erkennung: Wir verfolgen ungewöhnliche Anfrage-Muster und begrenzen oder blockieren automatisierte Scanner, die versuchen, verwundbare Endpunkte zu entdecken.
• Automatisierte Überwachung und Warnungen: Wir überwachen Endpunkte auf Anomalien und bieten umsetzbare Warnungen in unserem Dashboard.
• Malware-Scans und -Behebung: Wir scannen nach Artefakten der Ausbeutung und bieten eine Entfernung an, wo dies möglich ist.
• Wiederherstellung und Berichterstattung: Wenn ein Kompromiss festgestellt wird, helfen wir, ihn einzudämmen, zu bereinigen und nach Bedarf zu berichten.

Unsere Philosophie: Wenn Entwickler Fehler machen (und das werden sie), sollte ein effektives WAF und eine Sicherheitsstrategie verhindern, dass diese Fehler zu Kompromissen werden.

Beispiel WAF-Signaturlogik erklärt (was wir blockieren und warum)

Wenn ein Plugin einen verwundbaren Endpunkt offenlegt, umfassen gängige automatisierte Exploit-Muster:

• Hochvolumige Anfragen an denselben Endpunkt, oft mit ID-Enumerierung.
• Anfragen, die Abfrageparameter enthalten, die für Ticket-Systeme typisch sind: ticket_id, message_id, order_hash usw.
• Anfragen von Benutzeragenten, die von Scannern verwendet werden oder bekannte Bot-Strings enthalten.

Eine sinnvolle Signatur wird:

• Anfragen an bekannte anfällige Endpunkte blockieren, es sei denn, die Anfrage ist authentifiziert und der Benutzer hat die entsprechenden Berechtigungen.
• Verdächtige Clients mit CAPTCHA/JS-Herausforderung drosseln oder herausfordern.
• Protokollieren und benachrichtigen, wenn eine blockierte Anfrage beobachtet wird, einschließlich der betreffenden IP, des Benutzeragenten und der Anfrage-Payload.

Dieser Ansatz verhindert Massenexploitationen und minimiert gleichzeitig Fehlalarme für legitimen Admin-Verkehr.

Empfohlene langfristige Basissicherheit für WooCommerce-Seiten

1. Halten Sie Kern, Plugins und Themes aktualisiert. Verwenden Sie eine Test-/Staging-Umgebung, um Updates vor der Produktion zu validieren.
2. Durchsetzen des geringsten Privilegs: Erstellen Sie Mitarbeiterrollen mit nur den notwendigen Berechtigungen.
3. Verwenden Sie eine verwaltete WAF mit virtueller Patch-Funktion, damit Sie Websites sofort nach öffentlichen Bekanntmachungen schützen können.
4. Implementieren Sie starke Zugriffskontrollen für Admin-Bereiche (2FA, IP-Einschränkungen, robuste Passwörter).
5. Konfigurieren Sie Protokollierung und regelmäßige Überprüfung: Zugriffsprotokolle, WordPress-Aktivitätsprotokolle und Datenbank-Auditprotokolle.
6. Backups: Halten Sie verschlüsselte, externe Backups mit regelmäßigen Wiederherstellungstests.
7. Regelmäßige Sicherheitsüberprüfungen und automatisierte Schwachstellenscans.
8. Schulen Sie Teammitglieder über Phishing und Social Engineering.

Diese Maßnahmen verringern die Wahrscheinlichkeit, dass eine einzelne Plugin-Schwachstelle zu einem schweren Verstoß führt.

Validierung und Tests nach der Anwendung von Korrekturen

• Testen Sie die Plugin-Funktionalität von einem Administratorkonto und von einem nicht privilegierten Konto, um das korrekte Verhalten und die ordnungsgemäße Funktion der Autorisierungsprüfungen sicherzustellen.
• Überprüfen Sie, ob zuvor anfällige Endpunkte jetzt 401/403 für nicht authentifizierte Anfragen zurückgeben.
• Wenn Sie WAF-Regeln implementiert haben, verschieben Sie diese von der Erkennung zum Blockieren, nachdem Sie überprüft haben, dass sie legitime Admin-Anfragen nicht blockieren.
• Überwachen Sie die Protokolle auf wiederholte Versuche gegen die Endpunkte für mehrere Tage nach dem Patch.

FAQ (schnelle Antworten)

Q: Ist meine Seite definitiv kompromittiert, wenn ich das Plugin verwendet habe?

A: Nicht unbedingt. Die Exposition gegenüber einer Schwachstelle bedeutet nicht, dass eine Ausnutzung stattgefunden hat. Überprüfen Sie die Protokolle und die oben beschriebenen Indikatoren. Wenn Sie Anzeichen für verdächtigen Zugriff finden, folgen Sie der Checkliste für die Reaktion auf Vorfälle.

Q: Sollte ich das Plugin entfernen?

A: Wenn das Plugin nicht essenziell ist, ist die Entfernung ein sicherer Ansatz. Wenn Sie das Plugin benötigen, aktualisieren Sie auf 1.3.1 und härten Sie es mit WAF-Regeln und Least-Privilege-Kontrollen ab.

Q: Kann ein WAF das Aktualisieren des Plugins vollständig ersetzen?

A: Nein – das Aktualisieren ist die richtige Lösung. Eine WAF bietet sofortigen temporären Schutz (virtuelles Patchen) und reduziert das Risiko, bis ein vollständiger Patch angewendet wird.

Verantwortliche Offenlegung Anerkennung

Das Problem wurde verantwortungsvoll von Sicherheitsforschern (Anerkennung an den im Disclosure genannten Forscher) gemeldet und vom Plugin-Autor in einem zeitnahen Update behoben. Vielen Dank an die Forscher-Community für die Identifizierung und Meldung dieser Art von Problemen – koordinierte Offenlegung und Patchen sind entscheidend für die Sicherheit des Ökosystems.

Beginnen Sie mit kostenlosem verwaltetem Schutz für Ihre WooCommerce-Seite

Wenn Sie sofortigen, verwalteten Schutz wünschen, während Sie Plugins aktualisieren und testen, ziehen Sie unseren kostenlosen Schutzplan in Betracht. Er umfasst eine essentielle verwaltete Firewall, website­basierte WAF-Regeln, unbegrenzte Bandbreite, einen Malware-Scanner und Maßnahmen gegen die OWASP Top 10 – genug, um viele Geschäfte gegen automatisierte Angriffe und häufige Plugin-Fehler zu schützen.

• Basisversion (kostenlos): Verwaltete Firewall, unbegrenzte Bandbreite, WAF, Malware-Scanner, OWASP Top 10 Maßnahmen.
• Standard ($50/Jahr): Basic plus automatische Malware-Entfernung und die Möglichkeit, bis zu 20 IPs auf die schwarze oder weiße Liste zu setzen.
• Pro ($299/Jahr): Standard plus monatliche Sicherheitsberichte, automatisches virtuelles Patchen von Schwachstellen und Zugang zu Premium-Add-ons wie einem dedizierten Kontomanager und verwalteten Sicherheitsdiensten.

Starten Sie jetzt Ihren kostenlosen Plan und erhalten Sie eine zusätzliche Schicht des virtuellen Patchens, während Sie aktualisieren: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Sie können später upgraden, um automatisierte Behebungen und monatliche Berichte zu erhalten, wenn Sie mehrere Geschäfte verwalten.)

Schlussgedanken

Fehlende Zugriffskontrolle ist eine wiederkehrende Grundursache für viele WordPress-Datenexpositionen. Für E-Commerce-Shops sind die Einsätze höher, da Kundendaten sensibel sind und Vertrauen von größter Bedeutung ist. Die Schwachstelle im ilGhera Support System für WooCommerce unterstreicht die Bedeutung von:

• Schnellen Updates,
• Geschichteter Verteidigung mit einer verwalteten WAF und Überwachung,
• Best Practices für Entwickler (Berechtigungsprüfungen, Nonces, Least Privilege),
• Ein solider Prozess zur Reaktion auf Vorfälle.

Wenn Sie sich über das Patchen, die Erkennung unsicher sind oder Hilfe bei der Umsetzung der oben genannten Maßnahmen benötigen, wenden Sie sich an einen vertrauenswürdigen Sicherheitspartner oder Ihren Hosting-Anbieter. Schnelles, verantwortungsvolles Handeln ist die beste Verteidigung gegen automatisierte Ausnutzung in der Wildnis.

Anhang: Schnellcheckliste für Website-Besitzer (kopieren­einfügen)

• Aktualisieren Sie das ilGhera Support System für das WooCommerce-Plugin auf 1.3.1.
• Wenn ein sofortiges Update nicht möglich ist: WAF-Regel(n) anwenden, um Plugin-Endpunkte zu blockieren.
• Beschränken Sie den Zugriff auf den Plugin-Ordner über die Serverkonfiguration, wenn möglich.
• Durchsuchen Sie die Protokolle nach /wc-support-system/ oder verdächtigen 200-Antworten, die PII zurückgeben.
• Ändern/rotieren Sie alle externen API-Token, die mit dem Plugin verbunden sind.
• Ziehen Sie in Betracht, das Plugin vorübergehend zu deaktivieren, wenn es nicht kritisch ist.
• Melden Sie sich für eine verwaltete Firewall mit virtuellem Patchen an, um bis zum Abschluss des Patchens zu schützen.

Wenn Sie Hilfe bei der Umsetzung einer der oben genannten Maßnahmen (WAF-Regeln, Überwachung oder Vorfallreaktion) benötigen, steht Ihnen unser Support-Team zur Verfügung, um Ihren WooCommerce-Shop zu schützen.