CVE-2026-94504: Ninja Forms XSS wird aktiv ausgenutzt, Angreifer legen unsichtbare Admin-Konten an

Veröffentlicht: 08.10.2026 · Letzte Aktualisierung: 08.10.2026

Was ist passiert

Seit dem 4. Oktober 2026 nutzen Angreifer zwei gespeicherte Cross-Site-Scripting-Lücken in den WordPress-Plugins Ninja Forms und WPC Product Bundles for WooCommerce aktiv aus. Die zugehörigen Schwachstellen CVE-2026-94504 und CVE-2026-93836 wurden bereits am 22. September 2026 veröffentlicht, die ersten Angriffe folgten also rund 12 Tage später.

Beide Lücken erlauben es Angreifern, ohne jede Anmeldung Schadcode in der Website zu hinterlegen: bei Ninja Forms über eine normale Formulareinsendung, bei WPC Product Bundles über manipulierte Bestelldaten. Der Code wartet dann darauf, dass ein Administrator den Eintrag im Backend öffnet.

Das Besondere an dieser Kampagne ist nicht die Lücke selbst, sondern das, was danach kommt. Die Angreifer laden ein spezialisiertes JavaScript-Implantat nach, das im Browser eines eingeloggten Administrators läuft. Es installiert ein getarntes Schadplugin, legt mehrere Administratorkonten an (eines davon im Dashboard unsichtbar) und richtet einen Dateimanager ein, der ganz ohne Login erreichbar ist. Die Sicherheitsfirma Patchstack hat die Kampagne am 6. Oktober 2026 detailliert dokumentiert, BleepingComputer berichtete am selben Tag.

Wenn Sie Ninja Forms oder WPC Product Bundles einsetzen, sollten Sie diesen Artikel bis zum Ende lesen. Sie erfahren, wie der Angriff abläuft, woran Sie eine Kompromittierung erkennen und welche Schritte jetzt nötig sind.

Die beiden Schwachstellen im Detail

CVE-2026-94504 in Ninja Forms

CVE-2026-94504 ist eine unauthentifizierte Stored-XSS-Schwachstelle in Ninja Forms bis einschließlich Version 3.15.3, behoben in Version 3.15.4. Das Plugin ist mit über 500.000 aktiven Installationen eines der meistgenutzten Formular-Plugins für WordPress.

Die Lücke steckt im Umgang mit Textarea-Feldern: Ninja Forms speichert Formulareinsendungen, ohne bestimmte Feldinhalte beim späteren Anzeigen im älteren administrativen Einsendungs-Editor sauber zu kodieren. Ein Angreifer schickt also ganz normal ein Formular ab, ohne Login, und platziert darin JavaScript-Code. Sobald ein Administrator die Einsendung im Backend öffnet, wird der Code im Kontext von wp-admin ausgeführt.

Die CVSS-Einstufung von 7.1 („hoch“) unterzeichnet die reale Gefahr. Der Wert misst die technische Schwere der Lücke, nicht die Folgen der laufenden Kampagne. Entscheidend ist: Das eingeschleuste Skript läuft im Browser eines angemeldeten Administrators und erbt damit dessen komplette Rechte. Es kann Plugins installieren, Benutzer anlegen und Einstellungen ändern, alles über die reguläre, authentifizierte Session. Faktisch steht am Ende die vollständige Übernahme der Website, ein Ergebnis, das man sonst mit Einstufungen von 9 oder höher verbindet.

CVE-2026-93836 in WPC Product Bundles

CVE-2026-93836 ist ebenfalls eine unauthentifizierte Stored-XSS-Schwachstelle mit CVSS 7.1 und betrifft WPC Product Bundles for WooCommerce bis einschließlich Version 8.6.6, behoben in Version 8.6.7. Das Plugin hat über 30.000 aktive Installationen und wird in WooCommerce-Shops für Produkt-Bundles eingesetzt.

Für WooCommerce-Shops ist diese Variante besonders tückisch, weil der Auslöser mitten im Tagesgeschäft liegt. Bestellungen prüfen gehört in jedem Shop zur täglichen Routine, und genau dieser Blick in die Bestellansicht startet den Angriff.

Hier wandert die Schadnutzlast in die Bestellmetadaten von WooCommerce: Ein Mengen-Parameter akzeptiert Werte, die mit einer gültigen Zahl beginnen, aber zusätzliches Markup enthalten. Dieser Wert wird in den Bestelldaten gespeichert und später ungesichert gerendert. Öffnet ein Shop-Betreiber oder Mitarbeiter die manipulierte Bestellung im Backend, führt der Browser das eingebettete Skript aus.

