Eine neue Kirki Sicherheitslücke ermöglicht unter bestimmten Voraussetzungen Stored Cross-Site Scripting (XSS), ohne dass ein Angreifer bereits über ein WordPress-Benutzerkonto verfügen muss. Die Schwachstelle wird als CVE-2026-102173 geführt und hat einen CVSS-Score von 7,2 High.

Kirki wird laut WordPress.org auf mehr als 500.000 WordPress-Installationen aktiv eingesetzt. Betroffen sind Kirki-Versionen bis einschließlich 6.3.1. Die Sicherheitskorrektur ist in Version 6.3.2 enthalten.

Was ist die Kirki Sicherheitslücke CVE-2026-102173?

Kirki ist ein weit verbreitetes WordPress-Plugin und Framework für Website- und Theme-Entwicklung. Es bietet unter anderem Customizer-Funktionen, visuelle Website-Entwicklung, dynamische Inhalte, Formulare und weitere Komponenten für WordPress-Websites.

Kirki wird außerdem von WordPress-Themes als technisches Framework verwendet. Dadurch kann die Komponente auch auf Websites vorhanden sein, auf denen der Website-Betreiber Kirki nicht bewusst als eigenständiges Werkzeug einsetzt.

CVE-2026-102173 ist eine Stored-Cross-Site-Scripting-Schwachstelle in der Verarbeitung bestimmter Registrierungs- und Benutzerdaten.

Nach den veröffentlichten technischen Informationen werden bestimmte Benutzermetadaten nicht ausreichend bereinigt, bevor sie in einem HTML-Bildelement verarbeitet werden.

Welche Kirki-Versionen sind betroffen?

• Kirki 6.3.1 und älter – verwundbar
• Kirki 6.3.2 und neuer – Sicherheitskorrektur enthalten

Die Schwachstelle wird als CVE-2026-102173 geführt und hat einen CVSS-3.1-Score von 7,2 High.

Vservs empfiehlt, nicht dauerhaft bei einer verwundbaren Kirki-Version zu bleiben und die aktuellste stabile Version zu installieren.

Wie funktioniert die Stored-XSS-Schwachstelle?

Die Schwachstelle befindet sich in der Verarbeitung von Benutzermetadaten innerhalb eines Bildelements.

Unter bestimmten Bedingungen kann ein vom Benutzer kontrollierter Wert unzureichend bereinigt in das src-Attribut eines HTML-Bildelements gelangen.

Dadurch kann ein Angreifer speziell präparierte Daten speichern, die beim späteren Aufruf einer betroffenen Seite zur Ausführung von JavaScript im Browser führen können.

Man spricht von Stored Cross-Site Scripting, weil die schädliche Eingabe zunächst innerhalb der WordPress-Installation gespeichert und erst bei einem späteren Seitenaufruf verarbeitet wird.

Dies unterscheidet Stored XSS von Reflected XSS, bei dem eine schädliche Payload normalerweise unmittelbar über einen manipulierten Request an ein Opfer übermittelt wird.

Wann kann CVE-2026-102173 ausgenutzt werden?

Nicht jede WordPress-Website mit einer verwundbaren Kirki-Version ist automatisch über CVE-2026-102173 angreifbar.

Für den beschriebenen Angriffsweg müssen zusätzliche Voraussetzungen erfüllt sein:

• Die Website verwendet Kirki 6.3.1 oder älter.
• Die öffentliche WordPress-Benutzerregistrierung ist aktiviert.
• Eine veröffentlichte Seite enthält ein kirki-register-Element.
• Eine Kirki-Benutzercollection stellt ein Bildelement dar, das mit einem der betroffenen Registrierungsfelder verknüpft ist.

Sind diese Voraussetzungen erfüllt, kann ein externer Angreifer versuchen, über den Registrierungsprozess speziell präparierte Daten zu speichern.

Ein bereits vorhandenes WordPress-Benutzerkonto ist für diesen Angriffspfad nicht erforderlich.

Welche Auswirkungen kann Stored XSS haben?

Bei erfolgreicher Ausnutzung kann vom Angreifer kontrollierter JavaScript-Code innerhalb des Sicherheitskontexts der betroffenen WordPress-Website ausgeführt werden.

Abhängig davon, welcher Benutzer die manipulierte Seite aufruft und welche Funktionen dort verfügbar sind, können sich unterschiedliche Auswirkungen ergeben.

Mögliche Folgen sind unter anderem:

• Manipulation der dargestellten Website-Inhalte;
• Ausführung unerwünschter JavaScript-Aktionen;
• Einblenden manipulierter Inhalte oder Formulare;
• Zugriff auf Informationen, die innerhalb des Browserkontexts verfügbar sind;
• Ausführung unerwünschter Aktionen innerhalb einer bestehenden Benutzersitzung, sofern die jeweiligen Voraussetzungen erfüllt sind.

Eine Stored-XSS-Schwachstelle bedeutet nicht automatisch, dass ein Angreifer vollständigen Zugriff auf WordPress oder den zugrunde liegenden Webserver erhält.

Die tatsächliche Auswirkung hängt davon ab, in welchem Kontext die gespeicherte Payload ausgeführt wird und welche Rechte der betroffene Benutzer besitzt.

Mehr als 500.000 aktive Kirki-Installationen

Kirki hat laut offizieller WordPress Plugin Directory mehr als 500.000 aktive Installationen.

Damit gehört das Plugin beziehungsweise Framework zu den weit verbreiteten WordPress-Komponenten.

Die hohe Zahl aktiver Installationen bedeutet nicht, dass alle diese Websites tatsächlich die für CVE-2026-102173 erforderliche Konfiguration verwenden.

Die Kombination aus einer großen Installed Base, einer öffentlich bekannten Schwachstelle und einer verfügbaren Sicherheitsaktualisierung macht ein zeitnahes Update dennoch wichtig.

Wird CVE-2026-102173 aktiv ausgenutzt?

Zum Zeitpunkt dieser Veröffentlichung hat Vservs keine zuverlässige öffentliche Bestätigung gefunden, dass CVE-2026-102173 aktiv in freier Wildbahn ausgenutzt wird.

Die Veröffentlichung technischer Details zu einer Schwachstelle ist nicht mit bestätigter aktiver Exploitation gleichzusetzen.

Vservs spricht deshalb nicht von einer laufenden Angriffskampagne, solange dies nicht durch zuverlässige Security-Quellen eindeutig bestätigt wird.

Da die Schwachstelle öffentlich bekannt und eine korrigierte Version verfügbar ist, sollte das Update dennoch ohne unnötige Verzögerung installiert werden.

Kirki sofort auf Version 6.3.2 oder neuer aktualisieren

Die Sicherheitskorrektur ist in Kirki 6.3.2 enthalten.

WordPress.org bestätigt für Version 6.3.2 mehrere Sicherheitsverbesserungen, darunter Korrekturen im Zusammenhang mit sensiblen Metadaten.

WordPress-Administratoren können die installierte Version über folgende Stelle kontrollieren:

WordPress Dashboard → Plugins → Installierte Plugins

Ist Kirki 6.3.1 oder älter installiert, sollte die Komponente auf mindestens Version 6.3.2 beziehungsweise auf die aktuellste verfügbare stabile Version aktualisiert werden.

Erstellen beziehungsweise kontrollieren Sie vor dem Update ein aktuelles Backup der Website und Datenbank.

Wird Kirki durch ein Theme oder andere Website-Komponenten verwendet, sollten nach dem Update insbesondere Customizer-, Formular-, Registrierungs- und Frontend-Funktionen getestet werden.

Öffentliche WordPress-Benutzerregistrierung kontrollieren

Da eine öffentlich erreichbare Benutzerregistrierung zu den Voraussetzungen für den beschriebenen Angriff gehört, sollte diese WordPress-Einstellung ebenfalls überprüft werden.

Sie finden die Einstellung unter:

WordPress Dashboard → Einstellungen → Allgemein

Prüfen Sie dort, ob sich Besucher selbst als Benutzer registrieren können.

Wird eine öffentliche Registrierung für die Website nicht benötigt, sollte sie deaktiviert werden.

Websites, die Benutzerregistrierung für Membership-, Community- oder andere Funktionen benötigen, sollten diese Funktion nicht allein wegen der Schwachstelle entfernen. Entscheidend ist in diesem Fall, Kirki auf eine sichere Version zu aktualisieren.

Das Deaktivieren der Registrierung ist lediglich eine mögliche zusätzliche Risikoreduzierung und kein Ersatz für das Sicherheitsupdate.

Website auf mögliche Exploitation prüfen

Websites, auf denen Kirki 6.3.1 oder älter mit der betroffenen Konfiguration aktiv war, können zusätzlich auf auffällige Registrierungs- und Benutzerdaten untersucht werden.

Kontrollieren Sie unter anderem:

• unbekannte Benutzerkonten, die während des betroffenen Zeitraums angelegt wurden;
• ungewöhnliche HTML- oder JavaScript-Inhalte in Registrierungsfeldern;
• auffällige Werte innerhalb von Benutzermetadaten;
• ungewöhnliche Registrierungsrequests in Webserver- oder WAF-Logs;
• veröffentlichte Seiten, die ein kirki-register-Element verwenden;
• Kirki-Benutzercollections, in denen Registrierungsdaten als Bild dargestellt werden;
• unerwartete JavaScript-Ausführung auf betroffenen Seiten.

Ein ungewöhnlicher Registrierungsrequest allein ist kein Beweis für eine erfolgreiche Stored-XSS-Exploitation.

Verdächtige Requests sollten mit tatsächlich gespeicherten Benutzerdaten, Website-Inhalten und Browseraktivitäten abgeglichen werden.

Kirki-Version mit WP-CLI kontrollieren

Administratoren mit Zugriff auf WP-CLI können die installierte Kirki-Version beispielsweise mit folgendem Befehl kontrollieren:

wp plugin get kirki --field=version

Ob die öffentliche WordPress-Registrierung aktiviert ist, lässt sich überprüfen mit:

wp option get users_can_register

Ein Wert von 1 bedeutet normalerweise, dass die öffentliche Benutzerregistrierung aktiviert ist.

Diese Befehle helfen bei der Konfigurationskontrolle, ersetzen jedoch keine vollständige Sicherheitsanalyse.

Ein Update entfernt keine bereits gespeicherte XSS-Payload

Bei Stored XSS ist zu beachten, dass eine bereits erfolgreich gespeicherte schädliche Payload nach der Installation eines Sicherheitsupdates weiterhin in der Datenbank vorhanden sein kann.

Das Update auf Kirki 6.3.2 oder neuer verhindert die weitere Ausnutzung über den korrigierten Codepfad, entfernt aber nicht automatisch jede zuvor gespeicherte verdächtige Benutzereingabe.

Gibt es Hinweise auf eine erfolgreiche Ausnutzung, sollten deshalb zusätzlich die betreffenden Benutzerkonten, Benutzermetadaten und Kirki-Inhalte kontrolliert werden.

