Plugin-Name	Interaktive Geo-Karten
Art der Schwachstelle	Cross-Site-Scripting (XSS)
CVE-Nummer	CVE-2025-15345
Dringlichkeit	Medium
CVE-Veröffentlichungsdatum	2026-05-14
Quell-URL	CVE-2025-15345

Reflektiertes XSS in interaktiven Geo-Karten (<= 1.6.27) — Was WordPress-Seitenbesitzer wissen müssen (CVE‑2025‑15345)

Autor: WP‐Firewall-Sicherheitsteam
Datum: 2026-05-14

TL;DR — Eine reflektierte Cross-Site Scripting (XSS) Schwachstelle, die das Plugin Interaktive Geo-Karten (Versionen <= 1.6.27, behoben in 1.6.28) betrifft, wurde offengelegt (CVE‑2025‑15345). Die Schwachstelle ermöglicht es einem Angreifer, eine URL zu erstellen, die, wenn sie von einem Ziel (häufig einem Seitenadministrator oder einem anderen privilegierten Benutzer) besucht wird, beliebiges JavaScript im Browser des Opfers ausführen kann. Aktualisieren Sie sofort auf 1.6.28. Wenn Sie nicht sofort aktualisieren können, wenden Sie die unten aufgeführten vorübergehenden Minderungstechniken an und aktivieren Sie eine Regel der Webanwendungsfirewall, um Exploit-Versuche zu blockieren.

---

Einführung

Als Anbieter von WordPress-Sicherheit und das Team hinter WP‑Firewall verfolgen wir Berichte, die Millionen von Seiten betreffen. Am 14. Mai 2026 wurde ein reflektiertes Cross-Site Scripting (XSS) Problem im Plugin Interaktive Geo-Karten (bis Version 1.6.27) öffentlich bekannt gegeben und mit CVE‑2025‑15345 versehen. Dieser Beitrag erklärt, was die Schwachstelle ist, warum sie wichtig ist, wie Angreifer sie ausnutzen könnten, wie man erkennt, ob Ihre Seite angegriffen oder ausgenutzt wurde, sofortige Minderungstechniken, die Sie anwenden können, und langfristige Lösungen, die Plugin-Autoren implementieren sollten.

Ich werde dies aus der Perspektive erfahrener WordPress-Sicherheitsexperten schreiben. Dies ist praktische, umsetzbare Anleitung — keine trockene akademische Zusammenfassung.

Schwachstellensummary

• Betroffene Software: Plugin Interaktive Geo-Karten für WordPress
• Verwundbare Versionen: <= 1.6.27
• Behoben in: 1.6.28
• Sicherheitsanfälligkeitstyp: Reflektiertes Cross-Site-Scripting (XSS)
• CVE-ID: CVE‑2025‑15345
• CVSS (berichtet): 7.1 — mittel/hoch, abhängig vom Kontext
• Erforderliches Privileg: nicht authentifiziert, um die bösartige URL zu erstellen; Benutzerinteraktion erforderlich (ein Opfer muss einen erstellten Link öffnen oder eine Seite laden)
• Risikoübersicht: Ein Angreifer kann eine URL erstellen, die unsanitisierten Input auf eine Seite reflektiert, wodurch die Ausführung von JavaScript im Kontext des Browsers des Opfers ermöglicht wird. Wenn das Opfer ein Administrator oder ein anderer privilegierter Benutzer ist, könnte der Angreifer Sitzungstoken stehlen, Aktionen über den Browser ausführen oder weitere Malware liefern.

Warum diese Art von Schwachstelle gefährlich ist

Reflektiertes XSS ist eine der ältesten, aber immer noch häufig ausgenutzten Web-Schwachstellen, da es sich leicht mit Social Engineering kombinieren lässt. Ein Angreifer erstellt eine URL zu einer verwundbaren Seite auf Ihrer Website und verleitet einen Benutzer, darauf zu klicken (über E-Mail, soziale Medien oder private Nachrichten). Da die Injektion sofort auf der Seite reflektiert wird, wird das bösartige Skript im Browser des Benutzers mit den gleichen Rechten wie die Sitzung des Benutzers ausgeführt.

Wenn das Opfer ein Seitenadministrator ist, kann der Angreifer:

• Sitzungscookies stehlen und sich als Administrator ausgeben,
• Administratoraktionen über CSRF-ähnliche Techniken auslösen,
• Beiträge, Einstellungen oder Plugins erstellen oder ändern,
• Persistente bösartige Inhalte injizieren (durch Verwendung von Admin-Schnittstellen),
• Weitere browserbasierte Payloads liefern (Weiterleitungen, Keylogger usw.).

Selbst wenn ein ausgenutzter Benutzer kein Admin ist, umfasst das Risiko die Veränderung der Webseite, Weiterleitungen zu bösartigen Seiten oder die Einspeisung von Affiliate-Spam.

Wie ein reflektiertes XSS in einem interaktiven Karten-Plugin erreicht werden könnte

Interactive Geo Maps ist ein Plugin, das typischerweise Parameter sowohl aus der URL (Abfragezeichenfolge) als auch aus Formularübermittlungen erhält, um das Kartenverhalten oder den Fokus zu definieren. Ein reflektiertes XSS tritt normalerweise auf, wenn das Plugin einen benutzerkontrollierten Wert (z. B. Karten-ID, Beschriftung, Standortparameter oder Nachricht) ohne ordnungsgemäße Escape- oder Sanitärmaßnahmen in HTML oder JavaScript zurückgibt.

Häufige Vektoren:

• Abfragezeichenfolgenparameter, die verwendet werden, um Marker hervorzuheben oder Popups anzuzeigen.
• Shortcode-Attribute, die in der öffentlichen Kartenoberfläche angezeigt werden.
• AJAX-Handler, die Eingaben in JSONP-ähnlichen Antworten oder in HTML-Schnipseln zurückgeben, die an den Browser gesendet werden.
• Admin-Vorschauseiten, die vom Benutzer bereitgestellte Inhalte ohne Ausgabe-Codierung anzeigen.

Da die Schwachstelle “reflektiert” ist, muss der Angreifer keine bösartigen Daten auf dem Server speichern — er erstellt einfach eine URL, die die Payload enthält, und sendet sie an ein Ziel.

Ausbeutungsszenarien

1. Gezielter Admin-Kompromiss
   – Angreifer erstellt eine Karten-URL, die ein bösartiges Skript in einem Parameter enthält, der im Admin-Vorschau- oder Einstellungsbildschirm angezeigt wird.
   – Der Angreifer sendet eine E-Mail an den Seiteninhaber oder postet den Link in einem Forum; der Admin klickt darauf, während er angemeldet ist.
   – Das Skript wird im Admin-Kontext ausgeführt und stiehlt Authentifizierungscookies oder löst Aktionen aus.
2. Massenphishing-Kampagne
   – Angreifer sendet eine breite Phishing-E-Mail mit der erstellten URL an Mailinglisten oder Abonnenten.
   – Jeder Besucher, der auf den Link klickt und auf der Seite angemeldet ist (oder ein integriertes Single Sign-On hat), könnte betroffen sein.
3. Ausnutzung durch Dritte
   – Wenn die Seite den anfälligen Link öffentlich veröffentlicht (zum Beispiel teilbare Karten), könnten zufällige Besucher betroffen sein, was die Veränderung der Webseite oder die Umleitung von Verkehr zu bösartigen Domains ermöglicht.

Anzeichen für Kompromittierung und Erkennung

Reflektiertes XSS wird oft mit Social Engineering kombiniert, sodass Protokolle und Browser-Telemetrie die primären Erkennungspunkte sind.

Suchen Sie nach:

• Unusual query strings in server access logs containing strings like “<script”, “javascript:”, “onerror=”, or encoded equivalents (“script”, etc.).
• Anfragen, die verdächtige Payloads enthalten, gefolgt von sofortigen Admin-Aktivitäten (z. B. plötzliche Änderungen an Inhalten oder Einstellungen).
• Browserseitige Berichte von Benutzern, die sich über seltsame Popups oder Weiterleitungen nach dem Klicken auf freigegebene Links beschweren.
• Unerwartete Administratorsitzungen, die von unbekannten IP-Adressen kurz nach einer verdächtigen Anfrage erstellt wurden.
• Modifizierte Beiträge, neu erstellte Benutzer, unautorisierte Plugin-/Theme-Änderungen.

Praktische Beispiele für die Protokollsuchen (konzeptionell; an Ihr Protokollformat anpassen):