Warum Stored XSS in Formular-Plugins besonders gefährlich ist

Stored XSS in Formular- und Shop-Plugins ist deshalb so wirksam, weil der Angreifer die Nutzlast ohne jede Anmeldung hinterlegen kann und das Opfer sie im Rahmen seiner täglichen Arbeit selbst auslöst. Formulareinsendungen und Bestellungen anzusehen gehört zur Routine jedes Website- und Shop-Betreibers.

Anders als bei reflektiertem XSS muss der Angreifer sein Opfer also nicht auf einen präparierten Link locken. Die Nutzlast wartet geduldig in der Datenbank, bis sie geöffnet wird. Der Angriff skaliert zudem hervorragend: Ein Skript kann tausende verwundbare Websites automatisiert mit Einsendungen befüllen und muss danach nur abwarten. Patchstack beobachtete in dieser Kampagne genau dieses Muster, dieselbe zentrale Nutzlast wurde über zwei völlig unabhängige Plugins ausgeliefert, jeweils angepasst an den verwundbaren Kontext.

Dazu kommt ein technischer Punkt: Das Schadskript muss keine Cookies stehlen. Es läuft im selben Ursprung wie wp-admin, jede Anfrage trägt automatisch die gültige Session des Administrators. Schutzmechanismen wie HttpOnly-Cookies greifen hier nicht, denn das Skript liest das Cookie nie aus. Es reitet schlicht auf der bestehenden Sitzung mit und sammelt die CSRF-Nonces, die WordPress für administrative Aktionen verlangt, direkt aus den geladenen Backend-Seiten ein.

Die Angriffskette Schritt für Schritt

Die von Patchstack dokumentierte Kampagne läuft bei beiden Schwachstellen auf dieselbe zweite Stufe hinaus. Das nachgeladene Skript ist kein Proof-of-Concept und kein Scanner, sondern ein ausgereiftes Post-Exploitation-Implantat, das seinen Fortschritt lokal im Browser speichert (Local-Storage-Präfix __xp_v9_) und sich mit dem Kontrollserver abstimmt, damit bereits erledigte Stufen nicht wiederholt werden. Der Ablauf im Einzelnen:

1. Nutzlast einschleusen. Der Angreifer hinterlegt die Nutzlast unauthentifiziert, entweder als Formulareinsendung über den regulären Ninja-Forms-AJAX-Endpunkt oder in den Bestellmetadaten eines WooCommerce-Shops über den manipulierten Mengen-Parameter von WPC Product Bundles.
2. Admin löst das Skript aus. Ein Administrator öffnet die Einsendung oder Bestellung im Backend. Dabei wird das Skript x.js (19.378 Bytes) von der Angreifer-Domain imgcdn1.com unter dem Pfad /fz/x.js nachgeladen und läuft im Admin-Kontext.
3. C2-Check-in und Plugin-Installation. Das Skript meldet sich beim Kontrollserver unter /fz/c.php (Parameter xa=check, xa=pkg, xa=admin_creds) und installiert über den regulären WordPress-Plugin-Installer ein Schadplugin mit dem Slug wp-smart-thumbnails. Es tarnt sich als „WP Smart Thumbnails 1.2.4“ von „MediaPress Labs“, einem angeblichen Thumbnail-Caching-Plugin.
4. Zwei Administratorkonten. Das Skript legt über user-new.php einen sichtbaren Administrator an. Zusätzlich entsteht ein versteckter Administrator, der über ein Must-Use-Plugin aus der Benutzerliste, den Filtern und den Benutzerzählern ausgeblendet wird. Im Dashboard ist dieses Konto nicht zu sehen.
5. Backdoor-Login und Dateimanager. Die Malware richtet einen Magic-Login-Link ein (/wp-login.php?_wplogin=TOKEN), der eine Anmeldung ohne Passwort erlaubt, sowie einen unauthentifizierten Dateimanager, dessen Webshell im Quelltext den Titel „Moon, tell me if I could“ trägt.

Vier Wege zurück: die Persistenz verstehen

Die Kampagne verlässt sich nicht auf einen einzelnen Zugang, sondern baut vier voneinander unabhängige Wege zurück in die Website. Wer nur einen davon entfernt, bleibt kompromittiert.