Prüfen Sie anschließend, ob die betroffenen Seiten keine unerwarteten Scripts oder manipulierten Inhalte mehr ausführen beziehungsweise anzeigen.

Managed WordPress Hosting bei Vservs

Die Kirki Sicherheitslücke zeigt erneut, dass WordPress-Sicherheit nicht bei WordPress Core endet. Gerade weit verbreitete Plugins, Theme-Frameworks und Website-Builder bilden einen wichtigen Teil der Angriffsfläche einer WordPress-Website.

Mit Vservs Managed WordPress übernehmen wir unter anderem WordPress-Core-, Plugin- und Theme-Updates, Security Hardening, Monitoring, Malwarekontrollen, Backups, SSL und das technische WordPress-Management.

Für geschäftskritische WordPress-Websites und WooCommerce-Webshops stehen zusätzlich umfangreichere Managed-WordPress-Lösungen mit eigener VPS-Umgebung und erweitertem technischen Management zur Verfügung.

Zusammenfassung

• Software: Kirki – Freeform Page Builder, Website Builder & Customizer
• Entwickler: Themeum
• CVE: CVE-2026-102173
• Schwachstelle: Stored Cross-Site Scripting
• CVSS: 7,2 – High
• Aktive Installationen: mehr als 500.000
• Betroffene Versionen: Kirki 6.3.1 und älter
• Erste korrigierte Version: Kirki 6.3.2
• Authentifizierung: kein bereits bestehendes Benutzerkonto erforderlich, wenn die beschriebenen Voraussetzungen erfüllt sind
• Voraussetzungen: unter anderem öffentliche Registrierung und betroffene Kirki-Elemente
• Aktive Ausnutzung: zum Zeitpunkt der Veröffentlichung nicht bestätigt
• Empfehlung: sofort aktualisieren und die öffentliche Benutzerregistrierung kontrollieren

Quellen

• Wordfence Intelligence – CVE-2026-102173
• WordPress.org – Kirki Plugin Directory und Changelog
• CVE Program – CVE-2026-102173

Eine kritische Payload CMS SQL-Injection ermöglicht es Angreifern unter bestimmten Bedingungen, Datenbankabfragen ohne ein bereits vorhandenes Benutzerkonto zu manipulieren. Die Schwachstelle wird als CVE-2026-105845 geführt und hat einen CVSS-Score von 9,8 Critical.

Betroffen sind Payload CMS-Installationen mit PostgreSQL oder SQLite, wenn nicht vertrauenswürdige Benutzer lesbare Collections über dynamische Filter oder Joins abfragen können. Die Schwachstelle wurde in Payload CMS 3.88.0 sowie 4.0.0-canary.27 behoben.

Was ist die Payload CMS SQL-Injection CVE-2026-105845?

Payload CMS ist ein Open-Source Headless Content Management System, das unter anderem für Websites, Webanwendungen, APIs und individuell entwickelte Plattformen eingesetzt wird.

Im Gegensatz zu klassischen Content-Management-Systemen wie WordPress oder Joomla wird Payload häufig direkt in eine Node.js-Anwendung integriert und mit einer separaten Datenbank verbunden.

CVE-2026-105845 ist eine SQL-Injection-Schwachstelle in der Verarbeitung bestimmter Datenbankabfragen.

Nach Angaben der offiziellen Security Advisory kann ein nicht vertrauenswürdiger Benutzer, der lesbare Collections über dynamische Filter oder Joins abfragen darf, speziell präparierte Requests senden, die eine SQL-Injection in den SQLite- und PostgreSQL-Adaptern auslösen können.

Welche Payload CMS-Versionen sind betroffen?

• Payload CMS 3.0.0 bis vor 3.88.0 – verwundbar
• Payload CMS 3.88.0 und neuer – für CVE-2026-105845 korrigiert
• Payload CMS 4.0.0-canary.0 bis vor 4.0.0-canary.27 – verwundbar
• Payload CMS 4.0.0-canary.27 und neuer – für CVE-2026-105845 korrigiert

Vservs empfiehlt, nicht dauerhaft bei der ersten korrigierten Version zu bleiben, sondern nach Prüfung der Anwendung die aktuellste stabile Payload CMS-Version einzusetzen.

PostgreSQL und SQLite sind betroffen

Die Schwachstelle betrifft Payload-Installationen, die einen relationalen Datenbankadapter für PostgreSQL oder SQLite verwenden.

Installationen mit dem MongoDB-Adapter @payloadcms/mongodb sind nach Angaben der offiziellen Security Advisory von dieser spezifischen SQL-Injection-Schwachstelle nicht betroffen.

Dies bedeutet selbstverständlich nicht, dass eine Payload-Installation mit MongoDB generell frei von anderen Sicherheitsrisiken ist. Die Aussage bezieht sich ausschließlich auf CVE-2026-105845.

Wie funktioniert die SQL-Injection?

SQL-Injection entsteht, wenn von außen kontrollierte Eingaben nicht ausreichend von einer Datenbankabfrage getrennt oder validiert werden.

Bei CVE-2026-105845 betrifft dies die Verarbeitung dynamischer Filter und Joins.

Ein Angreifer, der solche Query-Parameter beeinflussen kann, kann unter den beschriebenen Voraussetzungen versuchen, die vom Payload CMS erzeugte SQL-Abfrage zu manipulieren.

Dadurch kann die Datenbank möglicherweise andere Operationen ausführen, als vom Anwendungsentwickler vorgesehen.

Die konkreten Auswirkungen hängen unter anderem von der Payload-Konfiguration, den öffentlich lesbaren Collections und den Berechtigungen des verwendeten Datenbankkontos ab.

Wann ist eine Payload CMS-Installation tatsächlich angreifbar?

Nicht jede Installation einer betroffenen Payload-Version ist automatisch auf dieselbe Weise ausnutzbar.

Nach Angaben des Payload-Sicherheitsteams müssen insbesondere folgende Bedingungen berücksichtigt werden:

• Es wird eine verwundbare Payload CMS-Version verwendet.
• Die Anwendung verwendet PostgreSQL oder SQLite.
• Nicht vertrauenswürdige Benutzer können lesbare Collections abfragen.
• Diese Benutzer können dynamische Query-Filter oder Join-Parameter übermitteln.

Sind diese Bedingungen erfüllt, kann die Schwachstelle über die Netzwerkschnittstelle der Anwendung erreichbar sein.

Gerade bei öffentlich erreichbaren APIs sollte deshalb geprüft werden, welche Collections ohne Authentifizierung beziehungsweise durch nicht vertrauenswürdige Benutzer gelesen und gefiltert werden können.

CVSS 9,8: als Critical eingestuft

CVE-2026-105845 hat einen CVSS-3.1-Score von 9,8 Critical.

Der veröffentlichte CVSS-Vektor lautet:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Die Bewertung bedeutet unter anderem:

• Attack Vector: Network;
• Attack Complexity: Low;
• Privileges Required: None;
• User Interaction: None;
• Confidentiality Impact: High;
• Integrity Impact: High;
• Availability Impact: High.

Die CVSS-Bewertung beschreibt damit eine potenziell über das Netzwerk erreichbare Schwachstelle, für deren Ausnutzung unter den betroffenen Konfigurationsbedingungen keine bestehenden Benutzerrechte und keine Interaktion eines Opfers erforderlich sind.

Welche Auswirkungen kann eine erfolgreiche SQL-Injection haben?

SQL-Injection kann abhängig von den Berechtigungen des Datenbankkontos dazu führen, dass ein Angreifer Informationen aus der Datenbank ausliest oder Daten verändert.

Je nach Anwendung können sich in einer Payload-Datenbank unter anderem folgende Informationen befinden:

• Benutzer- und Accountinformationen;
• CMS-Inhalte;
• Formular- und Anwendungsdaten;
• Konfigurationsinformationen;
• geschäftliche oder personenbezogene Daten;
• Daten aus individuell entwickelten Collections.

Der CVSS-Vektor bewertet die möglichen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit jeweils als High.

Dies bedeutet jedoch nicht automatisch, dass jede verwundbare Payload-Installation vollständig übernommen werden kann. Die tatsächlichen Möglichkeiten eines Angreifers hängen insbesondere von der Anwendung und den Datenbankberechtigungen ab.

Wird CVE-2026-105845 aktiv ausgenutzt?

Zum Zeitpunkt dieser Veröffentlichung hat Vservs keine zuverlässige öffentliche Bestätigung gefunden, dass CVE-2026-105845 aktiv in freier Wildbahn ausgenutzt wird.

Die offizielle Payload Security Advisory bestätigt die Schwachstelle und die verfügbaren Sicherheitsupdates, meldet jedoch keine beobachtete Angriffskampagne.

Patchstack stuft die Schwachstelle aufgrund ihrer technischen Eigenschaften als High Priority ein und warnt vor einem hohen Exploitationspotenzial. Dies ist jedoch kein Beweis dafür, dass bereits tatsächliche Angriffe stattfinden.

Vservs unterscheidet deshalb ausdrücklich zwischen einer technisch kritischen und potenziell gut automatisierbaren Schwachstelle und einer nachweislich aktiv ausgenutzten Sicherheitslücke.

Payload CMS sofort aktualisieren

Betroffene Installationen sollten mindestens auf Payload CMS 3.88.0 aktualisiert werden.

Für Installationen der 4.0-Canary-Reihe ist mindestens 4.0.0-canary.27 erforderlich.

Da inzwischen neuere Payload-Releases verfügbar sind, empfiehlt Vservs für Produktionsumgebungen die aktuellste stabile Version, sofern diese mit der eingesetzten Anwendung kompatibel ist.

Prüfen Sie beim Update nicht nur das zentrale Payload-Paket, sondern auch die verwendeten Payload-Packages, Datenbankadapter und sonstigen Abhängigkeiten.

Temporäre Maßnahmen, wenn ein Update nicht sofort möglich ist

Die offizielle Security Advisory nennt eine Einschränkung der betroffenen Query-Funktionalität als temporäre Gegenmaßnahme.

Bis das Update durchgeführt werden kann, sollte geprüft werden:

• welche Collections für nicht vertrauenswürdige Benutzer lesbar sind;
• ob öffentliche API-Endpunkte dynamische Filter akzeptieren;
• ob nicht vertrauenswürdige Benutzer Join-Parameter beeinflussen können;
• ob anonyme Benutzer Zugriff auf betroffene Collections besitzen;
• welche Rechte das Payload-Datenbankkonto tatsächlich benötigt.

Beschränken Sie den Zugriff auf dynamische Query-Filter und Join-Parameter für nicht vertrauenswürdige Benutzer und reduzieren Sie den Lesezugriff auf betroffene Collections, soweit dies betrieblich möglich ist.

Diese Maßnahmen dienen ausschließlich der temporären Risikoreduzierung und ersetzen die Installation der Sicherheitsaktualisierung nicht.

Payload CMS auf mögliche Exploitation prüfen