• Zugriffsprotokolle: Suchen Sie nach GET-Anfragen mit Parametern, die prozentual kodierte spitze Klammern oder verdächtige Schlüsselwörter enthalten.
• WP-Aktivitätsprotokolle (wenn Sie die Benutzeraktivität protokollieren): korrelieren Sie ungewöhnliche Anmeldesitzungen, Beitragsänderungen oder Optionsaktualisierungen mit ungewöhnlichen eingehenden Anfragen.

Sofortige Schritte für Website-Besitzer (was jetzt zu tun ist)

Wenn Ihre Website interaktive Geo-Karten verwendet und Sie das Plugin nicht sofort auf 1.6.28 aktualisieren können, befolgen Sie diese Notfall-Minderungsmaßnahmen:

1. Sofort aktualisieren (beste Lösung)
   – Wenn möglich, aktualisieren Sie das Plugin jetzt auf 1.6.28. Dies ist die einzige vollständige Lösung.
2. Falls Sie nicht sofort aktualisieren können:
   – Deaktivieren Sie das Plugin vorübergehend (wenn Karten für den aktuellen Betrieb der Website nicht kritisch sind).
   – Wenn das Deaktivieren nicht akzeptabel ist, beschränken Sie den Zugriff auf Seiten, die das Plugin verwenden, wo es praktikabel ist (z. B. Karten hinter Authentifizierung oder einem Wartungsflag bewegen).
   – Verwenden Sie WP-Rollenbeschränkungen: Begrenzen Sie, wer die Admin-Vorschauseiten oder Einstellungen sehen kann, um die anvisierbare Zielgruppe zu reduzieren.
   – Verwenden Sie Content Security Policy (CSP)-Header, um die Auswirkungen von injizierten Skripten zu reduzieren (Hinweis: CSP kann umgangen werden, wenn Inline-Skripte erlaubt sind; vorsichtig konfigurieren).
   – Sanitieren Sie eingehende Anfragen mit einer WAF-Regel: blockieren Sie Abfragezeichenfolgen, die verdächtige Muster enthalten, die häufig in XSS-Payloads verwendet werden (siehe empfohlene WAF-Signaturen unten).
3. Überwachen und untersuchen:
   – Suchen Sie Protokolle nach verdächtigen langen Abfragezeichenfolgen und kodierten Payloads.
   – Überprüfen Sie Admin-Konten auf unautorisierte Aktionen.
   – Wenn Sie einen Kompromiss vermuten, ändern Sie die Passwörter von Admin- und privilegierten Benutzern und geben Sie alle API-Token oder Integrationsgeheimnisse neu aus.

WAF-Minderungsmaßnahmen: was zu aktivieren ist, während Sie patchen.

Eine Webanwendungs-Firewall ist eine effektive Übergangslösung; sie kann typische Exploit-Muster blockieren, bevor sie das anfällige Plugin erreichen. Als WP-Firewall empfehlen wir Regeln, die mehrere Indikatoren kombinieren, anstatt einfache String-Blockierungen, um Fehlalarme zu reduzieren.

Beispielregelkonzepte (Pseudocode; sorgfältig testen, bevor sie in der Produktion angewendet werden):

• Blockiere Anfragen, bei denen die Abfragezeichenfolge unescaped “<script” oder Ereignis-Handler enthält:
  If request.querystring matches "(?i)(script|<script|onerror\s*=|onload\s*=|javascript:)" then block.
• Blockiere Anfragen, die offensichtliche XSS-Payload-Codierungen enthalten:
  If request.uri or request.args has sequences like "script" or "img" then block or challenge (CAPTCHA).
• Rate limitiere oder fordere eine Herausforderung für Anfragen, die verdächtige Payload-Muster enthalten:
  Wenn dieselbe IP viele Anfragen mit codierten spitzen Klammern durchführt, rate limitiere oder präsentiere eine Herausforderung.
• Blockiere verdächtige ‘gerenderte’ Parameter an Endpunkten, die vom Karten-Plugin verwendet werden:
  Wenn der Endpunkt der bekannten Karten-AJAX-URL entspricht und die Parameterlänge > 200 beträgt und Markup/codierte Zeichen enthält => blockiere.

Wichtig: Jede Seite ist anders; zu breite Regeln werden legitime Nutzung unterbrechen (z. B. Kartenbeschriftungen, die legitim HTML-Entitäten enthalten). Beginne mit dem Blockieren von Anfragen aus eindeutig bösartigen Mustern und passe dann an.