• Sichtbarer Administrator: ein regulär angelegtes Adminkonto, das in der Benutzerliste auftaucht. Es ist der auffälligste der vier Wege und dient vermutlich auch als Ablenkung.
• Versteckter Administrator: ein zweites Adminkonto mit unauffälligem Benutzernamen aus harmlosen Wörtern wie support oder backup und einer E-Mail-Adresse auf @wordpress.org. Ein Must-Use-Plugin filtert dieses Konto aus der Benutzerliste, den Rollenfiltern und den Zählern heraus. Im Dashboard sehen Sie es nicht, nur in der Datenbank.
• Magic-Login-Link: ein Token-basierter Direktlogin über /wp-login.php?_wplogin=TOKEN, der den Angreifer als bestehenden Administrator anmeldet, ganz ohne Passwort.
• Unauthentifizierter Dateimanager: eine Webshell im Schadplugin, die ohne Login erreichbar ist und vollen Dateizugriff bietet.

Dazu kommt ein Detail, das viele Prüfroutinen aushebelt: Die Malware datiert ihre Dateien auf den ältesten Zeitstempel der WordPress-Installation zurück. Eine Suche nach kürzlich geänderten Dateien, der Klassiker jeder manuellen Prüfung, findet deshalb nichts.

Diese Redundanz ist kein Zufall, sondern Kalkül. Die Angreifer rechnen damit, dass ein Teil ihrer Zugänge entdeckt wird. Der sichtbare Administrator fällt bei der ersten Durchsicht auf und wird gelöscht, der Betreiber wiegt sich in Sicherheit, und der Angreifer kommt über einen der drei verbliebenen Wege zurück. Genau deshalb ist bei dieser Kampagne eine vollständige Prüfung aller vier Mechanismen nötig, bevor eine Website wieder als sauber gelten kann.

Wer ist betroffen

Betroffen ist jede WordPress-Website mit Ninja Forms bis Version 3.15.3 und jeder WooCommerce-Shop mit WPC Product Bundles bis Version 8.6.6. Ob die Lücke bei Ihnen bereits ausgenutzt wurde, hängt davon ab, ob eine präparierte Einsendung oder Bestellung eingegangen ist und ob ein Administrator sie im Backend geöffnet hat.

Das Risiko steigt mit der Frequenz, in der Ihr Team das Backend durchsieht. Wer täglich Formulareinsendungen und Bestellungen prüft, löst eine hinterlegte Nutzlast schneller aus als eine Website, deren Backend selten geöffnet wird. Gerade gepflegte, aktiv betreute Shops sind hier paradoxerweise im Nachteil.

Agenturen mit mehreren Kundeninstallationen sollten alle betreuten Sites systematisch prüfen, nicht nur die, bei denen ein Verdacht besteht. Einen Überblick über grundlegende Absicherung finden Sie auf unserer Seite zur WordPress-Sicherheit.

Timeline

Datum	Ereignis
22.09.2026	CVE-2026-94504 und CVE-2026-93836 werden veröffentlicht
01.10.2026	Registrierung der Angreifer-Domain imgcdn1.com
02.10.2026	Delegation der Domain an Cloudflare-Nameserver
04.10.2026	Erste beobachtete Ausnutzung von CVE-2026-93836, früheste Anfrage um 10:39 UTC
05.10.2026	Dieselbe Nutzlast wird über die Ninja-Forms-Lücke CVE-2026-94504 ausgeliefert
06.10.2026	Patchstack veröffentlicht die Analyse, BleepingComputer berichtet
08.10.2026	Stand dieses Artikels, die Kampagne läuft weiter

Sofortmaßnahmen

Schritt 1: Updates einspielen

Aktualisieren Sie Ninja Forms auf Version 3.15.4 und WPC Product Bundles for WooCommerce auf Version 8.6.7. Das schließt die Einfallstore und stoppt neue Ausnutzungsversuche.

Wichtig: Das Update bereinigt keine bestehende Infektion. Wenn die Nutzlast bereits ausgelöst wurde, sind Schadplugin, versteckter Administrator, Magic-Login-Link und Dateimanager weiterhin aktiv. Die Schritte 2 bis 5 sind deshalb keine Kür, sondern Pflicht.

Schritt 2: Prüfen, ob Sie betroffen sind