Administratoren von Installationen, auf denen eine verwundbare Payload-Version öffentlich erreichbar war, sollten vorhandene Anwendungs-, API-, Webserver- und Datenbanklogs überprüfen.

Achten Sie insbesondere auf:

• ungewöhnliche Query-Parameter in API-Requests;
• auffällige Kombinationen von Filtern und Joins;
• ungewöhnliche oder wiederkehrende SQL-Fehler;
• unerwartete Zugriffe auf Collections mit sensiblen Informationen;
• nicht erklärbare Spitzen bei der Datenbankaktivität;
• ungeplante oder nicht autorisierte Änderungen an Anwendungsdaten;
• unerwartete Änderungen an Benutzerkonten oder Zugriffsrechten.

Prüfen Sie außerdem, ob Daten abgerufen wurden, die für den betreffenden API-Benutzer beziehungsweise anonymen Zugriff normalerweise nicht verfügbar sein sollten.

Für CVE-2026-105845 sind derzeit keine allgemein zuverlässigen Indicators of Compromise veröffentlicht, mit denen eine erfolgreiche Ausnutzung allein anhand eines bestimmten Requests eindeutig festgestellt werden kann.

Ein auffälliger Request oder Datenbankfehler ist deshalb noch kein Beweis für eine erfolgreiche SQL-Injection.

Ein Update entfernt keine bereits vorgenommenen Änderungen

Die Installation einer sicheren Payload CMS-Version verhindert eine weitere Ausnutzung über CVE-2026-105845.

Änderungen, die ein Angreifer möglicherweise bereits vor dem Update in der Datenbank vorgenommen hat, werden dadurch jedoch nicht automatisch rückgängig gemacht.

Bei konkreten Hinweisen auf eine erfolgreiche SQL-Injection sollte deshalb zusätzlich die Integrität der Datenbank und der Anwendung untersucht werden.

Kontrollieren Sie in diesem Fall auch:

• Payload-Benutzer und Berechtigungen;
• API-Keys und andere Application Secrets;
• Datenbank-Zugangsdaten;
• externe Integrationen;
• ungewöhnliche Änderungen an geschäftlichen oder personenbezogenen Daten;
• verfügbare Backups und deren Integrität.

Credentials sollten aus einer vertrauenswürdigen Umgebung geändert werden, nachdem die betroffene Anwendung untersucht und abgesichert wurde.

Managed VPS Hosting bei Vservs

Headless-CMS-Systeme wie Payload stellen andere Anforderungen an die Hosting-Umgebung als klassische WordPress- oder Joomla-Websites. Node.js, Datenbankserver, Reverse Proxy, Betriebssystem, Firewall und Monitoring bilden gemeinsam die technische Plattform der Anwendung.

Mit Vservs Managed VPS Hosting übernehmen wir unter anderem das technische Management, Security-Updates, Hardening und Monitoring der zugrunde liegenden Linux-Serverumgebung.

Eine professionell verwaltete Serverumgebung ersetzt nicht die Sicherheitsupdates der darauf betriebenen Anwendung. Sie sorgt jedoch dafür, dass auch Betriebssystem, Dienste und Serverkonfiguration kontinuierlich technisch betreut werden.

Zusammenfassung

• Software: Payload CMS
• CVE: CVE-2026-105845
• Schwachstelle: SQL-Injection
• CWE: CWE-89 – SQL Injection
• Schweregrad: Critical
• CVSS: 9,8
• Betroffene Datenbanken: PostgreSQL und SQLite
• MongoDB: von dieser spezifischen Schwachstelle nicht betroffen
• Betroffene stabile Versionen: 3.0.0 bis vor 3.88.0
• Erste korrigierte stabile Version: 3.88.0
• Betroffene Canary-Versionen: 4.0.0-canary.0 bis vor 4.0.0-canary.27
• Erste korrigierte Canary-Version: 4.0.0-canary.27
• Authentifizierung: unter den beschriebenen Voraussetzungen nicht erforderlich
• Benutzerinteraktion: nicht erforderlich
• Aktive Ausnutzung: zum Zeitpunkt der Veröffentlichung nicht bestätigt
• Empfehlung: sofort aktualisieren und öffentlich erreichbare Query-Funktionalität überprüfen

Quellen

• Payload CMS – offizielle Security Advisory GHSA-v49j-62m6-pgrr
• Payload CMS – Release-Informationen
• OSV – CVE-2026-105845 / GHSA-v49j-62m6-pgrr
• GitLab Advisory Database – CVE-2026-105845

Die OrdaSoft Joomla CCK Sicherheitslücke CVE-2026-102427 ermöglicht Remote Code Execution ohne Anmeldung, indem ein Angreifer eine manipulierte PHP-Datei auf den Webserver hochladen und anschließend ausführen kann. Zusätzlich enthält dieselbe Joomla-Erweiterung eine kritische unauthentifizierte SQL-Injection in den öffentlich erreichbaren Listenansichten.

Beide Sicherheitsprobleme betreffen OrdaSoft Joomla CCK beziehungsweise OS CCK in Versionen vor 8.3.16. CVE-2026-102427 hat mit 10,0 die maximale CVSS-4.0-Bewertung. Die SQL-Injection wurde ebenfalls in Version 8.3.16 behoben, besitzt zum Zeitpunkt dieser Veröffentlichung jedoch keine eigene CVE-Nummer.

Was ist die OrdaSoft Joomla CCK Sicherheitslücke?

In OrdaSoft Joomla CCK, auch als OS CCK beziehungsweise com_os_cck bekannt, wurden zwei schwerwiegende Sicherheitsprobleme festgestellt:

• CVE-2026-102427 – unauthentifizierter Arbitrary File Upload mit Remote Code Execution – CVSS 10,0 Critical;
• unauthentifizierte SQL-Injection in den Sortierfunktionen der öffentlich erreichbaren Listenansichten.

Für beide Angriffswege ist kein Joomla-Benutzerkonto erforderlich.

Wichtig: Die SQL-Injection besitzt zum Zeitpunkt dieser Veröffentlichung keine eigene CVE-Nummer. CVE-2026-102427 bezieht sich ausschließlich auf die File-Upload-/Remote-Code-Execution-Schwachstelle.

CVE-2026-102427 ermöglicht PHP-Code-Ausführung ohne Anmeldung

Die schwerwiegendste Schwachstelle befindet sich in der Upload-Funktion von OrdaSoft Joomla CCK.

Die betroffene Datei site/uploader.php kann über das normale Frontend-Routing der Joomla-Komponente mit task=getContent erreicht werden.

Nach den vom Joomla-Projekt als CNA veröffentlichten technischen Informationen findet auf diesem Ausführungspfad weder eine Authentifizierungs- noch eine ACL-Prüfung statt.

Der Upload-Handler überprüft den tatsächlichen Inhalt einer hochgeladenen Datei über deren Magic-Byte-MIME-Typ. Die eigentlich vorgesehene Allow-List für zulässige Dateiendungen war in den verwundbaren Versionen jedoch deaktiviert.

Die Dateiendung der gespeicherten Datei wurde dadurch direkt aus dem vom Angreifer gelieferten Dateinamen übernommen.

Anschließend wurde die Datei in einem Verzeichnis unterhalb des Joomla-Webroots gespeichert, in dem PHP-Dateien vom Webserver ausgeführt werden können.

Wie führt der Datei-Upload zu Remote Code Execution?

Ein Angreifer kann eine sogenannte Polyglot-Datei erstellen. Eine solche Datei beginnt beispielsweise mit gültigen Bilddaten, enthält anschließend jedoch zusätzlich PHP-Code.

Die Datei kann dadurch die in OS CCK vorhandene MIME-Prüfung als Bild bestehen und gleichzeitig vom Angreifer mit einer .php-Dateiendung versehen werden.

Da die verwundbaren Versionen diese Dateiendung nicht ausreichend einschränken, kann die Datei als PHP-Datei in einem über das Web erreichbaren Verzeichnis gespeichert werden.

Ruft der Angreifer die hochgeladene Datei anschließend über HTTP auf, führt der Webserver den enthaltenen PHP-Code aus.

Damit erhält der Angreifer Remote Code Execution mit den Berechtigungen des PHP- beziehungsweise Webserver-Benutzers, unter dem die Joomla-Website ausgeführt wird.

CVE-2026-102427 hat einen CVSS-Score von 10,0

Das Joomla-Projekt bewertet CVE-2026-102427 mit dem maximalen CVSS-4.0-Score von 10,0 Critical.

Der veröffentlichte Vektor lautet:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Die wesentlichen Eigenschaften sind:

• über das Netzwerk erreichbar;
• niedrige Angriffskomplexität;
• keine zusätzlichen Attack Requirements;
• keine Authentifizierung erforderlich;
• keine Benutzerinteraktion erforderlich;
• hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.

Was kann ein Angreifer nach erfolgreicher RCE tun?

Bei erfolgreicher Ausnutzung kann ein Angreifer unter anderem:

• Webshells und andere Malware installieren;
• Joomla-Dateien lesen oder verändern;
• auf configuration.php zugreifen;
• Datenbank-Zugangsdaten und andere Secrets auslesen;
• Templates und Erweiterungen manipulieren;
• persistente Backdoors installieren;
• auf Daten zugreifen, die für die betroffene Joomla-Installation erreichbar sind;
• die kompromittierte Website für weitere Angriffe verwenden.

Auf einer korrekt isolierten Hosting-Plattform bedeutet Code-Ausführung innerhalb einer Joomla-Website nicht automatisch Root-Zugriff auf den gesamten Server. Die betroffene Website selbst sollte nach erfolgreicher Ausnutzung jedoch als potenziell vollständig kompromittiert betrachtet werden.

Zusätzliche SQL-Injection ohne Anmeldung

Neben CVE-2026-102427 wurde in OS CCK eine weitere Sicherheitslücke in den öffentlich erreichbaren Listenansichten behoben.

OS CCK ermöglicht das Sortieren von Datensätzen. In Versionen vor 8.3.16 konnten die Parameter für das Sortierfeld beziehungsweise die Sortierreihenfolge in die SQL-Abfrage gelangen, ohne zuvor gegen eine feste Liste zulässiger Datenbankspalten geprüft zu werden.

Besonders problematisch ist hierbei das SQL-ORDER BY-Konstrukt. Ein Spaltenname ist Teil der SQL-Struktur und kein normaler Datenwert. Klassisches Escaping oder Parameter Binding allein kann dieses Problem deshalb nicht zuverlässig verhindern.

Ein nicht angemeldeter Besucher konnte dadurch die Struktur der zugrunde liegenden Datenbankabfrage beeinflussen.

Wie wurde die SQL-Injection behoben?

In OS CCK 8.3.16 wird das angeforderte Sortierfeld gegen die tatsächlich zulässigen Spalten des betreffenden Content-Typs und eine begrenzte Liste bekannter Sortierschlüssel geprüft.