Vorgeschlagener ModSecurity-Schnipsel (konzeptionell)
(Hinweis: Füge keine rohen Exploit-Payloads in Protokolle ein; halte die Regeln auf hoher Ebene.)

SecRule REQUEST_URI|ARGS_NAMES|ARGS "(?i)(?:<script|script|javascript:|onerror\s*=|onload\s*=)" \n "id:1009001,phase:2,deny,msg:'Potential reflected XSS attempt in Interactive Geo Maps',log,severity:2"

Passe die Regel-Logik an, damit sie auf Endpunkte und Parameter abzielt, die mit dem Plugin verbunden sind, um das Blockieren von harmlosen Verkehr zu vermeiden.

Härtungs- und Erkennungsrezepte

• Implementiere das Prinzip der geringsten Privilegien für Administratorkonten. Verwende separate Konten für die Site-Administration und die Inhaltsveröffentlichung, wo es praktikabel ist.
• Aktiviere sichere Cookies und verwende das Attribut “SameSite” für Cookies, um Vektoren für den Diebstahl von Cookies zu reduzieren.
• Erzwinge starke Passwörter und aktiviere die Multi-Faktor-Authentifizierung (MFA) für Administratorkonten.
• Aktiviere und überwache Aktivitätsprotokolle – protokolliere jede administrative Aktion als Teil einer Erkennungsstrategie.
• Verwenden Sie einen mehrschichtigen Verteidigungsansatz:
  • Halten Sie Kern, Thema und Plugins aktuell.
  • Verwenden Sie eine WAF mit optimierten Regeln.
  • Verwenden Sie zur Überwachung der Dateiintegrität zur Laufzeit, um unerwartete Dateiänderungen zu erkennen.
• Fügen Sie eine Richtlinie für gestaffelte Plugin-Updates in einer Test-/Staging-Umgebung hinzu, bevor Sie in die Produktion gehen, wenn Sie viele Seiten verwalten.

Für Entwickler: wie dies richtig behoben werden sollte

Wenn Sie ein Plugin-Entwickler sind oder benutzerdefinierten Code pflegen, der mit Benutzereingaben interagiert, befolgen Sie diese sicheren Entwicklungsregeln:

1. Validieren und bereinigen Sie Eingaben.
   – Vertrauen Sie niemals Eingaben von GET-, POST- oder AJAX-Endpunkten. Validieren Sie Typ, Länge und erwartetes Format.
   – Für Werte, die Ganzzahlen sein müssen, wandeln Sie in (int) um. Überprüfen Sie bei bekannten Enumerationswerten die zulässigen Werte.
2. Escape bei Ausgabe
   – Entkommen Sie für den richtigen Kontext: HTML, Attribut, JavaScript, URL.
       – Verwenden Sie esc_html() Und esc_attr() in PHP für Text und Attribute.
       – Für JavaScript innerhalb von HTML verwenden Sie wp_json_encode() oder json_encode() und geben Sie über Datenattribute aus; verwenden Sie dann textInhalt oder eine sichere Zuweisung in JS.
   – Vermeiden Sie es, rohen Benutzerinhalt über innerHTML in das DOM einzufügen.
3. Verwenden Sie geeignete Template-APIs
   – Wenn Sie JSON-Daten zurückgeben, die von Client-JS verarbeitet werden sollen, stellen Sie sicher, dass jede nachfolgende Einfügung in das DOM über sichere APIs erfolgt (textInhalt oder bereinigte Vorlagen).
4. Nonces und Berechtigungsprüfungen
   – Für jede Aktion, die den Zustand beeinflusst (Einstellungen speichern, Daten schreiben), überprüfen Sie einen gültigen Nonce und die Berechtigungsprüfungen (current_user_can()) wo zutreffend.
5. Bereinigen Sie AJAX-Antworten
   – Wenn Ihr Code HTML-Schnipsel über AJAX zurückgibt, stellen Sie sicher, dass diese Schnipsel serverseitig mit escaped Variablen gerendert werden oder der AJAX-Endpunkt nur JSON zurückgibt und clientseitig sichere DOM-Elemente erstellt.

Beispiel für einen sicheren PHP-Schnipsel