Durchsuchen Sie Ihre Server-Zugriffslogs nach der Angreifer-Infrastruktur: der Domain imgcdn1.com sowie den Pfaden /fz/x.js und /fz/c.php. Prüfen Sie außerdem Anfragen mit dem Parameter _wplogin an wp-login.php und Aufrufe von Dateien unterhalb von wp-smart-thumbnails.

Ein pragmatischer Einstieg auf der Shell (Logpfad an Ihren Server anpassen, bitte vor Einsatz prüfen):

grep -r "imgcdn1" /var/log/nginx/access.log*
grep "_wplogin" /var/log/nginx/access.log*
grep "wp-smart-thumbnails" /var/log/nginx/access.log*

Prüfen Sie zusätzlich alle Administratorkonten direkt in der Datenbank, nicht im Dashboard, denn das versteckte Konto taucht dort nicht auf. Mit WP-CLI (Befehl bitte in Ihrer Umgebung prüfen):

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Oder als SQL-Abfrage direkt auf wp_users und wp_usermeta (Tabellen-Präfix anpassen, bitte prüfen):

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%';

Jedes Konto, das Sie in dieser Liste nicht eindeutig zuordnen können, ist ein Alarmsignal. Achten Sie besonders auf unauffällige Benutzernamen wie support oder backup in Kombination mit einer E-Mail-Adresse auf @wordpress.org, dieses Muster nutzt die Kampagne für ihr verstecktes Konto. Werfen Sie außerdem einen Blick in das Verzeichnis wp-content/mu-plugins: Must-Use-Plugins laufen automatisch und tauchen nicht in der normalen Plugin-Liste auf.

Falls Ihr Hoster keine Roh-Logs bereitstellt, prüfen Sie alternativ die Formulareinsendungen in Ninja Forms und die jüngeren Bestellungen in WooCommerce auf eingebettetes Markup wie script-Tags oder img-Tags mit onerror-Attribut. Eine Einsendung, die HTML-Fragmente statt normalem Text enthält, ist ein deutlicher Hinweis auf einen Ausnutzungsversuch. Öffnen Sie solche Einträge nicht im Backend, solange die Plugins nicht aktualisiert sind, sonst lösen Sie die Nutzlast selbst aus.

Schritt 3: Indicators of Compromise abgleichen

Die folgenden Indikatoren stammen aus der Patchstack-Analyse vom 6. Oktober 2026:

Indikator	Details
x.js (Implantat)	19.378 Bytes · SHA-256 af803bc822cf9596b1f1785e1d59642f91f6fbc21f8e9943feefa19a6df8c2a4 · MD5 8a4413c1aa058179ff54b95571bcf2a3
wp-smart-thumbnails.php	SHA-256 ccc95113334357c2a3671aae12043bff00020858cec115f7e724fe43e9f1fc24 · MD5 da651d4f191a7c363806fe5357752015
emer-run.php	SHA-256 ed00234ad2b67dbbc9073e8c711b18b7d39e0a5255b6159189f75cf2ed99cfb9 · MD5 1024732009983dd5e54b4cf5593f04d4
Dateipfade	/wp-content/plugins/wp-smart-thumbnails/ · /wp-content/mu-plugins/class-wp-query-[8 Hex-Zeichen].php · /wp-content/mu-plugins/class-wp-token-validate.php
WordPress-Optionen	fz_emer_done_v1 · fz_emer_login_tokens
Weitere Merkmale	Stream-Wrapper dyiv:// · Local-Storage-Präfix __xp_v9_
Quell-IPs 04.10.	204.8.96.109 · 147.90.235.22 · 90.184.10.74 · 94.16.115.121
Quell-IP 05.10.	43.250.53.42

Vier der fünf beobachteten Quelladressen sind Tor-Exit-Nodes. Das Blockieren dieser IPs ist deshalb keine dauerhafte Maßnahme, die Angreifer wechseln die Adressen jederzeit.

Die Reputation verdächtiger Adressen wie dieser können Sie mit reportedIP prüfen und eigene Angriffe dort melden. reportedIP ist eine offene Threat-Intelligence-Plattform aus Deutschland, die Angreifer-IPs aus einem Community-Netzwerk sammelt, mit einem Confidence-Score bewertet und über ein WordPress-Plugin sowie eine API zum Blockieren bereitstellt. Die Detailseiten zu den fünf Adressen dieser Kampagne: 204.8.96.109, 147.90.235.22, 90.184.10.74, 94.16.115.121 und 43.250.53.42.