Stimmt die angeforderte Spalte nicht mit einem erlaubten Wert überein, verwendet OS CCK einen sicheren Standardwert.

Damit wird verhindert, dass frei kontrollierbare Eingaben als Bestandteil der SQL-Struktur verwendet werden.

Für diese SQL-Injection wurde zum Zeitpunkt dieser Veröffentlichung keine eigene CVE-Nummer vergeben. Die Änderung ist jedoch direkt in OS CCK 8.3.16 enthalten und wurde unabhängig im veröffentlichten Paket nachvollzogen.

Welche OrdaSoft Joomla CCK-Versionen sind betroffen?

• OS CCK 1.0.0 bis einschließlich 8.3.15 – für CVE-2026-102427 verwundbar
• OS CCK vor 8.3.16 – von der SQL-Injection betroffen
• OS CCK Light/free 8.3.16 – beide Sicherheitsprobleme behoben

Version 8.3.16 stellt für Uploads eine Allow-List mit den Dateiendungen jpg, jpeg, png, gif und webp wieder her. Zusätzlich wurde die Verarbeitung der Sortierfelder abgesichert.

Die automatische Joomla-Updateprüfung kann 8.3.16 übersehen

Bei diesem Sicherheitsupdate gibt es ein zusätzliches operatives Problem.

Nach der Veröffentlichung von OS CCK 8.3.16 meldete der Update-Manifest-Server von OrdaSoft weiterhin Version 8.3.14 als aktuelle Version.

Dadurch kann eine Joomla-Installation mit einer verwundbaren OS-CCK-Version melden, dass keine Aktualisierung verfügbar ist, obwohl Version 8.3.16 bereits veröffentlicht wurde.

Administratoren sollten deshalb das tatsächlich installierte Versionsnummer manuell kontrollieren und Version 8.3.16 beziehungsweise eine neuere bestätigte sichere Version direkt über den offiziellen OrdaSoft-Kanal installieren.

Besondere Vorsicht bei OS CCK Pro

Die Pro-Ausgabe verwendet dasselbe Joomla-Element com_os_cck, folgt jedoch einer anderen beziehungsweise nicht ausreichend öffentlich dokumentierten Versionshistorie.

Eine konkrete korrigierte Pro-Version konnte anhand der öffentlich verfügbaren Informationen nicht zuverlässig bestätigt werden.

Betreiber der Pro-Ausgabe sollten deshalb nicht einfach davon ausgehen, dass eine bestimmte Pro-Version sicher ist, sondern die verfügbare korrigierte Version direkt bei OrdaSoft überprüfen.

Wird CVE-2026-102427 bereits aktiv ausgenutzt?

Zum Zeitpunkt dieser Veröffentlichung gibt es keine zuverlässige öffentliche Bestätigung einer aktiven Ausnutzung von CVE-2026-102427 in freier Wildbahn.

Die Schwachstelle befindet sich derzeit nicht im CISA Known Exploited Vulnerabilities Catalog. Die an den CVE-Datensatz angehängte CISA-Bewertung nennt ebenfalls keine beobachtete Exploitation.

Das bedeutet jedoch nicht, dass die Schwachstelle ungefährlich oder schwer auszunutzen ist.

Der Angriff ist ohne Authentifizierung über einen vorhersehbaren Endpunkt erreichbar und lässt sich grundsätzlich automatisieren. Bei einer Remote-Code-Execution-Schwachstelle mit CVSS 10,0 sollte die verfügbare Sicherheitskorrektur daher ohne Verzögerung installiert werden.

Was sollten Joomla-Administratoren jetzt tun?

1. Prüfen Sie, ob OrdaSoft Joomla CCK beziehungsweise com_os_cck installiert ist.
2. Kontrollieren Sie die genaue installierte Version manuell.
3. Aktualisieren Sie OS CCK Light/free auf 8.3.16 oder eine neuere bestätigte sichere Version.
4. Verlassen Sie sich nicht ausschließlich auf die automatische Joomla-Updateprüfung.
5. Deaktivieren Sie die Komponente, wenn eine sichere Version nicht unmittelbar installiert werden kann.
6. Kontrollieren Sie Upload-Verzeichnisse auf unerwartete ausführbare Dateien.
7. Prüfen Sie Webserver-Logs auf verdächtige Upload- und Ausführungsaktivitäten.
8. Untersuchen Sie Datenbank- und Anwendungsaktivitäten auf mögliche SQL-Injection-Versuche.

Nur den Joomla-Menüpunkt zu deaktivieren reicht nicht aus

Wenn ein Update nicht unmittelbar möglich ist, sollte die betroffene Komponente selbst deaktiviert werden.

Lediglich einen Joomla-Menüpunkt zu deaktivieren oder zu verstecken reicht nicht aus. Die verwundbare Upload-Funktion kann über das eigene Frontend-Routing der Komponente direkt erreicht werden.

Eine Web Application Firewall kann eine zusätzliche Schutzschicht bieten, ersetzt jedoch weder das Sicherheitsupdate noch die Deaktivierung einer verwundbaren Komponente.

Upload-Verzeichnisse auf PHP-Dateien kontrollieren

Bei CVE-2026-102427 sollte insbesondere nach unerwarteten ausführbaren Dateien in Verzeichnissen gesucht werden, die dem folgenden Muster entsprechen:

/images/com_os_cck*/original/

Kontrollieren Sie diese und verwandte Upload-Verzeichnisse insbesondere auf:

• .php-Dateien;
• .phtml-Dateien;
• .phar-Dateien;
• Dateien mit verdächtigen doppelten Endungen;
• Dateien, deren tatsächlicher Inhalt nicht zur Dateiendung passt.

Ausführbarer PHP-Code sollte sich normalerweise nicht in einem Joomla-Verzeichnis befinden, das ausschließlich für Bilder oder andere Benutzer-Uploads vorgesehen ist.

Wird dort eine unbekannte ausführbare Datei gefunden, sollte die Website als potenziell kompromittiert behandelt werden. Das einfache Löschen der betreffenden Datei ist dann nicht ausreichend.

Webserver-Logs auf Exploitationsversuche prüfen

Prüfen Sie vorhandene Access- und Security-Logs auf ungewöhnliche Requests im Zusammenhang mit OS CCK.

Relevant sind unter anderem:

• Requests im Zusammenhang mit site/uploader.php;
• Frontend-Routen mit task=getContent;
• Upload-Requests, denen direkte Aufrufe neu angelegter Dateien unter /images/ folgen;
• ungewöhnliche Werte in order_field oder order_direction;
• SQL-Syntax oder ungewöhnliche Kodierung in Requests an OS CCK.

Ein verdächtiger HTTP-Request allein beweist keine erfolgreiche Exploitation. Die Requests sollten mit neu angelegten Dateien, PHP-Ausführung, Datenbankaktivitäten und nachfolgenden Änderungen an Joomla abgeglichen werden.

Was tun bei Verdacht auf Remote Code Execution?

Wird eine unbekannte ausführbare Datei oder ein anderer Hinweis auf erfolgreiche RCE gefunden, reicht ein Update von OS CCK allein nicht aus.

Die gesamte Joomla-Installation sollte dann als potenziell kompromittiert betrachtet werden.

Kontrollieren Sie mindestens:

• Joomla-Core-Dateien;
• installierte Templates und Erweiterungen;
• configuration.php;
• Administrator- und Super-User-Konten;
• unbekannte PHP- und andere ausführbare Dateien;
• Scheduled Tasks und serverseitige Cronjobs;
• Datenbankänderungen;
• API-Keys, SMTP-Zugangsdaten und andere Secrets;
• Webserver-, PHP- und Systemlogs.

Relevante Passwörter, API-Keys und andere Zugangsdaten sollten aus einer vertrauenswürdigen Umgebung geändert werden, nachdem der unbefugte Zugriff entfernt und die Integrität der Website wiederhergestellt wurde.

Managed Hosting und Serversicherheit bei Vservs

Eine Sicherheitslücke, über die beliebiger PHP-Code ausgeführt werden kann, betrifft nicht nur das CMS selbst. Benutzerisolation, Dateiberechtigungen, PHP-Konfiguration, Logging, Malwarekontrolle und Server-Hardening tragen dazu bei, die möglichen Auswirkungen einer kompromittierten Website zu begrenzen.

Mit Vservs Managed VPS Hosting übernehmen wir das technische Servermanagement, Betriebssystem- und Sicherheitsupdates, Hardening, Monitoring und die Verwaltung der zugrunde liegenden Linux-Hostingumgebung.

Zusammenfassung

• Produkt: OrdaSoft Joomla CCK / OS CCK / com_os_cck
• CVE: CVE-2026-102427
• Schwachstelle: unauthentifizierter Arbitrary File Upload mit
  

Die GiveWP Sicherheitslücke CVE-2026-104405 ermöglicht Privilege Escalation, ohne dass ein Angreifer zuvor über ein WordPress-Benutzerkonto verfügen muss. Die Schwachstelle betrifft GiveWP-Versionen bis einschließlich 4.17.0 und hat einen CVSS-3.1-Score von 8,1 High.

Die Sicherheitskorrektur ist ab GiveWP 4.18.0 enthalten. Inzwischen steht bereits Version 4.18.0.1 zur Verfügung. Vservs empfiehlt daher, direkt auf die aktuellste stabile GiveWP-Version zu aktualisieren.

Was ist die GiveWP Sicherheitslücke CVE-2026-104405?

CVE-2026-104405 ist eine unauthentifizierte Privilege-Escalation-Schwachstelle in GiveWP, einem weit verbreiteten WordPress-Plugin für Spenden und Fundraising.

Die Schwachstelle wird als CWE-266 – Incorrect Privilege Assignment – klassifiziert. Dabei weist eine Anwendung einem Benutzer oder einer anderen Entität unter bestimmten Bedingungen höhere Berechtigungen zu, als nach dem vorgesehenen Berechtigungsmodell erlaubt sein sollten.

Der veröffentlichte CVSS-3.1-Vektor lautet:

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Dies bedeutet:

• Attack Vector: Network;
• Attack Complexity: High;
• Privileges Required: None;
• User Interaction: None;
• Scope: Unchanged;
• Confidentiality Impact: High;
• Integrity Impact: High;
• Availability Impact: High.

Daraus ergibt sich ein CVSS-Score von 8,1 High.

Welche GiveWP-Versionen sind betroffen?

• GiveWP 4.17.0 und älter – verwundbar
• GiveWP 4.18.0 und neuer – für CVE-2026-104405 korrigiert
• Aktuell empfohlen – GiveWP 4.18.0.1 oder neuer

Da inzwischen eine neuere Version verfügbar ist, empfiehlt Vservs nicht, bewusst bei der ersten korrigierten Version 4.18.0 zu bleiben.

Version 4.18.0.1 enthält zusätzlich verbesserte Validierung für PayPal-Standard-IPN-Benachrichtigungen. Installieren Sie daher die aktuellste stabile GiveWP-Version, die über das offizielle WordPress-Update angeboten wird.