&lt;?php&#039;<div class="map-label">' . esc_html( $label ) . '</div>';

Beispiel für eine sichere JavaScript-Einfügung

// dataLabel ist eine Zeichenfolge aus einer sicheren JSON-Antwort;

Checkliste für die Reaktion auf Zwischenfälle

Wenn Sie einen aktiven Exploit oder Anzeichen einer Kompromittierung entdecken, ergreifen Sie diese Maßnahmen:

1. Enthalten
   – Deaktivieren oder nehmen Sie Seiten offline, die aktiv ausgenutzt werden.
   – Wenn die Ausnutzung Administratorenkonten betrifft, deaktivieren Sie den Zugriff vorübergehend.
2. Ausrotten
   – Aktualisieren Sie das Plugin auf 1.6.28.
   – Entfernen Sie alle bösartigen Dateien oder Codes, die von Angreifern eingeführt wurden.
   – Setzen Sie die Administratorpasswörter zurück und geben Sie Geheimnisse/Tokens neu aus.
3. Genesen
   – Stellen Sie bei Bedarf aus einem bekannten guten Backup wieder her.
   – Validieren Sie Plugins/Themes und Kern-Dateien erneut über Prüfziffern oder Dateiintegritätswerkzeuge.
4. Nach dem Vorfall
   – Rotieren Sie Schlüssel für externe Dienste, die möglicherweise zugegriffen wurden.
   – Überprüfen Sie Protokolle, um die Eingangsart und den Umfang zu bestimmen.
   – Benachrichtigen Sie betroffene Benutzer, wenn Anmeldeinformationen oder persönliche Daten möglicherweise offengelegt wurden.

Warum reflektierte XSS in WordPress-Plugins weiterhin häufig vorkommen

Die Entwicklung von WordPress-Plugins variiert stark in Bezug auf Fähigkeiten und Sicherheitsbewusstsein. Mehrere beitragende Faktoren halten XSS häufig:

• Schnelle Entwicklungszyklen und Druck auf Funktionen.
• Mangelnde konsistente Verwendung von WordPress-Escape-Funktionen (esc_html, esc_attr usw.).
• UI-Frameworks, die direkte DOM-Manipulation ohne sichere Codierungsmuster fördern.
• Komplexe Eingabepfade: Shortcode-Attribute, AJAX-Handler, REST-Endpunkte und Front-End-Interaktivität erhöhen die Anzahl der Stellen, die sorgfältiges Escaping erfordern.

Die richtige langfristige Antwort ist Entwicklerausbildung plus Laufzeitschutz (WAF + Protokollierung). Entwickler sollten sichere Codierungsstandards übernehmen und Wartende sollten Code-Überprüfungen und statische Analyseprüfungen durchführen.

Wie WP‑Firewall hilft

Bei WP-Firewall kümmern wir uns um viele WordPress-Seiten mit einem mehrschichtigen Ansatz:

• Verwaltete WAF mit Signaturen, die speziell auf das WordPress-Ökosystem und die Art der reflektierten XSS-Muster, die in interaktiven Karten-Plugins zu sehen sind, abgestimmt sind.
• Malware-Scans und Anomalieerkennung, um verdächtige Änderungen kurz nach ihrem Auftreten zu erkennen.
• Virtuelles Patchen: Wenn eine Schwachstelle offengelegt wird und Sie nicht sofort aktualisieren können, bietet unser Service vorübergehende Milderungsregeln, die Exploit-Versuche am Rand blockieren.
• Unterstützung nach Vorfällen und Checklisten zur Behebung, um Ihnen zu helfen, schnell und sicher wiederherzustellen.

Erhalten Sie sofortigen Schutz mit WP-Firewall (Kostenloser Plan)

Schützen Sie Ihre Seite jetzt mit dem kostenlosen Plan von WP-Firewall

Wenn Sie ein sofortiges Sicherheitsnetz wünschen, während Sie Plugins aktualisieren, ziehen Sie unseren Basis (Kostenlos) Plan in Betracht. Er bietet wesentliche Schutzmaßnahmen ohne Kosten: eine verwaltete Firewall, unbegrenzte Bandbreite, Regeln für die Webanwendungsfirewall (WAF), Malware-Scans und Milderung, die die OWASP Top 10-Risiken abdeckt. Für viele Seitenbesitzer ist dies eine effektive erste Schicht, während Sie aktualisieren und absichern.