Wenn Sie bekannte Angreifer-Adressen nicht nur prüfen, sondern automatisch abwehren wollen, hilft eine Web Application Firewall auf WordPress-Ebene. Wie das in der Praxis funktioniert und wie das reportedIP-Plugin Hive gemeldete IPs schon vor dem Login-Formular stoppt, beschreibt der Beitrag WordPress-Firewall (WAF): wie Hive Angriffe abwehrt.

Schritt 4: Bereinigen

Entfernen Sie das Schadplugin unter /wp-content/plugins/wp-smart-thumbnails/ vollständig. Löschen Sie anschließend die beiden Dateien im mu-plugins-Verzeichnis: class-wp-token-validate.php und die Datei nach dem Muster class-wp-query-[8 Hex-Zeichen].php.

Suchen Sie dabei nach Inhalt, nicht nach Datum. Die Malware datiert ihre Dateien zurück, eine Sortierung nach Änderungsdatum führt ins Leere. Prüfen Sie jede Datei in mu-plugins inhaltlich, das Verzeichnis ist bei den meisten Installationen klein genug dafür.

Löschen Sie danach die WordPress-Optionen fz_emer_done_v1 und fz_emer_login_tokens aus der Datenbank, sie steuern den Magic-Login-Mechanismus. Entfernen Sie zuletzt alle Administratorkonten, die Sie nicht eindeutig zuordnen können, den sichtbaren wie den versteckten.

Schritt 5: Zugangsdaten rotieren

Setzen Sie die Passwörter aller Administratoren neu und erneuern Sie die Security-Salts in der wp-config.php. Neue Salts machen alle bestehenden Login-Cookies ungültig und werfen damit auch den Angreifer aus laufenden Sessions. Neue Salts erzeugen Sie über den offiziellen Generator von WordPress.org oder per WP-CLI mit wp config shuffle-salts (Befehl bitte in Ihrer Umgebung prüfen).

Das Passwort des ältesten Administratorkontos gilt als kompromittiert: Der Magic-Login-Link der Kampagne authentifiziert sich gezielt als ursprünglicher Seiteninhaber. Behandeln Sie dieses Konto mit besonderer Priorität.

Wenn Sie bei der Prüfung auf Indikatoren gestoßen sind und sich die vollständige Bereinigung nicht zutrauen: Unser Team übernimmt die Bereinigung gehackter WordPress-Websites, inklusive Ursachenanalyse und Absicherung gegen Wiederholung.

Einschätzung von CMS ADMINS

Drei Punkte an dieser Kampagne verdienen besondere Aufmerksamkeit.

Erstens: Die 12-Tage-Lücke trifft genau die Monats-Patcher. Zwischen Veröffentlichung der CVEs am 22. September und der ersten Ausnutzung am 4. Oktober lagen rund 12 Tage. Wer Updates in einem monatlichen Wartungsfenster einspielt, war in diesem Fall rechnerisch zu langsam. Eine laufende WordPress-Wartung mit kurzen Update-Zyklen ist kein Komfortthema, sondern verkürzt genau dieses Zeitfenster.

Zweitens: CVSS 7.1 steuert Prozesse in die falsche Richtung. Viele Update-Prozesse priorisieren nach Einstufung und schieben alles unter 9.0 auf „später“. Diese Kampagne zeigt, dass die Einstufung allein kein Priorisierungskriterium ist. Entscheidend sind Ausnutzbarkeit ohne Login, aktive Ausnutzung und die Folgen im Erfolgsfall. Alle drei Kriterien sprechen hier für sofortiges Handeln.

Drittens: Vier Persistenzwege machen die Bereinigung zur Fachaufgabe. Wer nur das auffällige Adminkonto löscht und das Plugin deinstalliert, lässt drei Hintertüren offen. Eine Website, auf der das XSS nachweislich ausgelöst wurde, gilt als potenziell vollständig kompromittiert und braucht eine systematische Prüfung aller vier Wege. Für Agenturen mit vielen Kundeninstallationen heißt das: Checkliste statt Einzelfallprüfung, und zwar über den gesamten Bestand.

Häufige Fragen

Bin ich betroffen, wenn ich Ninja Forms nur für ein Kontaktformular nutze?

Ja, ein einzelnes Kontaktformular genügt für die Ausnutzung. Die Lücke steckt in der Verarbeitung der Formulareinsendungen, nicht in einer bestimmten Formular-Funktion. Sobald ein Angreifer eine präparierte Einsendung abschickt und ein Administrator sie im Backend öffnet, läuft das Schadskript. Aktualisieren Sie deshalb auch bei minimaler Nutzung auf Version 3.15.4.