Mehr als 100.000 WordPress-Websites verwenden GiveWP

GiveWP wird laut WordPress.org auf mehr als 100.000 WordPress-Websites aktiv eingesetzt.

Das Plugin wird insbesondere von gemeinnützigen Organisationen, Stiftungen, Vereinen und anderen Organisationen für Spenden und Fundraising verwendet.

Auf solchen Websites können personenbezogene Daten von Spendern sowie weitere sensible Verwaltungsdaten verarbeitet werden. Eine Privilege-Escalation-Schwachstelle ist deshalb auch aus Datenschutzsicht relevant.

Kein WordPress-Konto erforderlich

Für CVE-2026-104405 benötigt ein Angreifer nach den veröffentlichten Schwachstellendaten kein bereits vorhandenes WordPress-Benutzerkonto.

Auch eine Interaktion eines anderen WordPress-Benutzers ist nicht erforderlich.

Die Attack Complexity wird allerdings als High eingestuft. Das bedeutet, dass für eine erfolgreiche Ausnutzung zusätzliche Bedingungen oder ein bestimmter Ablauf erforderlich sein können.

Der vollständige technische Exploitationsweg ist zum Zeitpunkt dieser Veröffentlichung nicht öffentlich im Detail dokumentiert.

Was bedeutet Privilege Escalation?

Bei einer Privilege Escalation erhält ein Angreifer Berechtigungen oder Funktionen, die ihm nach dem normalen Autorisierungsmodell der Anwendung nicht zur Verfügung stehen sollten.

Die derzeit öffentlich verfügbaren Informationen zu CVE-2026-104405 beschreiben jedoch nicht vollständig, welche interne GiveWP-Funktion betroffen ist und welches konkrete WordPress-Berechtigungsniveau nach erfolgreicher Ausnutzung erreicht werden kann.

Es ist deshalb wichtig, bei der Beschreibung der möglichen Auswirkungen nicht über die bestätigten technischen Informationen hinauszugehen.

Der offizielle CVSS-Vektor bewertet die möglichen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit jeweils als High. Eine erfolgreiche Ausnutzung sollte daher als potenziell schwerwiegender Sicherheitsvorfall behandelt werden.

Privilege Escalation bedeutet nicht automatisch Administrator-Zugriff

CVE-2026-104405 wird als unauthentifizierte Privilege Escalation klassifiziert. Diese Klassifizierung allein bedeutet jedoch nicht, dass jede erfolgreiche Ausnutzung automatisch zu einem vollständigen WordPress-Administrator-Konto führt.

Die derzeit veröffentlichten technischen Informationen legen das genaue Zielprivileg beziehungsweise die konkrete Rollenänderung nicht ausreichend offen.

Vservs beschreibt die Schwachstelle daher entsprechend den bestätigten Informationen und klassifiziert sie nicht als bestätigte vollständige Administrator-Übernahme oder Remote Code Execution.

Wird CVE-2026-104405 aktiv ausgenutzt?

Zum Zeitpunkt dieser Veröffentlichung hat Vservs keine zuverlässige öffentliche Bestätigung gefunden, dass CVE-2026-104405 aktiv in freier Wildbahn ausgenutzt wird.

Das Fehlen bestätigter Exploitation ist kein Grund, die Installation der verfügbaren Sicherheitsaktualisierung aufzuschieben.

Die Schwachstelle kann über das Netzwerk erreicht werden, erfordert kein vorhandenes Benutzerkonto und betrifft ein WordPress-Plugin mit mehr als 100.000 aktiven Installationen.

Was sollten GiveWP-Administratoren jetzt tun?

1. Prüfen Sie, welche GiveWP-Version aktuell installiert ist.
2. Aktualisieren Sie mindestens auf GiveWP 4.18.0.
3. Installieren Sie vorzugsweise direkt GiveWP 4.18.0.1 oder eine neuere stabile Version.
4. Kontrollieren Sie nach dem Update, ob die aktualisierte Version tatsächlich aktiv ist.
5. Entfernen Sie nicht mehr benötigte GiveWP-Komponenten und Add-ons.
6. Kontrollieren Sie WordPress-Benutzer und deren Rollen auf unerwartete Änderungen.
7. Prüfen Sie Webserver-, WordPress- und Security-Logs auf auffällige Aktivitäten.

Website auf mögliche Kompromittierung prüfen

Websites, auf denen GiveWP 4.17.0 oder älter öffentlich erreichbar war, können zusätzlich auf Hinweise auf nicht autorisierte Berechtigungsänderungen überprüft werden.

Achten Sie unter anderem auf:

• neue oder unbekannte WordPress-Benutzer;
• bestehende Benutzer, die unerwartet Administrator- oder andere erhöhte Berechtigungen erhalten haben;
• Administrator-Anmeldungen von unbekannten IP-Adressen;
• unerklärliche Änderungen an GiveWP-Einstellungen;
• unerwartete Exporte oder Zugriffe auf Spenderdaten;
• unbekannte Plugins oder Themes;
• unerwartete PHP-Dateien oder Änderungen an WordPress-Dateien;
• auffällige Requests an GiveWP-Endpunkte in Webserver- oder WAF-Logs.

Da die vollständigen technischen Exploitdetails derzeit nicht öffentlich dokumentiert sind, wäre es nicht verantwortungsvoll, einen einzelnen HTTP-Request oder eine bestimmte URL als definitive Indicator of Compromise für CVE-2026-104405 darzustellen.

Was tun bei unerwarteten Berechtigungsänderungen?

Werden unbekannte Administrator-Konten, Berechtigungsänderungen oder andere Hinweise auf eine Kompromittierung gefunden, reicht ein Update von GiveWP allein nicht aus.

Die betroffene WordPress-Installation sollte dann auf weitere nicht autorisierte Änderungen untersucht werden.

Kontrollieren Sie mindestens:

• WordPress-Core-Dateien;
• installierte Plugins und Themes;
• Must-Use-Plugins;
• WordPress-Benutzer und Capabilities;
• Datenbankänderungen;
• wp-config.php;
• WordPress Scheduled Tasks und serverseitige Cronjobs;
• Webserver-, PHP- und Security-Logs;
• API-Keys, Datenbank-Zugangsdaten und andere Application Secrets.

Relevante Administrator-Passwörter und andere Zugangsdaten sollten erst aus einer vertrauenswürdigen Umgebung geändert werden, nachdem die Website untersucht und abgesichert wurde.

Wenn eine Administrator-Sitzung oder ein privilegiertes Konto möglicherweise kompromittiert wurde, sollten zusätzlich die WordPress Authentication Salts erneuert werden.

Mögliche Auswirkungen auf Spenderdaten berücksichtigen

GiveWP wurde speziell für die Verarbeitung von Spenden und die Verwaltung von Spenderinformationen entwickelt.

Wird ein unbefugter Zugriff bestätigt, sollte deshalb geprüft werden, ob personenbezogene Daten betroffen waren. Abhängig von der jeweiligen Website können beispielsweise Namen, E-Mail-Adressen, Spendenhistorien oder andere von GiveWP und zugehörigen Erweiterungen gespeicherte Informationen betroffen sein.

Bei einem möglichen Zugriff auf personenbezogene Daten muss zusätzlich geprüft werden, ob weitere Maßnahmen nach DSGVO beziehungsweise den geltenden Datenschutz- und Meldepflichten erforderlich sind.

Managed WordPress Hosting bei Vservs

WordPress-Sicherheit erfordert eine kontinuierliche Überwachung von WordPress Core, Plugins und Themes. Besonders weit verbreitete Plugins können nach Veröffentlichung einer Schwachstelle schnell zu attraktiven Zielen für automatisierte Angriffe werden.

Mit Vservs Managed WordPress übernehmen wir unter anderem WordPress-Core-, Plugin- und Theme-Updates, Security Hardening, Monitoring, Malwarekontrollen, Backups, SSL und das technische WordPress-Management.

Zusammenfassung

• Plugin: GiveWP
• CVE: CVE-2026-104405
• Schwachstelle: Privilege Escalation
• CWE: CWE-266 – Incorrect Privilege Assignment
• CVSS: 8,1 – High
• Betroffene Versionen: GiveWP 4.17.0 und älter
• Erste korrigierte Version: GiveWP 4.18.0
• Aktuell empfohlen: GiveWP 4.18.0.1 oder neuer
• Aktive Installationen: mehr als 100.000
• Authentifizierung erforderlich: Nein
• Benutzerinteraktion erforderlich: Nein
• Attack Complexity: High
• Bestätigte Administrator-Übernahme: durch die derzeit veröffentlichten technischen Informationen nicht belegt
• Aktive Ausnutzung: zum Zeitpunkt der Veröffentlichung nicht bestätigt
• Empfehlung: umgehend auf die aktuellste stabile GiveWP-Version aktualisieren

Quellen

• CVE Program – CVE-2026-104405
• NIST NVD – CVE-2026-104405
• Patchstack – GiveWP Vulnerability Database
• WordPress.org – GiveWP Donation Plugin and Fundraising Platform

Eine Ninja Forms Sicherheitslücke und eine Schwachstelle in WPC Product Bundles for WooCommerce werden aktiv ausgenutzt, um WordPress-Websites zu kompromittieren. Sicherheitsforscher von Patchstack beobachten eine Angriffskampagne, bei der Stored Cross-Site Scripting genutzt wird, um über die aktive Sitzung eines WordPress-Administrators schädliche Plugins, Administrator-Konten und mehrere Backdoors zu installieren.

Die Angriffe richten sich gegen CVE-2026-94504 in Ninja Forms und CVE-2026-93836 in WPC Product Bundles for WooCommerce. Beide Schwachstellen wurden behoben. Websites, auf denen eine erfolgreiche Ausnutzung bereits stattgefunden haben könnte, müssen jedoch zusätzlich auf eine mögliche Kompromittierung untersucht werden.

Welche Ninja Forms Sicherheitslücke wird aktiv ausgenutzt?

Patchstack hat die aktive Ausnutzung von zwei WordPress-Plugin-Schwachstellen bestätigt:

• Ninja Forms – CVE-2026-94504: Versionen bis einschließlich 3.15.3 sind für diese Schwachstelle verwundbar; Version 3.15.4 enthält die Sicherheitskorrektur.
• WPC Product Bundles for WooCommerce – CVE-2026-93836: Versionen bis einschließlich 8.6.6 sind verwundbar; Version 8.6.7 enthält die Sicherheitskorrektur.

Beide Schwachstellen sind Stored-Cross-Site-Scripting-Sicherheitslücken mit einem CVSS-Score von 7,1.

Da für Ninja Forms inzwischen Version 3.15.5 verfügbar ist und diese eine weitere separate XSS-Schwachstelle behebt, empfiehlt Vservs, direkt auf Ninja Forms 3.15.5 oder neuer zu aktualisieren und nicht bei 3.15.4 zu bleiben.

