| Plugin-Name | Ninja Forms |
|---|---|
| Art der Schwachstelle | Datenexposition |
| CVE-Nummer | CVE-2026-1307 |
| Dringlichkeit | Niedrig |
| CVE-Veröffentlichungsdatum | 2026-03-28 |
| Quell-URL | CVE-2026-1307 |
Sensible Datenexposition in Ninja Forms (<= 3.14.1) — Was WordPress-Seitenbesitzer wissen müssen und wie man Seiten mit WP-Firewall schützt
Zusammenfassung: Am 28. März 2026 wurde eine Schwachstelle veröffentlicht, die Ninja Forms-Versionen bis 3.14.1 (CVE-2026-1307, CVSS 6.5) betrifft. Sie ermöglicht es einem authentifizierten Benutzer mit Berechtigungen auf Contributor-Ebene (oder höher), über den Token-Pfad des Block-Editors auf sensible Informationen zuzugreifen. Obwohl die Schwachstelle ein authentifiziertes Konto erfordert, können die exponierten Daten für Folgeangriffe und laterale Bewegungen verwendet werden. Dieser Beitrag erklärt das Problem in einfacher Sprache, skizziert realistische Ausnutzungsszenarien, bietet sofortige Abhilfemaßnahmen, beschreibt Ansätze zur Erkennung und Überwachung und zeigt, wie WP-Firewall das Problem mindern und virtuell beheben kann, während Sie aktualisieren.
Hinweis: Wenn Sie Ninja Forms auf Ihrer Seite verwenden, behandeln Sie dies als umsetzbare Informationen — aktualisieren Sie das Plugin sofort, wo immer möglich, und implementieren Sie die unten beschriebenen mehrschichtigen Schutzmaßnahmen.
Was passiert ist (kurze Version)
Eine Schwachstelle im Ninja Forms-Plugin (Versionen <= 3.14.1) ermöglicht es einem authentifizierten Benutzer mit Contributor-Rechten — einer Rolle, die typischerweise Personen zugewiesen wird, die Inhalte einreichen, aber keine vertrauenswürdigen Administratoren sind —, sensible interne Informationen über die Integration des Block-Editors zu erhalten. Das Problem wird als Sensible Datenexposition kategorisiert und hat einen CVSS-Wert von 6.5. Der Anbieter veröffentlichte einen Patch in Version 3.14.2; ein Update auf 3.14.2 oder höher beseitigt die Schwachstelle.
Während ein Angriff ein angemeldetes Konto erfordert, sind Konten auf Contributor-Ebene auf vielen Seiten relativ häufig (Gastautoren, externe Redakteure, Praktikanten, Auftragnehmer). Die exponierten Informationen könnten Tokens oder Werte enthalten, die eine Eskalation oder den Missbrauch von Arbeitsabläufen oder REST-API-Funktionalitäten der Seite ermöglichen. Das macht dies zu einem mehr als theoretischen Problem: Ein Angreifer, der ein Contributor-Konto kontrolliert, könnte zu destruktiveren Aktionen übergehen.
Warum das wichtig ist — über die CVSS-Zahl hinaus
Viele Seitenbesitzer ignorieren Bedrohungen auf Contributor-Ebene in der Annahme, dass diese Konten stark eingeschränkt sind. In der Praxis:
- Contributor-Konten haben oft Zugang zum Block-Editor; einige Editoren und Plugin-Integrationen laden Assets hoch, fordern REST-Endpunkte an oder betten sensible Metadaten in Entwurf-Inhalte ein.
- Exponierte Tokens (Nonces, kurzlebige API-Tokens, Editor-Tokens) können von Angreifern wiederverwendet werden, um REST-Endpunkte aufzurufen, Seiteninformationen aufzulisten oder je nach Handhabung dieser Tokens durch die Seite und Plugins eine Berechtigungseskalation zu versuchen.
- Wenn Tokens oder interne IDs geleakt werden, könnte es möglich sein, Angriffe über viele Seiten zu automatisieren, die das Plugin verwenden — so verursachen auch Schwachstellen mit niedriger Schwere weitreichenden Schaden.
Obwohl die direkte Schwachstelle möglicherweise nicht sofort vollen Admin-Zugang gewährt, ist sie ein praktischer Ermöglicher für Folgeangriffe.
Technische Zusammenfassung (was Sie Ihrem Entwickler sagen sollten)
- Betroffenes Plugin: Ninja Forms
- Betroffene Versionen: <= 3.14.1
- Gepatcht in: 3.14.2
- CVE: CVE-2026-1307
- Erforderliche Berechtigung: Contributor (authentifiziert)
- Schwachstellenklasse: Offenlegung sensibler Daten (OWASP A3)
- Auswirkungen: Offenlegung von editorbezogenen Token(s) oder anderen sensiblen internen Informationen, die für Contributor-Konten nicht verfügbar sein sollten.
Einfach ausgedrückt: Das Plugin gab einen Wert aus dem Kontext des Block-Editors zurück oder erlaubte den Zugriff darauf, der serverseitig oder auf höhere Berechtigungen beschränkt bleiben sollte. Diese Daten in den falschen Händen können einem Angreifer helfen, interne Endpunkte aufzurufen oder Abläufe zu missbrauchen, die auf diesem Token basieren.
Praktische Angriffszenarien
- Token-Ernte und REST-Anfragen
– Ein böswilliger Contributor meldet sich an und öffnet den Block-Editor. Das Plugin exponiert ein Token im Editor-Kontext oder in einer Endpunktantwort. Der Angreifer exportiert dieses Token und verwendet es, um Plugin- oder REST-Endpunkte aufzurufen, die davon ausgehen, dass das Token ein Beweis für Vertrauen ist. - Automatisierte Aufklärung über Websites
– Wenn Angreifer ein kleines Skript oder gefälschte Anfragen erstellen können, sind sie möglicherweise in der Lage, Websites zu identifizieren, die die verwundbare Version verwenden (z. B. durch Abfragen von Endpunkten und Suchen nach einer bestimmten Antwortform). Sie können dann Konten von Mitwirkenden (gekauft, über Anmeldeprozesse erstellt oder durch Social Engineering erhalten) verwenden, um Tokens in großem Umfang zu ernten. - Wechsel zu Drittanbieter-Integrationen
– Tokens haben manchmal Auswirkungen über WordPress hinaus: Sie können den Missbrauch verbundener Dienste oder nachgelagerter Webhooks ermöglichen, wenn diese Systeme dem Token oder Wert vertrauen. Selbst wenn Tokens kurzlebig sind, kann der Angreifer schnell handeln. - Lokale Eskalation durch Verketten von Schwachstellen
– Das offengelegte Token könnte als ein Glied in einer Kette verwendet werden: z. B. Token -> REST-Endpunkt, der Benutzer-IDs offenbart -> Brute-Force privilegierte Konten oder Passwortzurücksetzungs-Workflows.
Selbst wenn Ihre Website nicht alle diese Abläufe direkt integriert, ist das Prinzip einfach: Die Offenlegung interner Tokens ist ein Risikomultiplikator.
Sofortige Maßnahmen (was in den nächsten 60 Minuten zu tun ist)
- Aktualisieren Sie Ninja Forms auf 3.14.2 oder höher
– Dies ist der wichtigste Schritt. Der Anbieter hat das Problem in 3.14.2 behoben. Aktualisieren Sie in allen betroffenen Umgebungen: Produktion, Staging und Entwicklung. - Wenn Sie nicht sofort aktualisieren können, deaktivieren Sie das Plugin oder deaktivieren Sie die Integration des Block-Editors
– Wenn das Aktualisieren kritische Funktionen beeinträchtigt und Sie Zeit zum Testen benötigen, ziehen Sie in Betracht, das Plugin in der Produktion vorübergehend zu deaktivieren oder den Zugriff auf den Block-Editor für Konten von Mitwirkenden einzuschränken, bis Sie aktualisieren können. - Überprüfen Sie Benutzerkonten mit Mitwirkenden- und höheren Berechtigungen
– Prüfen Sie kürzlich hinzugefügte Konten. Entfernen oder stufen Sie Konten herab, die Sie nicht erkennen. Erzwingen Sie starke Passwörter und 2FA für alle erhöhten Konten. - Drehen/ungültig machen relevanter Tokens und Sitzungen
– Wenn Sie eine Offenlegung vermuten, zwingen Sie die Abmeldung von Benutzern für Sitzungen, die betroffen sein könnten. Es gibt Tools und Plugins, um Sitzungen ablaufen zu lassen oder eine globale Abmeldung auszulösen. Ziehen Sie in Betracht, API-Schlüssel oder Webhook-Geheimnisse, die mit Ninja Forms verbunden sind, zu rotieren. - Überprüfen Sie Protokolle auf verdächtige Aktivitäten.
– Überprüfen Sie die Zugriffsprotokolle und REST-API-Protokolle auf anomale Muster von Konten mit Mitwirkenden, insbesondere Anfragen an /wp-json/-Endpunkte oder plugin-spezifische Endpunkte kurz nachdem der Block-Editor geöffnet wurde. - Benachrichtigen Sie Mitwirkende und Redakteure
– Wenn Sie Benutzerkonten verwalten, benachrichtigen Sie Ihre Mitwirkenden, vorsichtig zu sein, Passwörter zu ändern und unerwartetes Verhalten zu melden.
Erkennung: wie man erkennt, ob man Ziel oder ausgenutzt wurde
Achten Sie auf die folgenden Indikatoren:
- Ungewöhnliche REST-API-Anfragen, die von authentifizierten Konten mit Mitwirkenden stammen (POST/GET zu Plugin-Endpunkten).
- Mehrere Instanzen des Öffnens des Block-Editors von derselben IP oder mehrere Konten, die aus demselben IP-Bereich stammen.
- Neue oder unerwartete ausgehende Verbindungen oder Webhook-Aufrufe, die mit Ihren Plugin-Hooks verbunden sind.
- Anfragen, die interne Tokens oder unerwartete JSON-Felder in den Antworten zurückgeben.
- Höhere als normale Aktivität auf der Website von Benutzern mit niedrigen Berechtigungen innerhalb eines kurzen Zeitfensters (insbesondere die Erstellung vieler Entwürfe, das Hochladen von Anhängen oder die Konfiguration von Formularen).
Handlungsfähige Protokollabfragen:
- Durchsuchen Sie die Webserver-Protokolle nach POST/GET zu /wp-json/ Pfaden, die mit Ninja-Forms oder Block-Editor-Endpunkten verbunden sind.
- Überprüfen Sie die WordPress-Debug-Protokolle auf PHP-Hinweise/WARNUNGEN, die Datenexposition offenbaren.
- Wenn Sie Anwendungsprotokolle haben (WAF, Hosting-Panel, Plugin-Protokolle), filtern Sie nach Konten-IDs, die auf Contributor-Ebene sind, und überprüfen Sie die letzten Anfragen.
Härtung und langfristige Minderungsmaßnahmen
Selbst nach einem Update sollten Sie diese Schritte unternehmen, um das Risiko zu reduzieren und die Resilienz zu erhöhen:
- Modell der geringsten Privilegien
– Überprüfen Sie die Rollenzuweisungen. Beiträge benötigen in der Regel nicht die Block-Editor- oder Medien-Upload-Funktionen. Erwägen Sie, die Editor-Funktion zu entfernen oder zu einer eingeschränkteren Rolle für externe Mitwirkende zu wechseln. - Aktivieren Sie die Zwei-Faktor-Authentifizierung
– Erzwingen Sie 2FA (insbesondere für Konten mit erhöhten Berechtigungen), damit gestohlene Passwörter oder wiederverwendete Anmeldeinformationen nicht sofort Zugriff gewähren. - Inhalte moderieren Arbeitsabläufe
– Verwenden Sie Moderations- und redaktionelle Überprüfungsprozesse, damit Inhalte nicht automatisch von Konten mit begrenztem Vertrauen veröffentlicht werden können. - Begrenzen Sie die Bearbeitung von Plugins und Themes
– Deaktivieren Sie die Dateibearbeitung in WordPress (define('DISALLOW_FILE_EDIT', true)) und entfernen Sie unnötige Admin-Bildschirme von niedrigeren Rollen. - Kontrollieren Sie den REST-Zugriff
– Verwenden Sie ein Plugin oder benutzerdefinierten Code, um REST-Endpunkte einzuschränken, die nicht öffentlich sein müssen. Überprüfen Sie sorgfältig Endpunkte, die Daten zurückgeben, und stellen Sie sicher, dass die richtigen Berechtigungsprüfungen durchgeführt werden. - Wenden Sie regelmäßig Sicherheitsupdates an
– Halten Sie Plugins, Themes und den WordPress-Kern auf dem neuesten Stand. Testen Sie Updates in einer Staging-Umgebung, bevor Sie sie in der Produktion bereitstellen. - Implementieren Sie das Protokollieren und Überwachen auf Anwendungsebene
– Stellen Sie sicher, dass Sie klare Protokolle darüber haben, wer auf den Block-Editor zugreift und wann. Verknüpfen Sie Protokolle mit Authentifizierungsereignissen, damit Sie das Verhalten von Konten korrelieren können.
Wie WP-Firewall hilft (reale Schutzmaßnahmen, die Sie heute aktivieren können)
Als Anbieter von mehrschichtigen Schutzmaßnahmen für WordPress-Seiten bietet WP-Firewall mehrere Verteidigungen, um sowohl die Ausnutzbarkeit als auch die Auswirkungen zu reduzieren:
- Verwaltete Webanwendungs-Firewall (WAF): blockiert gängige Ausnutzungsmuster und kann virtuelle Patches bereitstellen, um den Ausnutzungsverkehr zu stoppen, bevor er das Plugin erreicht.
- Malware-Scannen und -Erkennung: identifiziert injizierte Payloads oder Indikatoren, dass Angreifer versucht haben, geleakte Tokens zu verwenden.
- Ratenbegrenzung und IP-Kontrollen: verringern die Effektivität der automatisierten Token-Ernte, indem verdächtige Anfragen gedrosselt werden.
- Sitzungsmanagement: ermöglicht eine erzwungene Sitzungsinvalidierung, um sicherzustellen, dass exponierte Tokens oder Sitzungen nicht mehr verwendet werden können.
- Überwachung und Warnungen: erkennen ungewöhnliche Aktivitäten von Mitwirkenden und benachrichtigen Administratoren nahezu in Echtzeit.
Wenn Sie nicht sofort aktualisieren können, ist eine WAF-Schicht, die die spezifischen Ausnutzungsmuster erkennen und blockieren kann, eine praktische Übergangslösung. WP-Firewall unterstützt virtuelles Patchen und benutzerdefinierte Regeln, um diese genaue Klasse von sensiblen Datenexpositionen zu mindern.
Vorgeschlagene WAF-Regeln und virtuelle Patches (für Site-Administratoren und Sicherheitsingenieure)
Im Folgenden finden Sie Beispielansätze für WAF-Regelautoren. Dies sind allgemeine Muster — passen Sie sie an Ihre Umgebung an und testen Sie sie in der Staging-Umgebung, bevor Sie sie in der Produktion verwenden.
- Blockieren Sie übermäßige REST-Aufrufe des Block-Editors durch Benutzer mit niedrigen Berechtigungen
– Bedingung: Anfragen an REST-Endpunkte, die mit Block-Editor oder Plugin-Admin-Funktionen von Konten mit der Rolle Mitwirkender verbunden sind.
– Antwort: Drosseln oder blockieren mit 403, wenn Schwellenwerte überschritten werden. - Antworten erkennen, die Tokens in HTML/JSON enthalten
– Bedingung: Ausgehende Antworten auf authentifizierte Anfragen von Mitwirkenden, die Zeichenfolgen enthalten, die mit tokenähnlichen Mustern übereinstimmen (z. B. lange base64-Zeichenfolgen, “token”, “nonce” im Antwortkörper, die mit dem Plugin verbunden sind).
– Antwort: Protokollieren und blockieren. Beispiel-Regex:(token|nonce|secret|auth)[\"'\s:]{0,5}[\"']?[A-Za-z0-9-_]{24,}
Hinweis: Vermeiden Sie das Blockieren legitimer kurzer Zeichenfolgen. Passen Sie die Regex an, indem Sie sie in der Staging-Umgebung testen. - Verdächtige Muster nach Benutzer-Agent und Referrer blockieren
– Bedingung: Nicht-Browser-Benutzer-Agenten oder No-Referrer-Anfragen an Block-Editor-Endpunkte.
– Antwort: Herausforderung (CAPTCHA) oder blockieren. - Dateiupload-Endpunkte begrenzen
– Bedingung: Mehrfache Uploads zu Editor-Endpunkten durch Contributor-Konten innerhalb eines kurzen Zeitfensters.
– Antwort: Blockieren oder manuelle Überprüfung verlangen. - Virtueller Patch für Plugin-Endpunkte
– Bedingung: Anfragen an die Plugin-Route, die bekannt dafür ist, sensible Daten zurückzugeben. Wenn ein Update noch nicht möglich ist, Antworten verwerfen oder bereinigte Daten zurückgeben.
– Antwort: 403 oder bereinigte Antwort zurückgeben, bis das Plugin gepatcht ist.
Wenn Sie WP-Firewall verwenden, kann unser Team getestete virtuelle Patches bereitstellen und implementieren, um Ausnutzungs-Signaturen für diese Schwachstelle zu blockieren, während Sie das Plugin-Update planen.
Vorfallreaktions-Checkliste (Schritt-für-Schritt-Playbook)
Wenn Sie vermuten, dass Ihre Seite angegriffen wurde:
- Isolieren
– Öffentliches Zugriffsrecht vorübergehend deaktivieren oder die Seite in den Wartungsmodus versetzen, wenn Sie aktive Ausnutzung vermuten. - Beweise sichern
– Serverprotokolle, Plugin-Protokolle und WAF-Protokolle mit Zeitstempeln exportieren. Dateien nicht kürzen. - Geheimnisse rotieren
– API-Schlüssel, Webhook-Geheimnisse und alle über das Plugin zugänglichen Schlüssel widerrufen. Alle Benutzer abmelden und Passwortzurücksetzungen für betroffene Konten ausstellen. - Aktualisieren
– Sofort Ninja Forms auf die gepatchte Version (3.14.2+) in allen Umgebungen aktualisieren. - Scannen und entfernen
– Einen vollständigen Malware-Scan durchführen. Nach Webshells, Hintertüren, verdächtigen geplanten Aufgaben oder modifizierten Dateien suchen. - Konten prüfen
– Verdächtige Contributor-Konten deaktivieren oder entfernen. 2FA und stärkere Passwörter für Administratoren und Redakteure durchsetzen. - Wiederherstellen und validieren
– Wenn die Integrität des Codes in Zweifel steht, aus einem sauberen Backup wiederherstellen, das vor dem Kompromiss erstellt wurde. Funktionalität in der Staging-Umgebung validieren. - Nach dem Vorfall
– Rotieren Sie alle Geheimnisse erneut, überprüfen Sie die Protokolle und implementieren Sie zusätzliche Härtungsmaßnahmen, die zuvor empfohlen wurden (geringste Privilegien, REST-Einschränkungen, WAF-Regeln). - Kommunizieren Sie
– Wenn Benutzerdaten oder Systeme von Drittanbietern betroffen sein könnten, folgen Sie Ihren Offenlegungsprozessen und informieren Sie die Stakeholder.
Empfehlungen für Hosting-Anbieter und Multi-Site-Administratoren
- Erzwingen Sie, wo möglich, zentrale Plugin-Updates.
- Verwenden Sie rollenbasierte Verwaltung: Beschränken Sie den Zugriff von Mitwirkenden auf den Block-Editor auf Websites oder Netzwerke, wo dies nicht erforderlich ist.
- Bieten Sie eine Ein-Klick-WAF-virtuelle Patch-Lösung an, um Exploit-Verkehr sofort zu blockieren, sobald eine Schwachstelle entdeckt wird.
- Stellen Sie Prüf- und Alarmierungsoberflächen für Kundenseiten bereit, um die Aktivitäten von Mitwirkenden zu überprüfen.
Beispielhafte Erkennungsabfragen und schnelle Skripte
Webserver-Protokoll (nginx/apache) grep für REST-Endpunkte:
grep "/wp-json/" /var/log/nginx/access.log | grep "ninja-forms\|block-editor"Suchen Sie nach Aktivitäten von Mitwirkenden-Konten:
# Ersetzen Sie ACCOUNT_ID durch die Benutzer-ID"Schnelle WordPress-Datenbankprüfung auf verdächtige Editor-Meta:
SELECT post_id, meta_key, meta_value;Verwenden Sie diese nur als Ausgangspunkte — Protokolle und Schemata variieren je nach Host.
Test- und Staging-Anleitung
- Testen Sie immer Plugin-Updates in einer Staging-Umgebung, bevor Sie sie in die Produktion übertragen.
- Spielen Sie echte Editor-Interaktionen im Staging nach, um sicherzustellen, dass es keine Rückschritte gibt.
- Aktivieren Sie zuerst den WAF-virtuellen Patch im Staging für Überprüfungen auf falsch-positive Ergebnisse.
- Führen Sie geplante Backups vor jedem größeren Update durch.
Beginnen Sie mit dem WP-Firewall Kostenlosen Plan — Essentielle Sicherheit, null Kosten
Wenn Sie sofortige, kostenfreie Schutzmaßnahmen wünschen, um das Risiko während des Testens und der Bereitstellung von Updates zu reduzieren, probieren Sie den WP-Firewall Basic (Kostenlos) Plan aus. Er umfasst eine verwaltete Firewall, unbegrenzte Bandbreite, eine WAF (Web Application Firewall), einen Malware-Scanner und Abwehrmöglichkeiten gegen die OWASP Top 10 Bedrohungen — alles Werkzeuge, die helfen, Ausnutzungsversuche zu erkennen und zu blockieren, während Sie dauerhafte Lösungen anwenden.
Melden Sie sich für den kostenlosen Plan an und aktivieren Sie den Schutz schnell
(Wenn Sie schnellere Reaktionen oder automatisches virtuelles Patchen für hochriskante Schwachstellen benötigen, beinhalten unsere kostenpflichtigen Pläne die automatische Malware-Entfernung, strengere IP-Kontrollen, automatisches virtuelles Patchen, monatliche Sicherheitsberichte und verwaltete Dienste.)
Häufige Fragen, die wir von Seiteninhabern hören
Q: “Kann ich einen böswilligen Contributor-Nutzer auf meiner Seite daran hindern, den Editor vollständig zu nutzen?”
A: Ja. Sie können die Block-Editor-Funktionen aus der Contributor-Rolle entfernen, ein klassisches Editor-Plugin verwenden, das die Exposition einschränkt, oder externe Contributor in eine Rolle mit weniger Fähigkeiten umwandeln.
Q: “Ist dies ein weit verbreitetes Risiko für Massenausnutzung?”
A: Jede Schwachstelle, die von einem authentifizierten Konto mit niedrigen Rechten ausgelöst werden kann, wird zu einem Kandidaten für Massenausnutzung, da Angreifer Konten registrieren oder kaufen können, um die Ausnutzung zu skalieren. Setzen Sie mehrschichtige Abwehrmaßnahmen (Patch + WAF + Überwachung) ein, um das Risiko zu reduzieren.
Q: “Wird das Zwingen von Benutzern zum Abmelden Tokens, die im Editor exponiert sind, widerrufen?”
A: Bei sitzungsbasierten Nonces und nicht persistierenden Tokens ist das Zwingen zum Abmelden effektiv. Für langlebige API-Schlüssel oder Webhook-Tokens müssen Sie diese ausdrücklich widerrufen oder rotieren.
Q: “Kann WP-Firewall dies blockieren, ohne das Plugin zu aktualisieren?”
A: Ja — virtuelles Patchen kann Ausnutzungsverkehrsmuster blockieren und die Token-Exfiltration verhindern. Aber virtuelle Patches sind eine Übergangslösung: Das Aktualisieren des Plugins ist die langfristige Lösung.
Abschließende Hinweise vom WP-Firewall-Sicherheitsteam
Schwachstellen, die interne Tokens leaken, sind besonders gefährlich, da sie andere Schutzmaßnahmen in Ihrem Stack schwächen. Behandeln Sie dieses Problem mit Dringlichkeit: Aktualisieren Sie Ninja Forms so schnell wie möglich auf 3.14.2 (oder höher), prüfen und beschränken Sie die Berechtigungen der Contributor, rotieren Sie potenziell betroffene Geheimnisse und aktivieren Sie ein WAF-basiertes virtuelles Patch, wenn es zu Verzögerungen bei der Anwendung des Updates kommt.
Wenn Sie Hilfe bei der Erkennung, virtuellem Patchen oder Incident Response benötigen, bietet das Team von WP-Firewall verwaltete Dienste und professionelle Unterstützung an, um Ihnen zu helfen, Ihre Seite wiederherzustellen und abzusichern. Beginnen Sie mit unserem kostenlosen Schutzplan, um sofortige Abdeckung zu erhalten, und wechseln Sie zu einem kostenpflichtigen Plan, wenn Ihre Bedürfnisse wachsen.
Bleiben Sie sicher und halten Sie Ihre Seite aktuell.
— WP-Firewall-Sicherheitsteam