Wie finde ich ein verstecktes Administratorkonto in WordPress?

Über die Datenbank, nicht über das Dashboard. Das versteckte Konto wird per Must-Use-Plugin aus der Benutzerliste gefiltert, eine Abfrage auf wp_users und wp_usermeta nach der Rolle administrator zeigt es dagegen zuverlässig an (Beispielabfrage in Schritt 2 dieses Artikels). Vergleichen Sie das Ergebnis mit der Benutzerliste im Dashboard: Jede Differenz ist ein starkes Kompromittierungssignal. Prüfen Sie zusätzlich das Verzeichnis wp-content/mu-plugins auf Dateien, die Sie nicht kennen.

Reicht das Update auf Ninja Forms 3.15.4 zur Bereinigung aus?

Nein, das Update schließt nur das Einfallstor. Eine bereits ausgelöste Infektion bleibt vollständig bestehen: Schadplugin, verstecktes Adminkonto, Magic-Login-Link und Dateimanager funktionieren nach dem Update unverändert weiter. Nach dem Update müssen Sie deshalb die Prüf- und Bereinigungsschritte aus diesem Artikel durchgehen und die Zugangsdaten rotieren.

Woran erkenne ich das Schadplugin wp-smart-thumbnails?

Am Verzeichnis /wp-content/plugins/wp-smart-thumbnails/ und an der Tarnidentität „WP Smart Thumbnails 1.2.4“ von „MediaPress Labs“ in der Plugin-Liste. Ein legitimes Plugin dieses Namens gibt es in dieser Form nicht, es handelt sich um eine reine Tarnung. Verlassen Sie sich nicht auf Dateidaten, die Malware datiert ihre Dateien auf den ältesten Zeitstempel der Installation zurück. Die SHA-256- und MD5-Prüfsummen der Dateien finden Sie in der IoC-Tabelle oben.

Muss ich meine WordPress-Salts wirklich neu setzen?

Ja, bei jedem Verdacht auf diese Kampagne. Die Salts in der wp-config.php sichern die Login-Cookies ab, neue Salts invalidieren sämtliche bestehenden Sessions, auch die des Angreifers. Da der Magic-Login-Link der Kampagne sich als bestehender Administrator authentifiziert, reichen neue Passwörter allein nicht aus, solange alte Sessions weiterlaufen. Der Austausch ist in wenigen Minuten erledigt und hat keine Nebenwirkungen außer einem einmaligen Neu-Login aller Benutzer.

Wie verhindere ich, dass mich die nächste XSS-Kampagne trifft?

Mit kurzen Update-Zyklen, wenigen gut gewählten Plugins und mehreren Verteidigungsebenen. Spielen Sie Sicherheitsupdates innerhalb von Tagen ein, nicht in Monatsfenstern, und entfernen Sie Plugins, die Sie nicht aktiv nutzen. Als zusätzliche Ebene lohnt sich IP-Reputation: Plattformen wie reportedIP gleichen eingehende Anfragen gegen ein Community-Netzwerk bekannter Angreifer-Adressen ab und blockieren auffällige IPs, bevor diese Formulare oder Login-Seiten erreichen. Wer die Prüf- und Update-Routine nicht selbst leisten kann, gibt sie an einen Wartungsdienstleister ab.

Fazit

Die aktuelle Kampagne gegen Ninja Forms und WPC Product Bundles zeigt, wie schnell aus einer mittelhoch eingestuften XSS-Lücke eine vollständige Seitenübernahme mit vier Hintertüren wird. Spielen Sie die Updates auf Ninja Forms 3.15.4 und WPC Product Bundles 8.6.7 jetzt ein und prüfen Sie anschließend Administratorkonten, mu-plugins und Zugriffslogs gegen die Indikatoren aus diesem Artikel. Das Update allein genügt nicht, wenn die Nutzlast bereits ausgelöst wurde. Wenn Sie Updates und Sicherheitsprüfungen dauerhaft abgeben möchten, übernimmt unsere WordPress-Wartung genau diese Arbeit, mit Update-Zyklen, die deutlich unter dem 12-Tage-Fenster dieser Kampagne liegen.

Quellen: Patchstack: Four ways back in (06.10.2026) · BleepingComputer: Ninja Forms plugin flaw exploited (06.10.2026)