Wie funktioniert der Angriff?

Der Angriff beginnt mit Daten, die ohne WordPress-Anmeldung an eine verwundbare Website übermittelt werden können.

Bei WPC Product Bundles wird der schädliche JavaScript-Code in WooCommerce-Bestelldaten gespeichert. Bei Ninja Forms kann die Payload über eine normale Formularübermittlung in der Datenbank abgelegt werden.

Der JavaScript-Code wird nicht unbedingt sofort ausgeführt. Stattdessen wartet der Angriff darauf, dass ein angemeldeter WordPress-Administrator die betroffene WooCommerce-Bestellung oder Ninja-Forms-Übermittlung öffnet.

In diesem Moment wird der gespeicherte JavaScript-Code innerhalb des Sicherheitskontexts der WordPress-Administrationsoberfläche ausgeführt.

Der Angriff missbraucht die bestehende Administrator-Sitzung

Die Malware muss weder das WordPress-Passwort des Administrators kennen noch dessen Session-Cookie direkt stehlen.

Da der schädliche JavaScript-Code innerhalb der eigenen WordPress-Domain ausgeführt wird, werden Requests an wp-admin automatisch mit der bereits authentifizierten Administrator-Sitzung ausgeführt.

Der Angriff kann diese Sitzung nutzen, um WordPress-Nonces abzurufen und legitime administrative WordPress-Funktionen aufzurufen.

Nach der Analyse von Patchstack kann die Angriffskette anschließend unter anderem:

• ein schädliches WordPress-Plugin installieren;
• ein sichtbares Administrator-Konto anlegen;
• ein zweites Administrator-Konto anlegen, das aus der normalen WordPress-Benutzerliste verborgen wird;
• einen geheimen Login-Mechanismus installieren;
• einen ungeschützten File Manager installieren;
• zusätzliche Persistence über Must-Use-Plugins einrichten.

Schädliches Plugin tarnt sich als WP Smart Thumbnails

Die beobachtete Kampagne installiert ein Plugin mit dem Namen WP Smart Thumbnails, Version 1.2.4, das angeblich von „MediaPress Labs“ entwickelt wurde.

Das Plugin wird unter folgendem Pfad installiert:

/wp-content/plugins/wp-smart-thumbnails/

Patchstack hat festgestellt, dass dieses Plugin keine legitime Thumbnail-Funktionalität enthält. Stattdessen dient es unter anderem als Malware-Dropper, Persistence-Installer und ungeschützter File Manager.

Verstecktes Administrator-Konto ist in wp-admin nicht sichtbar

Ein besonders relevantes Merkmal dieser Angriffskampagne ist die Möglichkeit, ein WordPress-Administrator-Konto anzulegen, das gezielt aus der normalen Benutzeroberfläche ausgeblendet wird.

Die Angreifer können dafür unter anderem Must-Use-Plugins unter folgenden Pfaden anlegen:

/wp-content/mu-plugins/class-wp-query-*.php

und:

/wp-content/mu-plugins/class-wp-token-validate.php

Diese schädliche PHP-Logik manipuliert WordPress-Benutzerabfragen so, dass ein vom Angreifer kontrolliertes Administrator-Konto nicht unter Benutzer → Alle Benutzer erscheint und auch nicht in den angezeigten Benutzerzahlen berücksichtigt wird.

Eine reine Kontrolle der Benutzerliste in wp-admin reicht daher nicht aus, um eine Kompromittierung auszuschließen.

Geheimer WordPress-Login ermöglicht dauerhaften Zugriff

Die Malware kann zusätzlich einen geheimen Authentifizierungsweg über folgende URL einrichten:

/wp-login.php?_wplogin=<token>

Damit kann ein Angreifer eine authentifizierte WordPress-Sitzung als bestehender Administrator erhalten, ohne den normalen Login-Prozess zu verwenden.

Die zugehörigen Tokens werden in der WordPress-Option gespeichert:

fz_emer_login_tokens

Ein Update oder die Deinstallation von Ninja Forms beziehungsweise WPC Product Bundles entfernt diese Persistence nach einer erfolgreichen Kompromittierung nicht automatisch.

Aktive Ausnutzung ist bestätigt

Bei dieser Kampagne handelt es sich nicht lediglich um theoretische Schwachstellen oder öffentlich verfügbaren Proof-of-Concept-Code.

Patchstack hat tatsächliche Exploitation beobachtet:

• 4. Oktober 2026: erste beobachtete Ausnutzung von CVE-2026-93836 in WPC Product Bundles;
• 5. Oktober 2026: dieselbe Angriffspayload wurde über CVE-2026-94504 in Ninja Forms ausgeliefert.

In beiden Fällen wurde schädliches JavaScript von derselben Angreifer-Infrastruktur unter imgcdn1.com geladen.

Patchstack beschreibt das bislang beobachtete Exploitationsvolumen als begrenzt. Die aktive Ausnutzung selbst ist jedoch eindeutig bestätigt.

Welche Versionen sollten installiert werden?

• Ninja Forms: für CVE-2026-94504 mindestens 3.15.4; aufgrund einer inzwischen zusätzlich behobenen XSS-Schwachstelle empfiehlt Vservs 3.15.5 oder neuer.
• WPC Product Bundles for WooCommerce: mindestens 8.6.7 beziehungsweise die aktuellste verfügbare stabile Version.

Installieren Sie grundsätzlich die aktuellste stabile Version, die vom jeweiligen Plugin-Entwickler angeboten wird.

Ein Update allein reicht nach erfolgreicher Ausnutzung nicht aus

Die Sicherheitsupdates verhindern eine erneute Ausnutzung über die jeweiligen Schwachstellen. Bereits installierte Backdoors, Administrator-Konten oder andere Persistence-Mechanismen werden dadurch jedoch nicht entfernt.

Websites, auf denen verwundbare Versionen aktiv waren und auf denen Administratoren während dieses Zeitraums WooCommerce-Bestellungen oder Ninja-Forms-Einträge geöffnet haben, sollten deshalb zusätzlich auf Indicators of Compromise überprüft werden.

Auf diese Indicators of Compromise prüfen

Kontrollieren Sie das WordPress-Dateisystem insbesondere auf folgende Dateien und Verzeichnisse:

• /wp-content/plugins/wp-smart-thumbnails/
• /wp-content/plugins/wp-smart-thumbnails/wp-smart-thumbnails.php
• /wp-content/plugins/wp-smart-thumbnails/emer-run.php
• /wp-content/mu-plugins/class-wp-token-validate.php
• /wp-content/mu-plugins/class-wp-query-*.php

Prüfen Sie außerdem die WordPress-Datenbank auf folgende Optionen:

• fz_emer_done_v1
• fz_emer_login_tokens

Durchsuchen Sie Webserver- und Security-Logs nach Hinweisen auf:

• imgcdn1.com
• /fz/x.js
• /fz/c.php
• _wplogin in Requests an wp-login.php.

Administrator-Konten direkt in der Datenbank kontrollieren

Da die Malware Administrator-Konten aus wp-admin ausblenden kann, sollten bei einem konkreten Verdacht die tatsächlichen WordPress-Benutzer und deren Berechtigungen direkt auf Datenbankebene kontrolliert werden.

Vergleichen Sie die Konten mit Administratorrechten mit den Benutzern, die in der WordPress-Administrationsoberfläche angezeigt werden.

Unbekannte Konten mit allgemeinen Namen wie support, updater, maintenance oder backup sollten besonders untersucht werden. Ein ungewöhnliches @wordpress.org-E-Mail-Konto bei einem lokalen WordPress-Benutzer ist ebenfalls ein mögliches Warnsignal.

Nicht nur nach kürzlich geänderten Dateien suchen

Die bei dieser Kampagne beobachtete Malware manipuliert bewusst die Änderungszeiten der von ihr angelegten Dateien.

Der Installer sucht nach älteren Dateien innerhalb der WordPress-Installation und übernimmt deren Zeitstempel für neu angelegte schädliche Dateien.

Eine Malwarekontrolle, die ausschließlich nach Dateien sucht, die in den vergangenen Tagen geändert wurden, kann diese Persistence daher übersehen.

Was tun bei bestätigter Kompromittierung?

Wird einer der beschriebenen Indicators of Compromise gefunden, sollte die betroffene WordPress-Website als potenziell vollständig kompromittiert betrachtet werden.

Vservs empfiehlt dann mindestens:

1. den Zugriff auf die betroffene Website bei Bedarf einzuschränken, um weitere schädliche Aktivitäten zu verhindern;
2. Ninja Forms und/oder WPC Product Bundles auf eine sichere Version zu aktualisieren;
3. nicht autorisierte Plugins und schädliche Must-Use-Plugins zu entfernen;
4. alle Administrator-Konten sowohl über WordPress als auch direkt in der Datenbank zu überprüfen;
5. schädliche WordPress-Optionen und Persistence-Mechanismen zu entfernen;
6. WordPress Core, Plugins und Themes auf Integrität zu überprüfen;
7. Administrator-Passwörter und andere privilegierte Zugangsdaten zu ändern;
8. die WordPress Authentication Salts neu zu generieren;
9. API-Keys und andere Secrets zu rotieren, wenn diese möglicherweise zugänglich waren;
10. Webserver-, PHP-, Datenbank- und Security-Logs zu sichern und auszuwerten.

Kann der Umfang einer Kompromittierung nicht zuverlässig bestimmt werden, sollte eine Wiederherstellung aus einem nachweislich sauberen Zustand in Betracht gezogen werden.

Managed WordPress Hosting bei Vservs

Diese Angriffskampagne zeigt, warum das reine Installieren von Updates für geschäftskritische WordPress-Websites nicht ausreicht. Bei aktiv ausgenutzten Schwachstellen sind Monitoring, Logging, Malwarekontrolle und Incident Response ebenso wichtig.

Mit Vservs Managed WordPress übernehmen wir unter anderem WordPress-Core-, Plugin- und Theme-Updates, Security Hardening, Monitoring, Malwarekontrollen, Backups, SSL und das technische WordPress-Management.

Zusammenfassung

• Ninja Forms CVE: CVE-2026-94504
• Ninja Forms betroffen: bis einschließlich 3.15.3
• Ninja Forms Fix für CVE-2026-94504: 3.15.4
• Aktuell empfohlen für Ninja Forms: 3.15.5 oder neuer
• WPC Product Bundles CVE: CVE-2026-93836
• WPC Product Bundles betroffen: bis einschließlich 8.6.6
• WPC Product Bundles gepatcht: 8.6.7 oder neuer
• Schwachstellentyp: Stored Cross-Site Scripting
• CVSS: 7,1
• Authentifizierung für die initiale Injection: nicht erforderlich
• Ausführung: wenn ein angemeldeter Administrator die injizierten Daten aufruft
• Aktive Ausnutzung: bestätigt
• Mögliche Auswirkungen: Administrator-Konten, Backdoors, versteckte Persistence und File Manager
• Empfehlung: sofort aktualisieren und zuvor exponierte Websites auf eine mögliche Kompromittierung prüfen

