| Plugin-Name | WordPress Visualizer-Plugin |
|---|---|
| Art der Schwachstelle | XSS |
| CVE-Nummer | CVE-2026-24573 |
| Dringlichkeit | Niedrig |
| CVE-Veröffentlichungsdatum | 2026-05-20 |
| Quell-URL | CVE-2026-24573 |
CVE-2026-24573: Was WordPress-Seitenbesitzer jetzt tun müssen — Visualizer Plugin (< 4.0.0) XSS erklärt und eingegrenzt
Eine Cross-Site Scripting (XSS) Schwachstelle wurde offengelegt, die WordPress-Seiten betrifft, die das Visualizer-Plugin (Versionen vor 4.0.0) verwenden. Das Problem wurde als CVE-2026-24573 verfolgt. Als WordPress-Sicherheitsteam, das eine verwaltete Web Application Firewall (WAF) betreibt, möchten wir Ihnen eine praktische, fachkundige Anleitung geben: was diese Schwachstelle ist, warum sie wichtig ist, wie Angreifer sie ausnutzen könnten und wie Sie Ihre Seiten sofort und langfristig schützen können.
Dieser Beitrag ist für Seitenbesitzer, Entwickler und Agenturen geschrieben, die WordPress betreiben und klare, umsetzbare Anleitungen wünschen. Kein Marketing-Geschwätz — nur praxisnahe, technische Anleitungen von Menschen, die täglich WordPress-Schwachstellen verwalten und mindern.
Zusammenfassung — die Überschrift
- Schwachstelle: Cross-Site Scripting (XSS) im WordPress Visualizer-Plugin, das Versionen vor 4.0.0 betrifft.
- CVE: CVE-2026-24573.
- Auswirkungen: Ein Angreifer kann JavaScript injizieren, das im Browser eines authentifizierten Benutzers ausgeführt wird (in diesem Fall wird berichtet, dass ein Benutzer mit der Rolle Contributor oder höher für die erste Aktion erforderlich ist). Erfolgreiche Ausnutzung erfordert Benutzerinteraktion (Klicken auf eine gestaltete URL, Besuch einer vom Angreifer kontrollierten Seite, Einreichen eines gestalteten Formulars).
- Schweregrad: Mäßig (CVSS 6.5 wurde zugewiesen); das tatsächliche Risiko hängt jedoch davon ab, welche Benutzerkonten existieren und wie sie verwendet werden.
- Sofortige Minderung: Aktualisieren Sie auf Visualizer 4.0.0 oder höher. Wenn Sie nicht sofort aktualisieren können, implementieren Sie virtuelles Patchen über eine WAF, deaktivieren Sie das Plugin oder beschränken Sie den Zugriff auf Plugin-Bildschirme und Upload-Pfade.
- Erkennung: Suchen Sie nach unerwarteten Skript-Tags oder base64-codierten Payloads in Diagrammdaten, Uploads oder temporären Optionen; scannen Sie Protokolle nach verdächtigen Anfragen im Admin-Bereich und neuen Inhalten, die -Tags oder verdächtige on*-Attribute (onclick, onload) enthalten.
Was genau ist XSS und warum diese spezifische Schwachstelle wichtig ist
Cross-Site Scripting (XSS) tritt auf, wenn eine Anwendung nicht vertrauenswürdige Eingaben in eine Seite einfügt, ohne sie ordnungsgemäß für den Browserkontext zu bereinigen oder zu kodieren. Der Angreifer liefert JavaScript (oder anderes HTML), das der Browser des Opfers ausführt. Die Folgen sind Sitzungsdiebstahl, unbefugte Aktionen im Namen des Opfers, Verunstaltung und die Einspeisung von persistentem bösartigem Inhalt.
Diese Visualizer-Schwachstelle ist ein gespeicherter XSS-Vektor innerhalb von pluginverwaltetem Inhalt. Gespeichertes XSS ist besonders gefährlich, da die bösartige Payload auf der Seite bleibt und ausgeführt werden kann, wann immer eine betroffene Seite oder ein Admin-Bildschirm von einem authentifizierten Benutzer angesehen wird. In diesem Fall erfordert die Schwachstelle eine anfängliche Interaktion durch einen privilegierten Benutzer (Rolle Contributor oder höher), kann jedoch breitere Auswirkungen haben, wenn ein Admin eine infizierte Seite ansieht oder wenn das bösartige Skript gegen weniger privilegierte Besucher agiert.
Selbst wenn die anfängliche Berechtigungsanforderung die Exposition zu begrenzen scheint, haben viele WordPress-Seiten mehrere Mitwirkende, Redakteure oder Administratoren — einige könnten ausgelagert sein, ihre Konten selten überprüfen oder wiederverwendete Anmeldeinformationen haben. Angreifer führen automatisierte Kampagnen durch, die schnell von selbst begrenzten Vektoren profitieren können.
Wie ein Angreifer die Schwachstelle nutzen könnte — praktische Angriffszenarien
- Persistentes (gespeichertes) XSS in Diagrammdaten
- Ein bösartiger Mitwirkender lädt Diagrammdaten hoch oder bearbeitet sie, die eingebettete Skript-Tags oder Ereignis-Handler enthalten.
- Das Plugin speichert diese Diagrammdaten, und wenn ein anderer Benutzer (Redakteur/Admin) oder möglicherweise ein nicht authentifizierter Besucher die Diagrammseite ansieht, wird das bösartige JavaScript ausgeführt.
- Ergebnis: Angreifer können Admin-Cookies erfassen, Aktionen über die Browsersitzung des Administrators ausführen oder weitere Hintertüren installieren.
- Phishing und Privilegieneskalation
- Der Angreifer erstellt Links oder Inhalte im Admin-Bereich, die einen Administrator dazu bringen, eine Aktion zu bestätigen (z. B. Optionen ändern oder ein Plugin installieren), während das Skript im Kontext des Administrators ausgeführt wird.
- Laterale Bewegung
- Sobald der Angreifer die Kontrolle über die Admin-Sitzung hat, kann er Dateien ändern, Backdoor-PHP-Dateien erstellen, neue Admin-Konten anlegen oder sensible Informationen exfiltrieren.
- Rufschädigung und SEO-Vergiftung
- Eingespritzte Skripte können umleiten, Spam-Links hinzufügen oder bösartige SEO-Inhalte einfügen, die Rankings und das Vertrauen der Benutzer schädigen.
Wer ist gefährdet
- Seiten, die Visualizer-Plugin-Versionen unter 4.0.0 ausführen.
- Seiten mit mehreren privilegierten Konten (Mitwirkender, Autor, Redakteur, Administrator).
- Seiten, die externen Mitwirkenden erlauben, Diagrammdaten hochzuladen oder bereitzustellen, ohne strenge Bereinigung.
- Seiten, die keinen aktiven WAF oder keinen Inhalts-Scan-Prozess haben.
Selbst Seiten mit nur einem Admin-Konto können gefährdet sein, wenn dieses Konto auf anderen Seiten verwendet wird und die Anmeldeinformationen wiederverwendet oder geleakt werden. Die Sicherheitslage aller Benutzer ist wichtig.
Sofortige Maßnahmen (erste 60–90 Minuten)
Dies sind priorisierte, praktische Schritte, die Sie sofort durchführen können. Befolgen Sie sie in der Reihenfolge.
- Aktualisieren Sie das Plugin (beste Option)
- Wenn Sie sicher aktualisieren können, tun Sie dies jetzt. Aktualisieren Sie Visualizer auf Version 4.0.0 oder höher. Bestätigen Sie das Update in einer Testumgebung, wenn möglich; andernfalls aktualisieren Sie während eines Wartungsfensters mit geringem Verkehr und haben Sie Backups bereit.
- Wenn Sie nicht sofort aktualisieren können — begrenzen Sie das Risiko
- Deaktivieren Sie das Visualizer-Plugin vorübergehend.
- Beschränken Sie den Zugriff auf die Visualizer-Admin-Bildschirme mithilfe von IP-Erlauben/Verweigern-Regeln auf Ihrem Server oder WAF-Ebene.
- Deaktivieren Sie die Möglichkeit für nicht vertrauenswürdige Rollen, Diagrammdaten zu bearbeiten oder hochzuladen. Überprüfen Sie die Rollen-/Fähigkeitseinstellungen und entfernen Sie den Bearbeitungszugriff für Mitwirkende (oder niedriger), wenn möglich.
- Aktivieren Sie WAF-virtuelles Patchen / Regeln
- Implementieren Sie WAF-Regeln, die Anfragen blockieren, die verdächtige Payloads enthalten, die auf das Plugin abzielen (siehe Abschnitt unten für Beispiele).
- Blockieren oder bereinigen Sie Anfragen, die rohe -Tags, javascript: URIs oder verdächtige Ereignishandler in Parametern enthalten, die mit Diagrammdatenfeldern korrelieren.
- Benutzerkonten prüfen
- Überprüfen Sie alle Benutzer mit der Rolle Contributor oder höher. Entfernen oder sperren Sie sofort Konten, die veraltet, nicht erforderlich oder verdächtig sind.
- Erzwingen Sie Passwortzurücksetzungen für privilegierte Benutzer, wenn Sie vermuten, dass die Schwachstelle ausgenutzt worden sein könnte.
- Aktivieren oder erzwingen Sie starke Passwörter und Zwei-Faktor-Authentifizierung (2FA) für Admin-/Editor-Konten.
- Snapshot und Protokolle
- Erstellen Sie vollständige Backups (Datenbank + Dateien) für forensische Analysen.
- Sammeln und bewahren Sie Webserver- und WordPress-Protokolle auf. Suchen Sie nach verdächtigen POST-Anfragen an admin-ajax.php, wp-admin/edit.php oder plugin-spezifischen Endpunkten.
- Auf Kompromisse prüfen
- Führen Sie einen vollständigen Malware-Scan durch und suchen Sie nach verdächtigen Dateien oder Codeänderungen (Webroot-PHP-Dateien, Änderungen in wp-content/uploads, unerwartete .php-Dateien in uploads).
- Durchsuchen Sie die Datenbank nach injizierten Skripten oder verdächtigen base64/URL-kodierten Zeichenfolgen in Beiträgen, Optionen oder Plugin-Tabellen.
WAF virtuelle Patches — Muster und empfohlene Regeln
Wenn Sie nicht sofort aktualisieren können, kann eine WAF virtuelle Patches bereitstellen, um Ausnutzungsversuche zu blockieren. Unten stehen praktische, konservative Regeln zur Überlegung. Sie sind konzeptionell ausgedrückt — passen Sie sie an die Syntax Ihres WAF-Produkts an und testen Sie zuerst in der Staging-Umgebung.
Wichtig: Vermeiden Sie das Blockieren legitimer Daten. Passen Sie die Regeln an das normale Verhalten Ihrer Website an.
Vorgeschlagene Erkennungen/Blockierungen:
- Blockieren Sie Anfragen, die wörtliche Skript-Tags oder Ereignis-Handler-Attribute in Feldern enthalten, die Daten und nicht HTML enthalten sollten:
- Vergleichen Sie Parameter, die auf Diagrammdaten abgebildet sind (z. B. data, chart_data usw.) und verweigern Sie, wenn sie <script, , onerror=, onload= oder javascript:. enthalten.
- Blockieren Sie POST-Anfragen mit base64-kodierten Payloads, die an Plugin-Endpunkte gesendet werden, wo base64 unerwartet ist:
- Erkennen Sie lange base64-Zeichenfolgen in Parametern und blockieren oder kennzeichnen Sie sie zur Überprüfung.
- Normalisieren und filtern Sie JSON-Payloads, die über Ajax-Endpunkte für das Plugin eingereicht werden:
- Verweigern Sie, wenn JSON-Felder HTML-Tags enthalten.
- Verhindern Sie reflektierte/Skript-Injektionen in Abfragezeichenfolgen:
- Blockieren Sie Anfragen, bei denen Abfrageparameter <script oder enthalten.
- Den Zugriff auf Admin-Seiten nach IP einschränken oder bei verdächtigen IPs mit Captcha herausfordern.
Beispiel für eine konzeptionelle Regel (Pseudo-Syntax):
# Blockiere POST-Anfragen an Plugin-Endpunkte, die Skript-Tags im chart_data-Parameter enthalten, wenn request.path übereinstimmt mit "/wp-admin/admin-ajax.php|/wp-admin/*visualizer*" UND request.method == POST:
Wende auch allgemeine Schutzmaßnahmen an:
- Erzwinge HTTPOnly und Secure für Cookies.
- Wende eine Content Security Policy (CSP) als Verteidigung in der Tiefe an, um Skriptquellen einzuschränken.
So erkennen Sie, ob Ihre Website ausgenutzt wurde
Eine kurze Checkliste zur Erkennung:
- Suche nach neuen oder modifizierten Beiträgen, Diagrammen oder Optionen, die unerwartete -Tags oder codiertes JavaScript enthalten.
- Durchsuche die Datenbank nach gängigen JS-Angriffs-Mustern: <script, document.cookie, XMLHttpRequest, fetch(, eval(, atob( kombiniert mit verdächtigen Zeichenfolgen.
- Überprüfe den Upload-Ordner auf Dateien mit ungewöhnlichen Erweiterungen oder PHP-Dateien in Uploads.
- Scanne nach neuen Admin-Benutzern oder modifizierten Benutzerrollen.
- Überprüfe die Webserver-Protokolle auf Anfragen an Plugin-Seiten mit ungewöhnlichen Payloads (lange POSTs, base64-Zeichenfolgen).
- Überwache die Browser-Konsole auf Fehler, wenn du oder deine Benutzer die Seite besuchen und auf seltsame Skripte stoßen.
Wenn Sie Beweise für eine Ausnutzung finden:
- Isolieren Sie den Vorfall: Nehmen Sie die Website offline oder versetzen Sie sie in den Wartungsmodus.
- Bewahren Sie Protokolle und Backups zur Untersuchung auf.
- Setze Passwörter und Schlüssel zurück (WordPress-Salze, API-Schlüssel).
- Bereinige die Seite oder stelle sie aus einem sauberen Backup wieder her, das vor dem Kompromiss erstellt wurde.
Checkliste zur Bereinigung — wenn der Kompromiss bestätigt ist
- Bewahre Beweise auf (Protokolle, DB-Dump, Dateisnapshot).
- Nimm die Seite offline oder zeige eine Wartungsseite an.
- Setze alle Admin-/privilegierten Passwörter zurück und widerrufe Sitzungen (WordPress und Hosting-Kontrollpanel).
- Ersetzen Sie die WordPress-Salze in wp-config.php.
- Entferne bösartige Dateien und stelle modifizierte Dateien auf bekannte gute Kopien zurück.
- Überprüfen Sie die geplanten Aufgaben (wp-cron) auf bösartige Jobs.
- Führen Sie eine Datei-Integritätsprüfung über Themes, Plugins und den Kern durch.
- Scannen Sie nach der Bereinigung erneut, um sicherzustellen, dass keine Rückstände vorhanden sind.
- Stellen Sie Updates erneut bereit, einschließlich Visualizer 4.0.0+.
- Aktivieren Sie Benutzer und Dienste schrittweise wieder; überwachen Sie nach der Bereinigung auf Anomalien.
Wenn Sie kein vertrauenswürdiges Backup haben, das älter ist als der Kompromiss, ziehen Sie in Betracht, von Grund auf neu zu erstellen und Inhalte nach sorgfältiger Sanitärung wiederherzustellen.
Entwickleranleitung — wie der Plugin-Autor dies hätte verhindern sollen
Wenn Sie ein Entwickler sind oder für die Wartung von Plugins verantwortlich sind, sind dies die gängigen Best Practices zur Vermeidung von XSS in WordPress-Plugins:
- Sanitärisieren Sie Eingaben auf dem Server:
- Verwenden Sie geeignete Sanitärfunktionen: sanitize_text_field, wp_kses_post, wp_kses für HTML mit erlaubten Tags, intval für Ganzzahlen, esc_attr für HTML-Attribute.
- Entkommen Sie Ausgaben entsprechend dem Kontext:
- Verwenden Sie esc_html() für HTML-Inhalte, esc_attr() für HTML-Attribute, esc_js() für JavaScript-Kontexte, esc_url() für URLs.
- Validieren und beschränken Sie Datentypen — erwarten Sie, was Sie benötigen (Whitelisting).
- Verwenden Sie Nonces für zustandsändernde Operationen.
- Vermeiden Sie es, rohes HTML zu speichern, wenn es nicht notwendig ist — speichern Sie strukturiertes JSON oder sanitärisierte Daten.
- Validieren Sie das Schema für JSON- oder Diagrammdaten und sanitärisieren Sie innerhalb jedes Feldes vor dem Rendern.
- Begrenzen Sie die Fähigkeiten: Erlauben Sie nur Rollen mit einem strengen Bedarf, Diagramme zu ändern, diese Fähigkeit zu haben.
- Implementieren Sie serverseitige Inhaltslängen-, Zeichensatz- und Typprüfungen für Uploads und Ajax-Payloads.
Härtung und langfristige Risikominderung
- Durchsetzen des Prinzips der geringsten Privilegien für Benutzerrollen.
- Aktivieren Sie 2FA für alle Admin-/Editor-Konten.
- Führen Sie regelmäßige Plugin- und Kernupdates durch; halten Sie eine Staging-Umgebung zum Testen bereit.
- Verwenden Sie die Überwachung der Dateiintegrität und geplante Schwachstellenscans.
- Halten Sie einen Vorfallreaktionsplan und getestete Backups bereit.
- Setzen Sie eine WAF ein, die für WordPress optimiert ist: blockieren Sie gängige Injektionsmuster, erzwingen Sie bekannte gute Verhaltensweisen und alarmieren Sie bei Anomalien.
- Wenden Sie Sicherheitsheader an: CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy und Strict-Transport-Security (HSTS).
Überwachung und Alarmierung — worauf man achten sollte
Richten Sie Warnungen ein für:
- Mehrere fehlgeschlagene Anmeldungen oder ungewöhnliche Anmeldeverhalten.
- Plötzliche Hinzufügung/Änderung von Plugins oder Themes.
- Neue Admin-Konten, die außerhalb normaler Prozesse erstellt wurden.
- Unerwartete Dateiänderungen in wp-content und uploads.
- Ungewöhnlich große POST-Anfragen oder verdächtige admin-ajax-Aktivitäten.
- Anstieg des ausgehenden Verkehrs oder ungewöhnliche externe Verbindungen.
Verwenden Sie zentralisierte Protokollierung und SIEM, wo immer möglich, damit Sie Webprotokolle, Serverprotokolle und WordPress-Ereignisse zur schnellen Erkennung korrelieren können.
Wie WP-Firewall hilft — praktische Funktionen, die dieses Risiko mindern
Als Team, das eine verwaltete WordPress WAF und Sicherheitsplattform betreibt, empfehlen wir einen mehrschichtigen Ansatz:
- Verwaltete WAF-Regelsätze — auf WordPress- und Plugin-Verhalten abgestimmt — die sofort bereitgestellt werden können, um Exploit-Muster für bekannte Schwachstellen zu blockieren, während Sie aktualisieren.
- Malware-Scans und Überprüfungen der Dateiintegrität, um persistente gespeicherte Payloads oder Hintertüren zu finden.
- Möglichkeit, den Zugriff auf Admin-Bereiche nach IP einzuschränken und zusätzliche Authentifizierungsherausforderungen anzuwenden.
- Rollen- und Aktivitätsüberwachung zur Erkennung verdächtiger Aktionen von Editoren/Beitragsautoren.
- Virtuelles Patchen für den Schutz vor Zero-Day-Angriffen, bis ein Plugin-Update angewendet werden kann.
- Leitfaden zur Incident-Response und koordinierte Bereinigung, falls ein Exploit erkannt wird.
Egal, ob Sie die WAF selbst verwalten oder unseren Managed-Service nutzen, diese Funktionen reduzieren die Exposition und geben Ihnen Zeit, sicher zu aktualisieren und zu beheben.
Praktische Beispielabfragen und -suchen für Ermittler
Verwenden Sie diese Suchideen (passen Sie sie an Ihre Datenbank und Tools an), um nach verdächtigen Inhalten zu suchen:
- Datenbanksuche nach Skript-Tags:
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%
- Suchoptionen und Plugin-Tabellen für Skripte oder base64:
SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%base64,%';
- In Uploads nach PHP-Dateien suchen:
finden /path/to/wordpress/wp-content/uploads -type f -name "*.php"
- Webserver-Logfilter:
grep -iE "(<script|onerror=|onload=|javascript:|base64,)" access.log
Exportieren Sie immer die Ergebnisse und speichern Sie sie außerhalb des Standorts für forensische Analysen.
Kommunikation und Koordination der Stakeholder
Wenn Sie Kundenwebsites, Agenturinhaber oder Hosting-Anbieter verwalten, kommunizieren Sie klar:
- Informieren Sie die Stakeholder über die Schwachstelle und dass ein Update oder eine Minderung erforderlich ist.
- Priorisieren Sie Websites nach Exposition (Multisite, Websites mit vielen Mitwirkenden, E-Commerce).
- Planen Sie Patchfenster und Backups.
- Gewähren Sie Transparenz, wenn ein Vorfall eine Behebung oder Ausfallzeit der Website erfordert.
Das Vorhandensein dieser Kommunikationslinien reduziert die Reaktionszeit erheblich, wenn neue Schwachstellen bekannt gegeben werden.
Schützen Sie Ihre Website noch heute – kostenloser Managed-Schutz von WP-Firewall
Der Schutz Ihrer WordPress-Seite sollte kein Glücksspiel sein. Wenn Sie sofortigen, verwalteten Schutz wünschen, der Ihnen Zeit zum Patchen und Wiederherstellen gibt, ziehen Sie unseren kostenlosen Basisplan in Betracht.
Beginnen Sie, Ihre Website kostenlos zu schützen
WP-Firewall Basic (Kostenlos) umfasst wesentliche Abwehrmaßnahmen zur Minderung von Risiken wie dem Visualizer XSS:
- Verwaltete Firewall mit WordPress-bewussten Regeln
- Unbegrenzte Bandbreite durch unsere Schutzschicht
- Web Application Firewall (WAF) mit Echtzeit-Blockierung
- Malware-Scanner zur Erkennung verdächtiger Dateien und injizierter Skripte
- Minderung der OWASP Top 10-Risiken
Melden Sie sich jetzt für den kostenlosen Plan an und erhalten Sie sofort eine Schutzschicht, während Sie Plugins patchen und die Kontosicherheit erhöhen:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Wenn Sie automatisierte Bereinigungen, erweiterte Kontrollen und virtuelles Patchen wünschen, bieten unsere Standard- und Pro-Pläne inkrementelle Funktionen, die mit Ihren Bedürfnissen skalieren.
Abschließende Empfehlungen — eine umsetzbare Checkliste
Bevor Sie diese Seite verlassen, hier ist eine kurze, druckbare Checkliste, die Sie sofort umsetzen können:
- Überprüfen Sie die Plugin-Version; aktualisieren Sie Visualizer sofort auf 4.0.0+.
- Wenn Sie nicht aktualisieren können, deaktivieren Sie das Plugin oder beschränken Sie den Zugriff auf die Plugin-Admin-Bildschirme.
- Implementieren Sie WAF-Regeln, um die Skripteinspritzung in Diagrammdaten und Plugin-Endpunkte zu blockieren.
- Überprüfen Sie privilegierte Benutzer; entfernen oder setzen Sie alle veralteten oder verdächtigen Konten zurück.
- Erstellen Sie einen Backup-Snapshot und bewahren Sie Protokolle für Untersuchungen auf.
- Scannen Sie nach injizierten Skripten, neuen Dateien in Uploads und unbekannten Admin-Benutzern.
- Härten Sie die Seite: Aktivieren Sie 2FA, erzwingen Sie starke Passwörter und beschränken Sie die Berechtigungen.
- Ziehen Sie eine verwaltete WAF oder Sicherheitsdienstleistung für virtuelles Patchen und aktive Minderung in Betracht.
Schlussgedanken
Schwachstellen wie das Visualizer XSS erinnern uns daran, dass selbst scheinbar risikoarme Plugins gefährlich werden können, wenn Benutzerdaten ohne strenge Validierung gespeichert und gerendert werden. Der Unterschied zwischen einem kleinen Problem und einem vollständigen Kompromiss der Seite hängt oft von der Vorbereitung ab: schnelles Patchen, geringste Privilegien, starke Kontohygiene und eine Verteidigungsstrategie in der Tiefe, die eine abgestimmte WAF umfasst.
Wenn Sie Hilfe bei der Bewertung der Exposition über mehrere Kundenwebsites benötigen oder Unterstützung beim Bereitstellen von virtuellen Patches wünschen, während Sie Plugins aktualisieren, steht Ihnen unser Team von WP-Firewall zur Verfügung. Bleiben Sie sicher, patchen Sie umgehend und härten Sie kontinuierlich.
— WP-Firewall-Sicherheitsteam