Melden Sie sich hier für den kostenlosen WP‑Firewall-Plan an: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Wenn Sie mehr praktische Hilfe benötigen, fügen unsere kostenpflichtigen Stufen automatische Malware-Entfernung, IP-Blacklistung/Whitelistung, geplante Sicherheitsberichte und automatisches virtuelles Patchen für schwerwiegende Schwachstellen hinzu.

Zusammenfassung der besten Praktiken — Checkliste, die Sie jetzt verwenden können

• Aktualisieren Sie das Plugin auf 1.6.28 (sofort).
• Wenn Sie nicht aktualisieren können:
  • Deaktivieren Sie das Plugin, bis es gepatcht ist, oder
  • Beschränken Sie den Zugriff auf betroffene Seiten, oder
  • Aktivieren Sie eine WAF-Regel, um verdächtige Abfragezeichenfolgen zu blockieren.
• Durchsuchen Sie Protokolle nach verdächtigen Anforderungsmustern und folgen Sie einem Vorfallreaktions-Workflow, wenn Sie Indikatoren finden.
• Erzwingen Sie MFA für Administratorkonten und rotieren Sie Passwörter/Tokens.
• Überwachen Sie ungewöhnliche Administratoraktivitäten und Dateiänderungen.
• Bilden Sie Ihr Team aus: Vermeiden Sie das Klicken auf untrusted Links, während Sie im WordPress-Administrationsbereich angemeldet sind.

Hinweis zur verantwortungsvollen Offenlegung für Plugin-Autoren

Wenn Sie ein WordPress-Plugin pflegen, behandeln Sie alle Benutzereingaben als untrusted und escapen Sie bei der Ausgabe. Bei der Annahme von Beiträgen oder Bewertungen sollten Sie Sicherheitstests einbeziehen, die das Escaping in mehreren Ausgabekontexten (HTML, Attribute, JavaScript, URLs) validieren. Erwägen Sie, eine automatisierte Sicherheits-Testpipeline einzurichten, um gängige Injektionsmuster vor der Veröffentlichung zu erkennen.

Abschluss

Reflektiertes XSS bleibt eine einfache, aber gefährliche Technik, die Angreifer schnell nutzen können, wenn eine Schwachstelle öffentlich ist. Das reflektierte XSS von Interactive Geo Maps (CVE‑2025‑15345) kann durch ein Update auf 1.6.28 behoben werden. Wenn Sie das betroffene Plugin verwenden, aktualisieren Sie sofort und befolgen Sie die Minderungsschritte in diesem Beitrag, während Sie Ihr Update abschließen. Für diejenigen, die viele Seiten verwalten oder nicht sofort aktualisieren können, ziehen Sie in Betracht, eine verwaltete WAF und automatisierte Scans zu aktivieren, um das Risiko zu reduzieren.

Bei WP‑Firewall konzentrieren wir uns auf praktische, mehrschichtige Verteidigungen, die WordPress-Seiten betriebsbereit und sicher halten. Wenn Sie Hilfe bei der Minderung, Überwachung oder Incident Response benötigen, steht unser Team zur Verfügung — und unser kostenloser Basisplan bietet Ihnen eine starke erste Verteidigungslinie, während Sie patchen und absichern.

Weiterführende Lektüre und Ressourcen

• WordPress-Entwicklerhandbuch: Escape- und Sanitizer-Funktionen.
• OWASP XSS-Präventions-Spickzettel (hochrangige Anleitung).
• Site-spezifische Protokolle und Zugriffsprüfer — konsultieren Sie Ihre Hosting- oder Anwendungsprotokolle nach verdächtigen Anfragen.

Wenn Sie Hilfe bei der Implementierung einer der oben genannten Minderungsschritte benötigen oder eine zweite Meinung zur Konfiguration Ihrer Seite wünschen, steht Ihnen unser Team von WordPress-Sicherheitsingenieuren zur Verfügung. Melden Sie sich für den kostenlosen Basisplan von WP‑Firewall an, um schnell verwalteten Firewall-Schutz zu erhalten: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Hinweis: Dieser Beitrag ist informativ und soll den Seiteninhabern helfen, auf die Offenlegung zu reagieren. Die zuverlässigste Abhilfe bleibt das Aktualisieren des Plugins auf die gepatchte Version.