Quellen

• Patchstack – Four ways back in: the WordPress XSS campaign that hides its own admin account
• Patchstack – CVE-2026-94504
• Patchstack – CVE-2026-93836
• Patchstack – aktuelle Ninja Forms Vulnerability Database

Das WordPress 7.1.3 Sicherheitsupdate behebt sieben Sicherheitslücken in WordPress Core, darunter Stored Cross-Site Scripting, eine Second-Order SQL-Injection, einen Denial-of-Service und die Offenlegung von Informationen ohne Authentifizierung. WordPress hat Version 7.1.3 am 6. Oktober 2026 veröffentlicht und empfiehlt Website-Betreibern, ihre Installationen umgehend zu aktualisieren.

Neben den sieben Sicherheitskorrekturen enthält WordPress 7.1.3 vier reguläre Bugfixes. Eine der Sicherheitslücken wird als CVE-2026-66666 geführt und kann es ermöglichen, Kommentare zu privaten oder noch nicht veröffentlichten Beiträgen ohne WordPress-Benutzerkonto abzurufen.

Was behebt das WordPress 7.1.3 Sicherheitsupdate?

Nach Angaben des offiziellen WordPress Security Teams behebt WordPress 7.1.3 sieben separate Sicherheitsprobleme:

• Stored Cross-Site Scripting auf der Verwaltungsseite für Kommentare über ausstehende Kommentare;
• ein Denial-of-Service-Problem in WP_Http::make_absolute_url();
• eine Second-Order SQL-Injection in der WordPress-WXR-Exportfunktion;
• ein Autorisierungsproblem, durch das Benutzer mit der Rolle Author Beiträge als „sticky“ markieren konnten;
• unauthentifizierte Offenlegung von Kommentaren zu privaten und noch nicht veröffentlichten Beiträgen;
• Cross-Site Scripting über Imgur-Embeds;
• manipulierbare Parameter für den {status}_{type}-Hook, die zu einer Action-Name-Collision führen können.

Die einzelnen Schwachstellen haben nicht alle denselben Angriffsvektor oder dieselbe Auswirkung. WordPress hat daher keinen gemeinsamen CVSS-Score für das gesamte Sicherheitsupdate 7.1.3 vergeben.

CVE-2026-66666: Kommentare zu privaten Beiträgen ohne Anmeldung abrufbar

Eine der mit WordPress 7.1.3 behobenen Schwachstellen wird als CVE-2026-66666 geführt.

Unter bestimmten Umständen konnten Kommentare, die zu privaten oder noch nicht veröffentlichten WordPress-Beiträgen gehören, über einen Kommentar-Feed ohne Authentifizierung abgerufen werden.

Die Schwachstelle hat einen CVSS-4.0-Score von 6,9 und wird als Medium eingestuft.

Für diese spezifische Schwachstelle sind unter anderem folgende WordPress-Versionen betroffen:

• WordPress 7.1 bis einschließlich 7.1.2;
• WordPress 7.0 bis einschließlich 7.0.6;
• WordPress 6.9 bis einschließlich 6.9.9;
• WordPress 6.8 bis einschließlich 6.8.10;
• WordPress 6.7 bis einschließlich 6.7.9;
• WordPress 6.6 bis einschließlich 6.6.9.

Für CVE-2026-66666 sind WordPress 7.1.3, 7.0.7, 6.9.10, 6.8.11, 6.7.10 und 6.6.10 als korrigierte Releases der jeweiligen Versionszweige registriert.

Vservs empfiehlt, wenn möglich direkt auf die aktuelle WordPress-Version 7.1.3 zu aktualisieren, anstatt dauerhaft auf einem älteren Versionszweig zu verbleiben. WordPress selbst empfiehlt den Einsatz der jeweils aktuellsten verfügbaren Version.

Stored XSS über ausstehende Kommentare

Ein weiteres in WordPress 7.1.3 behobenes Sicherheitsproblem betrifft Stored Cross-Site Scripting auf der WordPress-Verwaltungsseite für Kommentare.

Ein Angreifer kann schädliche Inhalte in einem ausstehenden Kommentar speichern. Öffnet ein berechtigter WordPress-Administrator diesen Kommentar anschließend in der Verwaltungsoberfläche, kann der gespeicherte JavaScript-Code im Kontext des WordPress-Backends ausgeführt werden.

Stored XSS ist besonders relevant, weil die schädliche Eingabe auf der Website gespeichert bleibt, bis sie von einem Administrator aufgerufen wird. Der Angreifer muss einen Administrator daher nicht zwingend dazu bringen, eine speziell präparierte externe URL zu öffnen.

Second-Order SQL-Injection im WXR-Export

WordPress 7.1.3 behebt außerdem eine Second-Order SQL-Injection in der WordPress-WXR-Exportfunktion.

Bei einer Second-Order SQL-Injection wird eine schädliche Eingabe nicht unbedingt unmittelbar als Teil einer SQL-Abfrage ausgeführt. Stattdessen können vom Angreifer kontrollierte Daten zunächst gespeichert und erst später bei der Verarbeitung durch eine andere Funktion in eine unsichere Datenbankabfrage gelangen.

Da die Schwachstelle die Exportfunktion betrifft, unterscheidet sich der Angriffsweg von einer klassischen, direkt aus dem Internet erreichbaren unauthentifizierten SQL-Injection.

Denial-of-Service in der WordPress-HTTP-Verarbeitung

Auch in WP_Http::make_absolute_url() wurde ein Sicherheitsproblem behoben, das einen Denial-of-Service verursachen kann.

Die praktische Auswirkung hängt davon ab, wie die betreffende HTTP-Funktion innerhalb einer WordPress-Installation erreicht und verwendet wird. Das zugrunde liegende Problem wurde in WordPress 7.1.3 korrigiert.

Weitere Sicherheitskorrekturen in WordPress 7.1.3

Das Update behebt zusätzlich ein Autorisierungsproblem im Zusammenhang mit Sticky Posts, eine XSS-Schwachstelle bei Imgur-Embeds sowie ein Problem mit manipulierbaren Hook-Parametern, das eine Action-Name-Collision verursachen kann.

Die Kombination der sieben Sicherheitskorrekturen macht WordPress 7.1.3 zu einem wichtigen Security-Release, auch wenn eine Website nicht jede der betroffenen Funktionen aktiv nutzt.

WordPress jetzt auf Version 7.1.3 aktualisieren

WordPress bezeichnet Version 7.1.3 ausdrücklich als Maintenance and Security Release und empfiehlt Website-Betreibern, ihre Installationen zu aktualisieren.

Vservs empfiehlt folgende Maßnahmen:

1. Prüfen Sie, ob ein aktuelles Backup von Website und Datenbank vorhanden ist.
2. Aktualisieren Sie WordPress Core auf Version 7.1.3 oder eine neuere verfügbare Version.
3. Kontrollieren Sie nach dem Update, ob die erwartete WordPress-Version tatsächlich aktiv ist.
4. Prüfen Sie installierte Plugins und Themes ebenfalls auf verfügbare Sicherheitsupdates.
5. Testen Sie nach dem Update wichtige Website-, Formular- und Shop-Funktionen.

WordPress-Website auf verdächtige Aktivitäten prüfen

Eine verwundbare WordPress-Version bedeutet nicht automatisch, dass eine Website angegriffen oder kompromittiert wurde. Bei Websites, die mit WordPress 7.1.2 oder einer anderen betroffenen älteren Version öffentlich erreichbar waren, kann eine zusätzliche Kontrolle dennoch sinnvoll sein.

Achten Sie unter anderem auf:

• unerwartete oder auffällige ausstehende Kommentare;
• HTML- oder JavaScript-Konstruktionen in Kommentaren, die dort funktional nicht hingehören;
• ungewöhnliche Requests an Kommentar-Feeds für private oder unveröffentlichte Inhalte;
• unerwartete WordPress-Exportaktivitäten;
• nicht erklärbare Spitzen bei PHP- oder Webserver-Last;
• unerwartete Änderungen an Beiträgen, Benutzern oder Benutzerrollen;
• neue oder unbekannte Administrator-Konten;
• auffällige Aktivitäten in Webserver-, PHP- oder Security-Logs.

Ein verdächtiger Request allein ist kein Beweis dafür, dass eine Schwachstelle erfolgreich ausgenutzt wurde. Logaktivitäten sollten mit tatsächlichen Änderungen innerhalb von WordPress und weiteren verfügbaren Sicherheitsdaten abgeglichen werden.

Werden die Schwachstellen aus WordPress 7.1.3 aktiv ausgenutzt?

Zum Zeitpunkt der Veröffentlichung hat Vservs keine zuverlässige Bestätigung gefunden, dass die sieben mit WordPress 7.1.3 behobenen Schwachstellen in größerem Umfang aktiv ausgenutzt werden.

Für CVE-2026-66666 meldet die aktuelle CISA-Vulnerability-Enrichment-Bewertung keine beobachtete Exploitation. Die Schwachstelle ist derzeit ebenfalls nicht im CISA Known Exploited Vulnerabilities Catalog aufgeführt.

Dies sollte nicht als Grund verstanden werden, das Update aufzuschieben. Die Schwachstellen sind öffentlich bekannt und eine offizielle Sicherheitsaktualisierung ist verfügbar.

Managed WordPress Hosting bei Vservs

WordPress Core ist nur ein Teil der Sicherheit einer WordPress-Umgebung. Plugins, Themes, PHP, Datenbankkonfiguration, Serversicherheit, Monitoring und zuverlässige Backups tragen ebenfalls wesentlich zur Sicherheit einer Website bei.

Mit Vservs Managed WordPress übernehmen wir unter anderem WordPress-Core-, Plugin- und Theme-Updates, Security Hardening, Monitoring, Backups, SSL, Performance-Optimierung und relevante Sicherheitskontrollen.

Zusammenfassung

• Produkt: WordPress Core
• Release: WordPress 7.1.3
• Veröffentlichungsdatum: 6. Oktober 2026
• Sicherheitskorrekturen: 7
• Unter anderem: Stored XSS, Second-Order SQL-Injection, Denial-of-Service und Information Disclosure
• CVE: unter anderem CVE-2026-66666
• CVE-2026-66666 CVSS: 6,9 – Medium
• Aktive Ausnutzung: zum Zeitpunkt der Veröffentlichung nicht bestätigt
• Empfohlene Version: WordPress 7.1.3 oder neuer
• Empfehlung: umgehend aktualisieren

Quellen

• WordPress.org – WordPress 7.1.3 Maintenance and Security Release
• WordPress.org – WordPress 7.1.3 Release-Dokumentation
• Patchstack – CVE-2026-66666
• CVE Program / CISA ADP – CVE-2026-66666

Die WordPress File Upload Sicherheitslücke CVE-2026-62071 ermöglicht einem nicht authentifizierten Angreifer eine SQL-Injection, ohne dass dafür ein WordPress-Benutzerkonto erforderlich ist. Die kritische Schwachstelle betrifft das inzwischen unter dem Namen Iptanus File Upload angebotene WordPress-Plugin und hat einen CVSS-Score von 9,3.

Die WordPress File Upload Sicherheitslücke betrifft Versionen bis einschließlich 5.1.10. Die Sicherheitskorrektur wurde mit Version 5.2.0 veröffentlicht. Vservs empfiehlt, betroffene Installationen umgehend auf Version 5.2.0 oder eine neuere verfügbare Version zu aktualisieren.

Was ist die WordPress File Upload Sicherheitslücke CVE-2026-62071?

CVE-2026-62071 ist eine unauthentifizierte SQL-Injection-Schwachstelle in WordPress File Upload, einem Plugin, das inzwischen unter dem Namen Iptanus File Upload angeboten wird.

Das Plugin ermöglicht es, Upload-Funktionen in WordPress-Websites zu integrieren, sodass Besucher oder Benutzer Dateien über die Website hochladen können.

Nach Angaben des Entwicklers befand sich das Sicherheitsproblem in der Verarbeitung eines Upload-Identifiers, der nicht vollständig bereinigt wurde, bevor die entsprechenden Daten verarbeitet wurden.

Unzureichend bereinigte Eingaben können dazu führen, dass vom Angreifer kontrollierte Daten die Struktur einer Datenbankabfrage beeinflussen, anstatt ausschließlich als normaler Datenwert behandelt zu werden.

Welche Versionen sind betroffen?

• WordPress File Upload / Iptanus File Upload 5.1.10 und älter – verwundbar
• Version 5.2.0 und neuer – Sicherheitskorrektur enthalten

Der offizielle WordPress.org-Changelog bestätigt für Version 5.2.0 ausdrücklich die Behebung einer über Patchstack gemeldeten SQL-Injection-Schwachstelle. Betroffen war ein Upload-Identifier, der nicht vollständig bereinigt wurde.

Administratoren sollten nach Möglichkeit die aktuellste stabile Version des Plugins installieren und nicht dauerhaft bei der ersten korrigierten Version bleiben.

Kein WordPress-Login erforderlich

Ein besonders wichtiger Aspekt von CVE-2026-62071 ist, dass ein Angreifer kein authentifiziertes WordPress-Benutzerkonto benötigt.

Der CVSS-3.1-Vektor lautet:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L

Dies bedeutet unter anderem:

• der Angriff kann remote über das Netzwerk erfolgen;
• die Angriffskomplexität ist niedrig;
• es sind keine Benutzerrechte erforderlich;
• es ist keine Benutzerinteraktion erforderlich;
• die Auswirkung auf die Vertraulichkeit wird als hoch eingestuft.

Diese Eigenschaften tragen zur kritischen CVSS-Bewertung von 9,3 bei.

Was kann eine SQL-Injection ermöglichen?

Bei einer SQL-Injection werden vom Angreifer kontrollierte Eingaben nicht ausreichend von einer Datenbankabfrage getrennt.

Dadurch kann ein Angreifer möglicherweise beeinflussen, wie die Datenbank eine Abfrage interpretiert.

Für CVE-2026-62071 weist der veröffentlichte CVSS-Vektor auf eine hohe Auswirkung auf die Vertraulichkeit, keine direkte Auswirkung auf die Integrität und eine geringe Auswirkung auf die Verfügbarkeit hin.

Das wichtigste bestätigte Risiko besteht daher im unbefugten Zugriff auf Informationen aus der WordPress-Datenbank.

Abhängig von der betroffenen Website und den dort gespeicherten Daten können dazu beispielsweise gehören:

• WordPress-Benutzerdaten;
• Passwort-Hashes;
• E-Mail-Adressen;
• Website-Konfigurationen;
• Plugin-Einstellungen;
• WooCommerce- oder Formulardaten, sofern diese in derselben Datenbank gespeichert sind;
• weitere sensible Anwendungsdaten, die von WordPress-Plugins gespeichert werden.

SQL-Injection bedeutet nicht automatisch Serverübernahme

CVE-2026-62071 sollte nicht als bestätigte Remote-Code-Execution-Schwachstelle beschrieben werden.

Die bestätigte Sicherheitslücke ist eine SQL-Injection. Die veröffentlichte CVSS-Bewertung weist insbesondere auf eine hohe Auswirkung auf die Vertraulichkeit hin.

Ob sich eine SQL-Injection in einer bestimmten Umgebung mit anderen Schwachstellen kombinieren lässt, hängt unter anderem von den Datenbankberechtigungen, der Serverkonfiguration und der zusätzlich installierten Software ab.

Vservs klassifiziert das Problem daher entsprechend der bestätigten technischen Informationen als kritische unauthentifizierte SQL-Injection.

Wird CVE-2026-62071 bereits aktiv ausgenutzt?

Zum Zeitpunkt der Veröffentlichung hat Vservs keine eindeutige Bestätigung gefunden, dass CVE-2026-62071 aktiv in freier Wildbahn ausgenutzt wird.

Das bedeutet nicht, dass eine Ausnutzung ausgeschlossen ist oder dass die Installation der Sicherheitsaktualisierung aufgeschoben werden sollte.

Insbesondere die Kombination aus Remote-Erreichbarkeit, fehlender Authentifizierung, niedriger Angriffskomplexität und einer bereits öffentlich bekannten Schwachstelle macht ein schnelles Update wichtig.

Was sollten WordPress-Administratoren jetzt tun?

1. Prüfen Sie, ob WordPress File Upload beziehungsweise Iptanus File Upload installiert ist.
2. Prüfen Sie die aktuell installierte Plugin-Version.
3. Aktualisieren Sie umgehend auf Version 5.2.0 oder neuer.
4. Kontrollieren Sie nach dem Update, ob tatsächlich die korrigierte Version aktiv ist.
5. Entfernen Sie das Plugin vollständig, wenn es nicht mehr benötigt wird.
6. Prüfen Sie, ob öffentlich zugängliche Upload-Funktionen tatsächlich erforderlich sind.
7. Kontrollieren Sie Webserver- und Security-Logs auf verdächtige Anfragen im Zusammenhang mit der Upload-Funktion.

Temporäre Maßnahmen, wenn ein Update nicht möglich ist

Kann Version 5.2.0 oder neuer nicht unmittelbar installiert werden, sollte das Plugin nach Möglichkeit vorübergehend deaktiviert werden.

Ist eine Deaktivierung aus betrieblichen Gründen nicht möglich, sollte der öffentliche Zugriff auf die betroffene Upload-Funktion bis zur Installation der Sicherheitsaktualisierung so weit wie möglich eingeschränkt werden.

Eine Web Application Firewall kann zusätzlichen Schutz gegen SQL-Injection-Versuche bieten, ersetzt jedoch nicht die Installation der offiziellen Sicherheitsaktualisierung.

Website auf mögliche Exploitation prüfen

Websites, auf denen Version 5.1.10 oder älter öffentlich erreichbar war, sollten auf Hinweise auf versuchte oder erfolgreiche Angriffe überprüft werden.

Administratoren sollten unter anderem auf folgende Auffälligkeiten achten:

• ungewöhnliche Requests an Seiten mit aktiver Upload-Funktion;
• ungewöhnlich lange oder auffällige Werte in Upload-Parametern und Identifiers;
• Requests mit SQL-typischer Syntax oder ungewöhnlicher Kodierung;
• eine große Anzahl ähnlicher Requests von einzelnen oder mehreren IP-Adressen;
• Datenbankfehler im zeitlichen Zusammenhang mit verdächtigen Web-Requests;
• unerwartet hohe Datenbanklast ohne funktionale Erklärung;
• PHP- oder Anwendungsfehler nach verdächtigen Requests;
• weitere ungewöhnliche Aktivitäten innerhalb der betroffenen Website oder Datenbank.

Ein verdächtiger HTTP-Request allein beweist nicht, dass tatsächlich Daten aus der Datenbank ausgelesen wurden.

Bei einem konkreten Verdacht sollten Webserver-Logs, Anwendungslogs, Datenbankaktivitäten und vorhandene Web-Application-Firewall-Logs gemeinsam ausgewertet werden.

Was tun, wenn ein Zugriff auf Daten vermutet wird?

Gibt es Hinweise darauf, dass ein Angreifer erfolgreich Informationen aus der WordPress-Datenbank auslesen konnte, sollte zunächst festgestellt werden, welche Daten möglicherweise betroffen waren.

Abhängig von der Website und den gespeicherten Informationen können weitere Maßnahmen erforderlich sein:

• betroffene Benutzerpasswörter zurücksetzen;
• WordPress Authentication Salts erneuern;
• möglicherweise betroffene API-Keys und Application Secrets ersetzen;
• Datenbank-Zugangsdaten ändern, sofern dies erforderlich ist;
• WordPress-Benutzerkonten und Berechtigungen überprüfen;
• WooCommerce-, Formular- und andere in der Datenbank gespeicherte Anwendungsdaten überprüfen;
• feststellen, ob personenbezogene Daten möglicherweise betroffen waren;
• prüfen, ob weitere Maßnahmen nach DSGVO oder anderen Datenschutzvorschriften erforderlich sind.

Zugangsdaten sollten aus einer vertrauenswürdigen Umgebung geändert werden, nachdem die betroffene Website untersucht und abgesichert wurde.

Managed WordPress Hosting bei Vservs

Viele schwerwiegende WordPress-Sicherheitsvorfälle entstehen nicht durch WordPress Core selbst, sondern durch verwundbare Plugins, die nach Veröffentlichung einer Sicherheitsaktualisierung zu lange ungepatcht erreichbar bleiben.

Mit Vservs Managed WordPress übernehmen wir unter anderem WordPress-Core-, Plugin- und Theme-Updates, Security Hardening, Monitoring, Backups, SSL und relevante Sicherheitskontrollen.

Zusammenfassung

• Plugin: WordPress File Upload / Iptanus File Upload
• CVE: CVE-2026-62071
• Schwachstelle: SQL-Injection
• Schweregrad: Critical
• CVSS: 9,3
• Aktive Installationen: 10.000+
• Betroffene Versionen: 5.1.10 und älter
• Gepatchte Version: 5.2.0 oder neuer
• Authentifizierung erforderlich: Nein
• Benutzerinteraktion erforderlich: Nein
• Hauptauswirkung: unbefugter Zugriff auf sensible Datenbankinformationen
• Aktive Ausnutzung: zum Zeitpunkt der Veröffentlichung nicht bestätigt
• Empfehlung: umgehend auf Version 5.2.0 oder neuer aktualisieren

Quellen

• Patchstack – CVE-2026-62071 / WordPress File Upload SQL-Injection
• NIST NVD – CVE-2026-62071
• CISA ADP Vulnrichment – CVE-2026-62071
• WordPress.org – Iptanus File Upload Changelog