Autor: Vincent Zeilmaker – Vservs UG

Die ACPT Premium Sicherheitslücke CVE-2026-105701 ermöglicht es einem authentifizierten WordPress-Benutzer mit lediglich Subscriber-Rechten, beliebigen Code auf dem Webserver auszuführen. Die Schwachstelle wird mit einem CVSS-Score von 8,8 als High eingestuft und kann zu Remote Code Execution führen.

Die ACPT Premium Sicherheitslücke betrifft alle Versionen bis einschließlich 2.0.66. Die Sicherheitskorrektur ist in Version 2.0.67 enthalten. Vservs empfiehlt, ACPT Premium umgehend auf die aktuellste verfügbare stabile Version zu aktualisieren.

Was ist die ACPT Premium Sicherheitslücke CVE-2026-105701?

CVE-2026-105701 ist eine Remote-Code-Execution-Schwachstelle in ACPT Premium, einem WordPress-Plugin zur Verwaltung unter anderem von Custom Post Types, Meta Fields, Formularen und dynamischen Inhalten.

Die Schwachstelle entsteht durch eine Kombination aus unzureichender Zugriffskontrolle und der unsicheren Verarbeitung von Twig-Templates.

Nach den veröffentlichten technischen Informationen bestehen dabei zwei wesentliche Sicherheitsprobleme:

• eine fehlende Capability-Prüfung bei einem REST-API-Endpunkt zum Erstellen von ACPT-Formularen;
• die Verarbeitung von E-Mail-Templates in einer nicht ausreichend eingeschränkten Twig-Umgebung.

Dadurch kann ein authentifizierter Benutzer mit eingeschränkten WordPress-Rechten ein speziell präpariertes Formular erstellen und schädliche Twig-Ausdrücke in dessen Konfiguration einfügen.

Wird das betreffende Formular anschließend verarbeitet, können diese Ausdrücke serverseitig ausgewertet werden. Dies kann zur Ausführung von beliebigem Code führen.

Welche ACPT Premium-Versionen sind betroffen?

• ACPT Premium 2.0.66 und älter – verwundbar
• ACPT Premium 2.0.67 und neuer – Sicherheitskorrektur enthalten

Administratoren sollten nach Möglichkeit nicht nur auf die erste korrigierte Version 2.0.67 aktualisieren, sondern die aktuellste stabile ACPT Premium-Version installieren.

Subscriber-Rechte reichen für einen Angriff aus

CVE-2026-105701 kann nicht vollständig ohne Authentifizierung ausgenutzt werden. Ein Angreifer benötigt ein gültiges WordPress-Benutzerkonto mit mindestens Subscriber-Rechten.

Das reduziert die Angriffsfläche gegenüber einer vollständig unauthentifizierten Remote-Code-Execution-Schwachstelle, macht das Problem jedoch keineswegs harmlos.

Subscriber ist die WordPress-Standardrolle mit den geringsten Berechtigungen. Auf Websites mit öffentlicher Benutzerregistrierung, Membership-Funktionen oder automatischer Kontoerstellung kann es für einen Angreifer vergleichsweise einfach sein, ein solches Konto zu erhalten.

Auch ein bereits kompromittiertes Benutzerkonto kann als Ausgangspunkt für einen Angriff dienen.

Wie funktioniert CVE-2026-105701?

Die Schwachstelle betrifft Funktionen zum Erstellen und Verarbeiten von ACPT-Formularen.

Aufgrund einer unzureichenden Berechtigungsprüfung kann ein Benutzer mit eingeschränkten Rechten Funktionen erreichen, die einem Subscriber normalerweise nicht zur Verfügung stehen sollten.

Ein Angreifer kann anschließend ein Formular erstellen, dessen E-Mail-Einstellungen speziell präparierte Inhalte enthalten.

ACPT verwendet Twig zur Verarbeitung bestimmter Templates. In den betroffenen Versionen ist diese Ausführungsumgebung nicht ausreichend eingeschränkt.

Bei der anschließenden Verarbeitung des manipulierten Formulars können die eingeschleusten Twig-Ausdrücke serverseitig ausgewertet werden. Dadurch kann der Angreifer Code innerhalb der WordPress- beziehungsweise PHP-Umgebung ausführen.

Warum ist Remote Code Execution so gefährlich?

Bei erfolgreicher Ausnutzung kann vom Angreifer kontrollierter Code im Kontext des PHP- beziehungsweise Webserver-Prozesses der betroffenen WordPress-Website ausgeführt werden.

Abhängig von der Hosting-Konfiguration kann ein Angreifer dadurch möglicherweise:

• WordPress-Dateien verändern;
• Malware oder Webshells installieren;
• Konfigurationsdateien und Datenbank-Zugangsdaten auslesen;
• WordPress-Zugangsdaten und andere Secrets auslesen;
• neue Administrator-Konten anlegen;
• Plugins oder Themes manipulieren;
• Daten aus der WordPress-Datenbank auslesen oder verändern;
• persistenten Zugriff auf die Website einrichten;
• die kompromittierte Website für weitere Angriffe verwenden.

In einer korrekt isolierten Hosting-Umgebung bedeutet Remote Code Execution innerhalb einer WordPress-Installation nicht automatisch Root-Zugriff auf den gesamten Server. Die betroffene Website selbst muss nach erfolgreicher Ausnutzung jedoch als potenziell vollständig kompromittiert betrachtet werden.

Wird CVE-2026-105701 bereits aktiv ausgenutzt?

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

Patchstack stuft die Schwachstelle allerdings als High Priority ein und weist darauf hin, dass Remote-Code-Execution-Schwachstellen dieser Art für automatisierte Angriffe und Massen-Exploitation attraktiv sind.

Dies ist kein Beleg dafür, dass bereits Angriffe stattfinden. Aufgrund der möglichen Auswirkungen sollte die verfügbare Sicherheitsaktualisierung dennoch ohne unnötige Verzögerung installiert werden.

Was sollten WordPress-Administratoren jetzt tun?

1. Prüfen Sie, ob ACPT Premium auf der Website installiert ist.
2. Prüfen Sie die aktuell installierte Plugin-Version.
3. Aktualisieren Sie mindestens auf ACPT Premium 2.0.67.
4. Installieren Sie nach Möglichkeit die aktuellste stabile ACPT Premium-Version.
5. Entfernen Sie nicht mehr benötigte Subscriber- und andere Benutzerkonten.
6. Prüfen Sie, ob eine öffentliche WordPress-Benutzerregistrierung tatsächlich erforderlich ist.
7. Kontrollieren Sie ACPT-Formulare und deren Konfiguration auf unerwartete Änderungen.
8. Führen Sie bei verdächtigen Aktivitäten zusätzliche Malware- und Integritätsprüfungen durch.

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

Kann ACPT Premium nicht unmittelbar aktualisiert werden, sollte das Plugin vorübergehend deaktiviert werden, sofern die Funktionalität nicht geschäftskritisch ist.

Zusätzlich sollte die öffentliche WordPress-Benutzerregistrierung deaktiviert werden, wenn diese nicht benötigt wird. Nicht mehr erforderliche Benutzerkonten sollten entfernt werden.

Eine Web Application Firewall kann eine zusätzliche Schutzebene bieten, ersetzt jedoch nicht die Installation der verfügbaren Sicherheitsaktualisierung.

Website auf eine mögliche Kompromittierung prüfen

Websites, auf denen ACPT Premium 2.0.66 oder älter eingesetzt wurde, sollten insbesondere dann überprüft werden, wenn nicht vertrauenswürdige Benutzer WordPress-Konten anlegen konnten.

Administratoren sollten unter anderem auf folgende Auffälligkeiten achten:

• unbekannte oder unerwartete WordPress-Benutzer;
• neu angelegte Subscriber-Konten im Zeitraum verdächtiger Aktivitäten;
• unerwartet angelegte ACPT-Formulare;
• verdächtige Werte in Formular- oder E-Mail-Template-Einstellungen;
• ungewöhnliche REST-API-Anfragen im Zusammenhang mit ACPT;
• unerwartete PHP-Dateien in wp-content oder anderen beschreibbaren Verzeichnissen;
• veränderte Plugin- oder Theme-Dateien;
• unbekannte Administrator-Konten;
• unbekannte WordPress-Cronjobs oder geplante Server-Aufgaben;
• unerwartete ausgehende Netzwerkverbindungen der Website.

Eine ungewöhnliche REST-API-Anfrage allein ist noch kein Beweis für eine erfolgreiche Ausnutzung. Verdächtige Requests sollten mit WordPress-Benutzern, ACPT-Konfigurationsdaten, Änderungen am Dateisystem und Webserver-Logs abgeglichen werden.

Was ist bei bestätigter Remote Code Execution zu tun?

Gibt es Hinweise darauf, dass tatsächlich beliebiger Code ausgeführt wurde, reicht es nicht aus, lediglich ACPT Premium zu aktualisieren.

Die vollständige WordPress-Installation sollte in diesem Fall als potenziell kompromittiert behandelt werden.

Mindestens folgende Bereiche sollten untersucht werden:

• WordPress-Core-Dateien;
• installierte Plugins und Themes;
• wp-config.php;
• WordPress-Benutzer und deren Rollen;
• Änderungen an der Datenbank;
• Upload- und temporäre Verzeichnisse;
• WordPress-Cronjobs und serverseitige Cronjobs;
• Webserver- und Anwendungslogs;
• API-Keys, Datenbank-Zugangsdaten und andere Secrets.

Relevante Passwörter, API-Keys und andere Zugangsdaten sollten nach der Bereinigung beziehungsweise Wiederherstellung aus einer vertrauenswürdigen Umgebung geändert werden.

Managed WordPress Hosting bei Vservs

WordPress-Sicherheit beschränkt sich nicht auf die Aktualisierung von WordPress Core. Plugins und Themes stellen einen erheblichen Teil der Angriffsfläche dar und müssen kontinuierlich gepflegt und auf Sicherheitsprobleme überwacht werden.

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

Zusammenfassung

• Plugin: ACPT Premium
• CVE: CVE-2026-105701
• Schwachstelle: Remote Code Execution
• CVSS: 8,8 – High
• Betroffene Versionen: 2.0.66 und älter
• Gepatchte Version: 2.0.67 oder neuer
• Erforderliche Berechtigungen: Subscriber oder höher
• Benutzerinteraktion: Nicht erforderlich
• Auswirkung: Ausführung von beliebigem serverseitigem Code im Kontext der WordPress-/Webserver-Umgebung
• Aktive Ausnutzung: Zum Zeitpunkt der Veröffentlichung nicht bestätigt
• Empfehlung: Umgehend auf die aktuellste stabile ACPT Premium-Version aktualisieren

Quellen

• Wordfence Intelligence – CVE-2026-105701
• Patchstack – ACPT Premium Remote Code Execution
• ACPT – offizielle Release- und Changelog-Informationen

Die Plesk Sicherheitslücke CVE-2026-68489 ermöglicht es einem authentifizierten Plesk-Benutzer, über verwundbare Versionen der Node.js Toolkit- oder Ruby-Erweiterung beliebige Befehle mit root-Rechten auszuführen. Eine erfolgreiche Ausnutzung kann dadurch zur vollständigen Übernahme des zugrunde liegenden Plesk-Servers führen.

Die Schwachstelle wird mit einem CVSS-4.0-Score von 8,7 (High) bewertet. Ein Angreifer benötigt ein authentifiziertes Plesk-Konto mit niedrigen Berechtigungen. Eine zusätzliche Benutzerinteraktion ist nicht erforderlich.

Betroffen ist Plesk for Linux. Plesk for Windows ist laut Hersteller von CVE-2026-68489 nicht betroffen.

Was ist die Plesk Sicherheitslücke CVE-2026-68489?

CVE-2026-68489 ist eine Static-Code-Injection-Schwachstelle in den Plesk-Erweiterungen Node.js Toolkit und Ruby.

Das Sicherheitsproblem betrifft die Verarbeitung benutzerdefinierter Environment Variables, die ein authentifizierter Hosting-Benutzer für seine Anwendungen konfigurieren kann.

In verwundbaren Versionen werden vom Benutzer kontrollierte Werte nicht ausreichend neutralisiert, bevor sie in Konfigurationen oder Code übernommen werden, die anschließend mit erhöhten Berechtigungen verarbeitet werden.

Dadurch kann ein normaler Plesk-Hosting-Benutzer unter den verwundbaren Bedingungen Befehle einschleusen, die letztlich als root ausgeführt werden.

Welche Plesk-Erweiterungen sind verwundbar?

• Node.js Toolkit 2.4.11 und älter – verwundbar
• Node.js Toolkit 2.5.0 oder neuer – gepatcht
• Ruby Extension 1.6.5 und älter – verwundbar
• Ruby Extension 1.6.6 oder neuer – gepatcht
• Plesk for Windows – nicht betroffen

Plesk-Administratoren können die installierten Versionen unter Extensions > My Extensions kontrollieren.

Node.js Toolkit muss mindestens Version 2.5.0 und die Ruby-Erweiterung mindestens Version 1.6.6 verwenden.

Warum ist Code-Ausführung als root besonders kritisch?

Eine Plesk-Hostingumgebung soll einzelne Hosting-Abonnements voneinander und vom zugrunde liegenden Betriebssystem isolieren.

Ein normaler Plesk-Benutzer sollte ausschließlich auf Dateien, Anwendungen und Ressourcen seines eigenen Hosting-Abonnements zugreifen können.

CVE-2026-68489 durchbricht diese Sicherheitsgrenze, weil eine erfolgreiche Ausnutzung die Ausführung von Befehlen als root ermöglicht.

Der root-Benutzer besitzt auf einem Linux-System praktisch uneingeschränkte Berechtigungen.

Ein Angreifer mit root-Zugriff kann abhängig von der Serverkonfiguration unter anderem Zugriff erhalten auf:

• andere Hosting-Accounts auf demselben Server;
• Websites und Webanwendungen;
• Datenbanken und Datenbank-Zugangsdaten;
• E-Mail-Daten;
• Webserver- und PHP-Konfigurationen;
• SSL-Private-Keys;
• Systembenutzer und Authentifizierungskonfiguration;
• SSH-Schlüssel;
• Firewall- und Netzwerkeinstellungen;
• Cronjobs und Systemdienste;
• Backup-Konfigurationen;
• weitere auf dem Server gespeicherte Zugangsdaten und Secrets.

Eine bestätigte erfolgreiche Ausnutzung von CVE-2026-68489 sollte deshalb als potenzielle Kompromittierung des vollständigen Plesk-Servers und nicht lediglich eines einzelnen Hosting-Accounts behandelt werden.

Welche Zugriffsrechte benötigt ein Angreifer?

Die Plesk Sicherheitslücke ist keine unauthenticated Remote-root-Schwachstelle.

Ein Angreifer benötigt bereits gültigen authentifizierten Zugang zu Plesk mit niedrigen Berechtigungen und muss die Funktionalität der verwundbaren Node.js Toolkit- oder Ruby-Erweiterung verwenden können.

Die offizielle CVSS-4.0-Bewertung verwendet unter anderem:

AV:N/AC:L/AT:N/PR:L/UI:N

Damit ist die Schwachstelle über das Netzwerk erreichbar, besitzt eine niedrige Angriffskomplexität, erfordert niedrige Privilegien und benötigt keine zusätzliche Benutzerinteraktion.

Gerade auf Shared- oder Multi-Tenant-Hostingservern ist dies ein schwerwiegender Bruch der Sicherheitsgrenze. Ein kompromittiertes oder böswilliges Kundenkonto darf niemals von normalen Hosting-Rechten zu root auf dem vollständigen Server eskalieren können.

Wie funktioniert die Schwachstelle?

CVE-2026-68489 wird als CWE-96 – Improper Neutralization of Directives in Statically Saved Code klassifiziert, auch als Static Code Injection bezeichnet.

Node.js Toolkit und Ruby ermöglichen Hosting-Benutzern die Konfiguration von Environment Variables für ihre Anwendungen.

Environment Variables sind an sich eine normale und notwendige Anwendungsfunktion. Das Sicherheitsproblem entsteht dadurch, dass speziell präparierte Werte in verwundbaren Versionen in einen Kontext gelangen können, der später als ausführbare Konfiguration interpretiert wird.

Da der betreffende Plesk-Prozess nachfolgende Aktionen mit erhöhten Berechtigungen durchführt, können eingeschleuste Befehle schließlich als root ausgeführt werden.

Das eigentliche Sicherheitsproblem besteht deshalb nicht darin, dass ein Kunde Environment Variables definieren darf, sondern darin, dass verwundbare Erweiterungen nicht ausreichend zwischen nicht vertrauenswürdigen Kundendaten und privilegiert ausgeführter Konfiguration trennen.

Wird CVE-2026-68489 aktiv ausgenutzt?

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

Die CISA-SSVC-Daten klassifizieren den Exploitationsstatus derzeit als none. Das bedeutet, dass in den dort ausgewerteten Informationen keine bestätigte aktive Ausnutzung vorliegt.

Dies sollte jedoch keinesfalls als Grund betrachtet werden, die Aktualisierung aufzuschieben. Die Schwachstelle kann zu root-level Code Execution führen und die gepatchten Erweiterungen sind bereits verfügbar.

Was sollten Plesk-Administratoren jetzt tun?

1. Als Administrator bei Plesk anmelden.
2. Zu Extensions > My Extensions wechseln.
3. Prüfen, ob Node.js Toolkit installiert ist.
4. Node.js Toolkit auf Version 2.5.0 oder neuer aktualisieren.
5. Prüfen, ob die Ruby-Erweiterung installiert ist.
6. Ruby auf Version 1.6.6 oder neuer aktualisieren.
7. Nach dem Update die tatsächlich installierten Versionsnummern erneut kontrollieren.
8. Hosting-Accounts überprüfen, die Node.js- oder Ruby-Funktionalität verwenden.
9. Verdächtige Konfigurationsänderungen aus dem Zeitraum kontrollieren, in dem eine verwundbare Erweiterung installiert war.

Temporäre Mitigation, wenn ein Update nicht sofort möglich ist

Plesk hat eine offizielle temporäre Mitigation veröffentlicht, falls die gepatchten Erweiterungen nicht sofort installiert werden können.

Für jeden aktiven Service Plan:

1. Den betreffenden Service Plan in Plesk öffnen.
2. Zum Tab Permissions wechseln.
3. Node.js support management deaktivieren.
4. Ruby support management deaktivieren.

Alternativ können Node.js Toolkit und/oder Ruby unter Extensions > My Extensions vorübergehend entfernt werden.

Das Entfernen der Erweiterungen führt dazu, dass davon abhängige Node.js- oder Ruby-Anwendungen auf dem Server nicht mehr funktionieren.

Diese Maßnahmen sind ausschließlich temporäre Workarounds. Das Aktualisieren auf die gepatchten Erweiterungsversionen bleibt die strukturelle Lösung.

Server auf eine mögliche Kompromittierung prüfen

Administratoren von Plesk-for-Linux-Servern, auf denen verwundbare Erweiterungsversionen aktiv waren, sollten das System auf Hinweise für unerwartete privilegierte Aktivitäten kontrollieren.

Achten Sie insbesondere auf:

• unerwartete Änderungen an Custom Environment Variables von Node.js- oder Ruby-Anwendungen;
• ungewöhnliche Anwendungskonfigurationen durch normale Plesk-Benutzer;
• unerwartete Prozesse, die rund um solche Änderungen als root gestartet wurden;
• verdächtige Einträge in Plesk-Panel- und Systemlogs;
• neue oder unbekannte Linux-Systembenutzer;
• Änderungen an SSH-authorized_keys-Dateien;
• neue oder geänderte Cronjobs;
• neue oder geänderte systemd-Services;
• unerwartete Firewall- oder Netzwerkkonfigurationsänderungen;
• neue ausführbare Dateien oder Scripts in temporären Verzeichnissen;
• unerwartete Änderungen an Websites anderer Hosting-Kunden;
• unbekannte Shell-Scripts, Webshells oder andere Persistence-Mechanismen.

Ein einzelner ungewöhnlicher Prozess oder eine Konfigurationsänderung beweist für sich allein keine erfolgreiche Ausnutzung von CVE-2026-68489.

Auffälligkeiten sollten mit Plesk-Logs, Authentifizierungsdaten, Prozessaktivitäten, Dateisystem-Zeitstempeln und anderen Systemlogs abgeglichen werden.

Untersuchung nicht auf einen Hosting-Account beschränken

Werden verdächtige Aktivitäten festgestellt, sollte die Untersuchung nicht ausschließlich auf das Hosting-Abonnement des möglicherweise angreifenden Benutzers beschränkt werden.

Die entscheidende Auswirkung dieser Schwachstelle ist die Eskalation zu root.

Sobald ein Angreifer erfolgreich Befehle als root ausgeführt hat, können die Sicherheitsgrenzen zwischen einzelnen Hosting-Accounts nicht mehr als vertrauenswürdig betrachtet werden.

Die Untersuchung muss deshalb auch das zugrunde liegende Betriebssystem und andere Hosting-Accounts umfassen.

Was tun bei bestätigter root-Kompromittierung?

Gibt es Beweise dafür, dass ein Angreifer tatsächlich Befehle als root ausgeführt hat, reicht das Aktualisieren von Node.js Toolkit oder Ruby nicht mehr aus.

Alle Informationen und Zugangsdaten, auf die root Zugriff hatte, müssen als potenziell offengelegt oder verändert betrachtet werden.

Dazu können gehören:

• System-Credentials;
• Datenbankpasswörter;
• API-Tokens;
• SSH-Private-Keys;
• SSL-Private-Keys;
• Plesk-Konfiguration;
• Website-Konfigurationsdateien;
• Mail-Zugangsdaten;
• Backup-Credentials;
• Zugangsdaten anderer Hosting-Kunden.

Kontrollieren Sie die Integrität von Systemdateien, Benutzern, SSH-Konfiguration, geplanten Aufgaben, Systemdiensten, Firewallregeln, Plesk-Konfiguration und gehosteten Anwendungen.

Relevante Credentials und Secrets sollten nach Wiederherstellung einer vertrauenswürdigen Umgebung ausgetauscht werden.

Abhängig vom Umfang einer bestätigten root-Kompromittierung kann eine saubere Neuinstallation des Servers mit anschließender Migration überprüfter Daten eine höhere Sicherheit bieten als der Versuch, sämtliche mögliche Persistence aus einem kompromittierten Betriebssystem zu entfernen.

Plesk for Windows ist nicht betroffen

Plesk bestätigt ausdrücklich, dass Plesk for Windows von CVE-2026-68489 nicht betroffen ist.

Die verwundbaren Komponenten und der beschriebene Privilege-Escalation-Pfad betreffen Node.js Toolkit und Ruby auf Plesk for Linux.

Administratoren sollten deshalb zunächst das verwendete Betriebssystem und die tatsächlich installierten Erweiterungen feststellen, bevor sie die Exposition des Servers bewerten.

Managed VPS bei Vservs

Die Absicherung einer Hostingumgebung erfordert mehr als ausschließlich Betriebssystemupdates. Auch Controlpanelsoftware und installierte Erweiterungen müssen kontinuierlich überwacht und aktualisiert werden.

Mit einem Managed VPS von Vservs übernehmen wir unter anderem das technische Servermanagement, relevante Betriebssystem- und Sicherheitsupdates, Monitoring und Server-Hardening.

Bei Unmanaged VPS-Servern bleibt die Bewertung, Installation und Kontrolle von Plesk-, Extension- und Betriebssystem-Sicherheitsupdates in der Verantwortung des Serveradministrators.

Zusammenfassung

• Software: Plesk for Linux
• Betroffene Komponenten: Node.js Toolkit und Ruby Extension
• CVE: CVE-2026-68489
• Schwachstellentyp: Static Code Injection / Local Privilege Escalation
• Severity: High
• CVSS 4.0: 8,7
• Betroffene Node.js Toolkit-Versionen: 2.4.11 und älter
• Abgesicherte Node.js Toolkit-Version: 2.5.0 oder neuer
• Betroffene Ruby-Versionen: 1.6.5 und älter
• Abgesicherte Ruby-Version: 1.6.6 oder neuer
• Plesk for Windows: nicht betroffen
• Authentifizierung erforderlich: Ja, Plesk-Benutzer mit niedrigen Berechtigungen
• Benutzerinteraktion: Keine
• Auswirkung: beliebige Befehlsausführung als root und mögliche vollständige Serverkompromittierung
• Aktive Ausnutzung: zum Zeitpunkt der Veröffentlichung nicht bestätigt
• Empfehlung: beide betroffenen Erweiterungen sofort aktualisieren

Quellen

• Plesk – Security Advisory zu CVE-2026-68489
• NVD – CVE-2026-68489

Die All in One SEO Sicherheitslücke CVE-2026-100152 ermöglicht es einem nicht authentifizierten Angreifer unter bestimmten Voraussetzungen, beliebige WordPress-Shortcodes auszuführen. Die Schwachstelle hat einen CVSS-Score von 6,5 und betrifft All in One SEO bis einschließlich Version 5.0.2.

All in One SEO, häufig als AIOSEO bezeichnet, wird auf mehr als 2 Millionen WordPress-Websites eingesetzt. Aufgrund dieser großen Installationsbasis ist die Schwachstelle trotz ihrer Einstufung als Medium für WordPress-Betreiber relevant.

Die Sicherheitskorrektur ist in All in One SEO 5.0.2.1 enthalten. Der offizielle Changelog bestätigt, dass diese Version die Sicherheitsmaßnahmen für Shortcodes auf WordPress-Suchseiten verbessert.

Was ist die All in One SEO Sicherheitslücke CVE-2026-100152?

CVE-2026-100152 betrifft die Verarbeitung von WordPress-Suchanfragen, wenn AIOSEO-Breadcrumbs auf der Suchergebnisseite ausgegeben werden.

In verwundbaren Versionen wird vom Besucher beeinflussbare Suchtexteingabe nicht ausreichend validiert, bevor der betreffende Inhalt die WordPress-Shortcode-Verarbeitung über do_shortcode() erreicht.

Dadurch kann ein externer Angreifer ohne WordPress-Benutzerkonto unter den erforderlichen Bedingungen einen auf der Website registrierten Shortcode ausführen lassen.

Welche All in One SEO-Versionen sind verwundbar?

• All in One SEO 5.0.2 und älter – verwundbar
• All in One SEO 5.0.2.1 oder neuer – Sicherheitskorrektur vorhanden

Der offizielle AIOSEO-Changelog nennt bei Version 5.0.2.1 ausdrücklich verbesserte Sicherheitsmaßnahmen für Shortcodes auf Suchseiten.

Administratoren sollten deshalb mindestens auf Version 5.0.2.1 oder eine neuere verfügbare Version aktualisieren.

Kein WordPress-Login erforderlich

Für die beschriebene Angriffskette benötigt ein Angreifer kein authentifiziertes WordPress-Benutzerkonto.

Die Schwachstelle ist über eine öffentlich erreichbare WordPress-Suchanfrage ausnutzbar, sofern die zusätzlich erforderliche AIOSEO-Breadcrumb-Konfiguration vorhanden ist.

Damit unterscheidet sich CVE-2026-100152 von Sicherheitsproblemen, bei denen zunächst Contributor-, Editor- oder Administratorrechte erforderlich sind.

AIOSEO-Breadcrumbs auf der Suchergebnisseite sind erforderlich

Nicht jede WordPress-Installation mit All in One SEO ist über die dokumentierte Angriffskette direkt ausnutzbar.

AIOSEO-Breadcrumbs müssen auf der WordPress-Suchergebnisseite ausgegeben werden.

Dies kann beispielsweise erfolgen über:

• den AIOSEO Breadcrumbs Block;
• ein AIOSEO-Widget;
• den AIOSEO-Breadcrumb-Shortcode;
• einen Template-Tag im verwendeten WordPress-Theme;
• eine individuelle Template-Integration.

Werden AIOSEO-Breadcrumbs auf Suchergebnisseiten nicht gerendert, ist die dokumentierte Angriffskette nicht direkt verfügbar.

Diese Konfigurationsbedingung ist jedoch kein Grund, eine veraltete Plugin-Version installiert zu lassen. Die strukturelle Lösung bleibt das Update.

Was bedeutet beliebige Shortcode-Ausführung?

WordPress-Shortcodes sind serverseitige Befehle, die von WordPress Core, Plugins oder Themes registriert werden.

Sie werden normalerweise innerhalb vertrauenswürdiger WordPress-Inhalte eingesetzt, um dynamische Inhalte oder bestimmte Funktionen auszuführen.

Die tatsächlichen Auswirkungen einer beliebigen Shortcode-Ausführung hängen deshalb davon ab, welche Shortcodes auf der betroffenen WordPress-Installation verfügbar sind.

Einige Shortcodes zeigen lediglich harmlose Inhalte an. Andere können Funktionen bereitstellen, die beispielsweise:

• Daten aus der WordPress-Datenbank abrufen;
• Informationen anzeigen, die nicht über öffentliche Suchanfragen erreichbar sein sollten;
• Formulare oder andere serverseitige Aktionen ausführen;
• HTTP-Requests vom Server aus starten;
• Funktionen anderer WordPress-Plugins aktivieren;
• mit Benutzer-, Membership- oder Shop-Funktionen interagieren.

Shortcode-Ausführung ist nicht automatisch Remote Code Execution

CVE-2026-100152 sollte nicht automatisch als PHP Remote Code Execution bezeichnet werden.

Die primäre Schwachstelle ermöglicht die Ausführung von WordPress-Shortcodes. Ob daraus eine weitergehende Kompromittierung entstehen kann, hängt vollständig von den auf der jeweiligen Website registrierten Shortcodes ab.

Eine WordPress-Installation mit ausschließlich harmlosen Shortcodes hat ein anderes praktisches Risikoprofil als eine Website, auf der ein anderes Plugin einen leistungsfähigen Shortcode mit sensibler serverseitiger Funktionalität bereitstellt.

Vservs beschreibt CVE-2026-100152 deshalb als unauthenticated arbitrary shortcode execution und nicht als garantierte Serverübernahme.

Warum ist die Schwachstelle trotz CVSS 6,5 relevant?

CVE-2026-100152 hat einen CVSS-Score von 6,5 und wird als Medium eingestuft.

Für WordPress-Betreiber sind jedoch zwei zusätzliche Faktoren wichtig:

• für die Angriffskette ist kein WordPress-Konto erforderlich;
• All in One SEO wird auf mehr als 2 Millionen WordPress-Websites eingesetzt.

Eine öffentlich dokumentierte Schwachstelle in einem Plugin mit einer derart großen Installationsbasis kann für automatisierte Internet-Scans interessant werden.

Da eine Sicherheitskorrektur bereits verfügbar ist, besteht kein sinnvoller Grund, die Aktualisierung unnötig aufzuschieben.

Wird CVE-2026-100152 aktiv ausgenutzt?

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

Die Schwachstelle ist öffentlich dokumentiert und technische Informationen über den betroffenen Codepfad sind verfügbar.

Öffentlich verfügbare technische Informationen oder Exploit-Forschung sind jedoch nicht mit einem Nachweis tatsächlich beobachteter Angriffe gleichzusetzen.

Vservs empfiehlt aufgrund der fehlenden Authentifizierung und der sehr großen Installationsbasis eine zeitnahe Aktualisierung, bezeichnet die Schwachstelle derzeit jedoch nicht als aktiv ausgenutzt.

Was sollten WordPress-Administratoren jetzt tun?

1. Kontrollieren, ob All in One SEO installiert ist.
2. Die exakt installierte Plugin-Version überprüfen.
3. Auf All in One SEO 5.0.2.1 oder neuer aktualisieren.
4. Kontrollieren, ob das Update erfolgreich abgeschlossen wurde.
5. Prüfen, ob AIOSEO-Breadcrumbs auf WordPress-Suchergebnisseiten ausgegeben werden.
6. Individuelle Themes und Templates auf AIOSEO-Breadcrumb-Template-Tags kontrollieren.
7. Nach dem Update gegebenenfalls Page Cache, Reverse-Proxy-Cache und CDN-Cache leeren.

Temporäre Mitigation, wenn ein Update nicht sofort möglich ist

Kann das Sicherheitsupdate nicht sofort installiert werden, sollte die Ausgabe von AIOSEO-Breadcrumbs auf WordPress-Suchergebnisseiten vorübergehend entfernt oder deaktiviert werden.

Damit entfällt eine notwendige Voraussetzung für die dokumentierte Angriffskette.

Kann nicht zuverlässig festgestellt werden, ob Breadcrumbs auf Suchseiten ausgegeben werden, ist das vorübergehende Deaktivieren von All in One SEO sicherer, als eine bekannte verwundbare Konfiguration öffentlich erreichbar zu lassen.

Eine Web Application Firewall kann zusätzliche Schutzmechanismen bieten, ersetzt das Plugin-Update jedoch nicht.

Auf mögliche Exploit-Versuche prüfen

Administratoren von Websites, auf denen All in One SEO 5.0.2 oder älter installiert war, sollten insbesondere Aktivitäten rund um WordPress-Suchseiten überprüfen.

Kontrollieren Sie Webserver- und Applikationslogs auf:

• ungewöhnliche Requests an WordPress-Suchergebnisseiten;
• Suchparameter mit shortcode-ähnlicher Syntax;
• große Mengen automatisierter Suchrequests von derselben oder verwandten IP-Adressen;
• kodierte oder verschleierte Shortcode-Syntax in Suchparametern;
• unerwartete WordPress- oder Pluginaktionen unmittelbar nach verdächtigen Suchrequests;
• unerwartete serverseitige Requests an externe oder interne Ziele;
• PHP- oder Applikationsfehler im Zusammenhang mit verdächtigen Suchanfragen.

Ein ungewöhnlicher Suchrequest beweist für sich allein keine erfolgreiche Ausnutzung.

Zunächst sollte festgestellt werden, ob AIOSEO-Breadcrumbs tatsächlich auf der Suchergebnisseite gerendert wurden und welche Shortcodes auf der betreffenden WordPress-Installation verfügbar waren.

Auf mögliche Folgeschäden prüfen

Gibt es Hinweise darauf, dass ein sicherheitsrelevanter Shortcode tatsächlich ausgeführt wurde, sollte genau geprüft werden, welche Funktion dieser Shortcode bereitstellt.

Abhängig vom betroffenen Shortcode können zusätzliche Kontrollen erforderlich sein:

• WordPress-Benutzer- und Administratorkonten;
• aktuelle Änderungen an Benutzerrollen;
• neu installierte oder veränderte Plugins;
• Änderungen an Themes;
• unerwartete Änderungen an WordPress-Einstellungen;
• Datenbankänderungen;
• neue oder veränderte PHP-Dateien;
• unerwartete ausgehende Netzwerkverbindungen;
• relevante WordPress- und Webserver-Logs.

Werden Hinweise auf nicht autorisierte Administratoraktionen oder serverseitige Code-Ausführung gefunden, sollte die WordPress-Installation als potenziell kompromittiert behandelt werden. Das alleinige Aktualisieren von All in One SEO reicht dann nicht mehr aus.

Managed WordPress bei Vservs

Aktuelle WordPress-Plugins sind ein wichtiger Bestandteil, um das Zeitfenster für die Ausnutzung öffentlich bekannter Schwachstellen möglichst klein zu halten.

Mit Vservs Managed WordPress übernehmen wir unter anderem WordPress Core-, Plugin- und Theme-Updates, Hardening, Monitoring, Malware-Kontrollen und Backups.

Für Websites, die eine eigene isolierte Serverumgebung benötigen, bietet Vservs außerdem Managed VPS mit technischem Servermanagement, relevanten Betriebssystem- und Sicherheitsupdates, Monitoring und Server-Hardening.

Zusammenfassung

• Plugin: All in One SEO
• CVE: CVE-2026-100152
• Severity: Medium
• CVSS: 6,5
• Aktive Installationen: mehr als 2 Millionen
• Betroffene Versionen: 5.0.2 und älter
• Abgesicherte Version: 5.0.2.1 oder neuer
• Authentifizierung erforderlich: Nein
• Auswirkung: unauthenticated arbitrary WordPress shortcode execution
• Voraussetzung: AIOSEO-Breadcrumbs werden auf der Suchergebnisseite gerendert
• Aktive Ausnutzung: zum Zeitpunkt der Veröffentlichung nicht bestätigt
• Empfehlung: auf 5.0.2.1 oder neuer aktualisieren

Quellen

• AIOSEO – offizieller Changelog
• WordPress.org – All in One SEO
• NVD – CVE-2026-100152

Das Joomla Sicherheitsupdate 6.1.4 und Joomla 5.4.9 behebt insgesamt 16 Sicherheitslücken in Joomla Core, darunter Server-Side Request Forgery, beliebiges Löschen von Verzeichnissen durch Path Traversal, einen MFA-Bypass sowie mehrere Probleme bei der Zugriffskontrolle. Das Joomla Project hat beide abgesicherten Versionen am 29. September 2026 veröffentlicht.

Mehrere der behobenen Schwachstellen haben einen hohen technischen Impact. Weitere Probleme betreffen Authentifizierung, Autorisierung und Cross-Site-Scripting-Schutz innerhalb von Joomla Core.

Administratoren mit Joomla 5 sollten auf Joomla 5.4.9 aktualisieren. Joomla-6-Installationen sollten auf Joomla 6.1.4 aktualisiert werden.

Was behebt das Joomla Sicherheitsupdate?

Das Joomla Sicherheitsupdate enthält insgesamt 16 Security-Fixes in verschiedenen Bereichen von Joomla Core.

Zu den wichtigsten Schwachstellen gehören:

• CVE-2026-90915: beliebiges Löschen von Verzeichnissen durch Path Traversal in der Cache-Purge-Funktion;
• CVE-2026-92222: Server-Side Request Forgery in verschiedenen Joomla-Core-Erweiterungen;
• CVE-2026-92227: Umgehung der Multi-Faktor-Authentifizierung durch zu früh ausgegebene Remember-Me-Cookies;
• CVE-2026-92226: unzureichende ACL-Prüfungen bei verschiedenen Web-Services-Editieraktionen;
• nicht autorisierte Erstellung von Benutzerkonten unter bestimmten Voraussetzungen;
• mehrere Cross-Site-Scripting-Schwachstellen;
• weitere Fehler bei der Zugriffskontrolle innerhalb von Joomla Core.

Der genaue betroffene Versionsbereich unterscheidet sich je nach Schwachstelle. Mehrere der wichtigsten Probleme betreffen Joomla 4.0.0 bis 5.4.8 sowie Joomla 6.0.0 bis 6.1.3.

CVE-2026-90915: Verzeichnisse durch Path Traversal löschen

CVE-2026-90915 betrifft die Cache-Purge-Funktion von Joomla und wird vom Joomla Project mit High Impact und High Severity bewertet.

Der Name einer Cache-Gruppe wurde nicht ausreichend validiert, bevor er für Dateisystemoperationen verwendet wurde.

Dadurch war Path Traversal innerhalb des Cache-Layers möglich. Unter den betroffenen Bedingungen konnten Verzeichnisse außerhalb des vorgesehenen Cache-Verzeichnisses gelöscht werden.

Das Joomla Project nennt folgende Installationen als betroffen:

• Joomla 4.0.0 bis einschließlich 5.4.8;
• Joomla 6.0.0 bis einschließlich 6.1.3.

Die Schwachstelle wurde in Joomla 5.4.9 und Joomla 6.1.4 behoben.

CVE-2026-92222: Server-Side Request Forgery in Joomla Core

CVE-2026-92222 ist eine weitere High-Severity-Schwachstelle, die mit dem Joomla Sicherheitsupdate behoben wurde.

URLs, die von verschiedenen Joomla-Core-Erweiterungen für serverseitige Requests verwendet werden, wurden nicht ausreichend validiert. Dadurch entstanden Server-Side-Request-Forgery-Angriffsvektoren.

Bei SSRF kann ein Angreifer beeinflussen, welche Netzwerkrequests vom Joomla-Server selbst ausgeführt werden.

Das ist sicherheitsrelevant, weil der Webserver möglicherweise Netzwerkziele erreichen kann, die aus dem öffentlichen Internet nicht direkt erreichbar sind.

Abhängig von der Hosting- und Netzwerkumgebung können beispielsweise folgende Ziele relevant sein:

• interne HTTP-Dienste;
• Anwendungen auf privaten IP-Adressen;
• Dienste auf localhost;
• interne Management-Endpunkte;
• Cloud-Metadata-Dienste, sofern diese in der Umgebung vorhanden und erreichbar sind.

Die tatsächliche Auswirkung hängt deshalb von der Netzwerkarchitektur und den vom Joomla-Server erreichbaren Diensten ab.

Joomla bewertet CVE-2026-92222 mit High Severity und High Impact. Die Exploit Probability wird als Low eingestuft.

CVE-2026-92227 kann Multi-Faktor-Authentifizierung umgehen

CVE-2026-92227 betrifft die Remember-Me-Funktion von Joomla in Kombination mit der Multi-Faktor-Authentifizierung.

Laut Joomla konnte ein Remember-Me-Cookie zu früh innerhalb des Authentifizierungsprozesses ausgegeben werden.

Unter den betroffenen Bedingungen konnte dadurch bei einer späteren Frontend-Anmeldung die MFA-Prüfung umgangen werden.

Dies bedeutet nicht, dass ein beliebiger nicht authentifizierter Besucher automatisch auf ein Joomla-Konto zugreifen kann.

Die primäre Authentifizierung bleibt relevant. MFA soll jedoch gerade eine zusätzliche Sicherheitsbarriere darstellen, wenn ein Passwort bereits kompromittiert wurde.

Eine Möglichkeit, diesen zweiten Faktor zu umgehen, schwächt deshalb einen wichtigen Schutzmechanismus für Benutzer- und Administratorkonten.

Joomla bewertet den Impact als High, die Severity als Moderate und die Exploit Probability als Moderate.

CVE-2026-92226: unzureichende Zugriffskontrolle

CVE-2026-92226 betrifft ACL-Prüfungen bei verschiedenen Editieraktionen über die Joomla Web Services.

Unzureichende Zugriffskontrollen konnten dazu führen, dass Benutzer Änderungen an Objekten durchführen konnten, für die sie entsprechend ihrer zugewiesenen Berechtigungen eigentlich keine Editierrechte besitzen sollten.

Diese Schwachstelle ist insbesondere für Joomla-Websites und Integrationen relevant, die die Web Services API verwenden.

Joomla bewertet CVE-2026-92226 mit Moderate Severity und High Impact.

Auch nicht autorisierte Benutzerkontoerstellung behoben

Die Securityrelease behebt außerdem eine Schwachstelle im profile.save-Controller, über die unter bestimmten Bedingungen nicht autorisierte Benutzerkonten erstellt werden konnten.

Der Loginstatus wurde nicht ausreichend überprüft. Dadurch konnte ein Besucher ein Benutzerkonto auf Guest-Level erstellen, obwohl die öffentliche Benutzerregistrierung vom Administrator deaktiviert war.

Ein Guest-Konto ist nicht mit einem Joomla-Super-User-Konto gleichzusetzen. Die Schwachstelle umgeht jedoch eine ausdrückliche Sicherheits- und Konfigurationsentscheidung des Website-Administrators.

Mehrere Cross-Site-Scripting-Schwachstellen

Das Joomla Sicherheitsupdate behebt zusätzlich mehrere Cross-Site-Scripting-Probleme in Joomla Core.

Dazu gehören Schwachstellen in Zusammenhang mit:

• der Methode HTMLHelper::link;
• generischen Media-Output-Layouts;
• HTML-E-Mail-Templates;
• dem Link-Toolbar-Layout;
• Modullisten;
• Joomlas InputFilter und der Verarbeitung von HTML5-Entities;
• HTML-Data-URIs mit ungewöhnlichen Whitespace-Zeichen.

Nicht jede dieser Schwachstellen ist auf jeder Joomla-Installation gleichermaßen erreichbar. Die praktische Angriffsfläche hängt von den aktivierten Funktionen, Benutzerrechten und der Website-Konfiguration ab.

Welche Joomla-Versionen müssen aktualisiert werden?

• Joomla 5.x bis einschließlich 5.4.8 – von einer oder mehreren Schwachstellen betroffen
• Joomla 5.4.9 – Security-Fixes vorhanden
• Joomla 6.x bis einschließlich 6.1.3 – von einer oder mehreren Schwachstellen betroffen
• Joomla 6.1.4 – Security-Fixes vorhanden

Einige einzelne Schwachstellen reichen außerdem bis in ältere Joomla-Versionen zurück.

Websites auf nicht mehr unterstützten Joomla-Versionen sollten das Fehlen eines neuen Updates für ihren Versionszweig nicht als Hinweis darauf interpretieren, dass die Installation sicher ist. Für solche Systeme sollte eine Migration auf eine aktuell unterstützte Joomla-Version geplant werden.

Joomla-5-Nutzer müssen wegen dieser Security-Fixes nicht sofort auf Joomla 6 migrieren

Administratoren mit Joomla 5.4 müssen nicht allein aufgrund dieser Schwachstellen ein Major-Upgrade auf Joomla 6 durchführen.

Joomla 5.4.9 enthält die relevanten Security-Fixes für den Joomla-5-Zweig.

Eine Migration auf Joomla 6 kann separat geplant und zunächst auf Kompatibilität mit Erweiterungen, Templates und individuellen Integrationen getestet werden.

Wichtig: bekanntes Web-Services-API-Problem in Joomla 5.4.9

Das Joomla Project hat eine separate funktionale Regression in Joomla 5.4.9 dokumentiert.

PATCH-Requests über die Web Services API können mit einem Fatal Error fehlschlagen, wenn beispielsweise ein Banner oder ein Benutzer über die API aktualisiert werden soll.

Joomla hat hierfür einen offiziellen Workaround veröffentlicht. Die dauerhafte Korrektur soll in Joomla 5.4.10 enthalten sein.

Joomla 6.1.4 ist von dieser spezifischen Regression nicht betroffen.

Joomla-5-Websites, die Web-Services-API-PATCH-Requests verwenden, sollten das Update deshalb zunächst in einer Staging-Umgebung testen und bei Bedarf den offiziellen Workaround anwenden.

Die Regression ist jedoch kein Grund, eine verwundbare Joomla-5.4.8-Installation dauerhaft ungepatcht zu lassen.

Werden die neuen Joomla-Schwachstellen aktiv ausgenutzt?

Zum Zeitpunkt dieser Veröffentlichung hat Vservs keine zuverlässige Bestätigung gefunden, dass die in diesem Joomla Sicherheitsupdate behandelten Schwachstellen aktiv in freier Wildbahn ausgenutzt werden.

Das Joomla Project veröffentlicht bei den Security Advisories eine Exploit Probability. Diese Einstufung ist eine Risikobewertung und kein Nachweis tatsächlich beobachteter Angriffe.

Beispielsweise bewertet Joomla die Exploit Probability von CVE-2026-92222 und CVE-2026-90915 als Low, während CVE-2026-92227 als Moderate eingestuft wird.

Da technische Details und die abgesicherten Versionen inzwischen öffentlich verfügbar sind, sollten Administratoren mit dem Update nicht auf Hinweise für aktive Angriffe warten.

Was sollten Joomla-Administratoren jetzt tun?

1. Die exakt installierte Joomla-Version kontrollieren.
2. Vor dem Update eine vollständige Sicherung der Website-Dateien und Datenbank erstellen.
3. Joomla-5-Installationen auf 5.4.9 oder neuer aktualisieren.
4. Joomla-6-Installationen auf 6.1.4 oder neuer aktualisieren.
5. Kontrollieren, ob das Update erfolgreich abgeschlossen wurde.
6. Frontend und Joomla Administrator anschließend testen.
7. Installierte Erweiterungen und Templates überprüfen.
8. Web-Services-API-Integrationen testen, sofern diese verwendet werden.
9. Bei Joomla 5.4.9 den offiziellen Workaround prüfen, wenn PATCH-Requests benötigt werden.
10. Benutzerkonten, Authentifizierungsaktivitäten und Webservice-Aktionen auf Auffälligkeiten kontrollieren.

Website auf eine mögliche Kompromittierung prüfen

Da das Joomla Sicherheitsupdate 16 unterschiedliche Schwachstellen behebt, gibt es keinen einzelnen universellen Indicator of Compromise, der die Ausnutzung aller Probleme zuverlässig erkennt.

Abhängig von den auf der Website verwendeten Funktionen sollten Administratoren unter anderem kontrollieren:

• unerwartete ausgehende HTTP- oder HTTPS-Verbindungen vom Joomla-Server;
• Requests zu internen IP-Adressen, localhost-Diensten oder ungewöhnlichen Netzwerkzielen;
• unerwartet gelöschte Verzeichnisse;
• Dateisystemfehler im Zusammenhang mit Joomla-Cache-Operationen;
• verdächtige Remember-Me-Anmeldungen;
• Authentifizierungen, bei denen normalerweise MFA erwartet worden wäre;
• unbekannte Joomla-Benutzerkonten;
• unerwartete Änderungen an bestehenden Benutzerrechten;
• Webservice-Editieraktionen, die nicht zu den ACL-Rechten des betreffenden Benutzers passen;
• unerwartete Änderungen an Joomla-Inhalten oder der Konfiguration;
• verdächtige Script- oder HTML-Inhalte, die auf einen XSS-Versuch hinweisen können.

Ein ungewöhnlicher Request, Login oder Dateisystemvorgang beweist für sich allein noch keine erfolgreiche Ausnutzung. Auffälligkeiten sollten mit Joomla-, Webserver-, Reverse-Proxy- und Firewall-Logs sowie Dateisystem-Zeitstempeln abgeglichen werden.

Was tun, wenn verdächtige Aktivitäten gefunden werden?

Wird ein unbekanntes privilegiertes Konto, eine nicht erklärte Dateisystemänderung oder ein anderer deutlicher Hinweis auf nicht autorisierten Zugriff entdeckt, reicht das einfache Aktualisieren von Joomla nicht mehr aus.

Die Installation sollte dann als potenziell kompromittiert behandelt werden.

Joomla Core, Erweiterungen, Templates, Benutzerkonten, geplante Aufgaben und relevante Server-Logs sollten überprüft werden. Anwendungsdateien sollten, wo möglich, mit vertrauenswürdigen Originaldateien verglichen werden.

Zugangsdaten, auf die aus der betroffenen Joomla-Umgebung zugegriffen werden konnte, sollten nach Wiederherstellung der Integrität ebenfalls überprüft und gegebenenfalls geändert werden.

Managed VPS bei Vservs

Die Absicherung eines Content-Management-Systems erfordert sowohl die Pflege der Anwendung als auch der zugrunde liegenden Hostingumgebung.

Mit einem Vservs Managed VPS übernehmen wir unter anderem die technische Serververwaltung, relevante Betriebssystem- und Sicherheitsupdates, Monitoring und Server-Hardening.

Auch Joomla Core, Erweiterungen und Templates müssen aktuell gehalten werden. Nicht mehr unterstützte Joomla-Versionen sollten rechtzeitig auf eine unterstützte Release-Serie migriert werden.

Zusammenfassung

• Software: Joomla CMS
• Anzahl Security-Fixes: 16
• Abgesicherte Joomla-5-Version: 5.4.9
• Abgesicherte Joomla-6-Version: 6.1.4
• Veröffentlichung: 29. September 2026
• Wichtige CVEs: CVE-2026-90915, CVE-2026-92222, CVE-2026-92227 und CVE-2026-92226
• Impact: SSRF, Directory Deletion durch Path Traversal, MFA-Bypass, fehlerhafte Zugriffskontrolle, nicht autorisierte Kontoerstellung und mehrere XSS-Schwachstellen
• Aktive Ausnutzung: zum Zeitpunkt der
  

Das ModSecurity Sicherheitsupdate auf libmodsecurity3 3.0.17 und mod_security2 2.9.15 behebt acht Sicherheitsprobleme in der weit verbreiteten Web Application Firewall. Mehrere Schwachstellen ermöglichen eine Umgehung von Sicherheitsregeln. Ein weiteres Problem in libmodsecurity3 kann unter bestimmten Konfigurationen Speicherfehler verursachen und möglicherweise den Ausführungsfluss eines Prozesses beeinflussen.

ModSecurity wird auf Hosting-Servern häufig als zusätzliche Sicherheitsschicht vor WordPress, Joomla, Magento, Adobe Commerce und anderen Webanwendungen eingesetzt. In Kombination mit Regelwerken wie dem OWASP Core Rule Set werden HTTP-Requests und Responses analysiert, bevor sie die eigentliche Anwendung erreichen beziehungsweise an den Besucher ausgeliefert werden.

Die neuen Schwachstellen bedeuten deshalb nicht zwangsläufig, dass ModSecurity selbst unmittelbar zur Übernahme einer Website führt. Mehrere der Probleme schwächen vielmehr die Schutzwirkung der Web Application Firewall. Angriffe, die normalerweise erkannt oder blockiert werden sollten, können dadurch unter bestimmten Bedingungen die dahinterliegende Webanwendung erreichen.

Welche Probleme behebt das ModSecurity Sicherheitsupdate?

Das ModSecurity Project hat insgesamt acht Security Advisories veröffentlicht. Nicht alle Probleme betreffen exakt dieselben Versionen und Konfigurationen.

Für Administratoren gelten praktisch folgende Upstream-Versionen als relevant:

• libmodsecurity3 3.0.16 und älter – von mehreren Schwachstellen betroffen
• libmodsecurity3 3.0.17 – Sicherheitskorrekturen enthalten
• mod_security2 2.9.14 und älter – von sechs der acht Probleme betroffen
• mod_security2 2.9.15 – Sicherheitskorrekturen enthalten

CVE-2026-73857 hat einen engeren betroffenen Versionsbereich und betrifft speziell libmodsecurity3 3.0.15 und 3.0.16.

Acht Sicherheitsprobleme in ModSecurity

Die veröffentlichten Advisories betreffen unterschiedliche Bereiche der Request- und Response-Verarbeitung, Parser sowie Transformationen, die ModSecurity vor der eigentlichen Prüfung durch Sicherheitsregeln verwendet.

Zu den wichtigsten Problemen gehören:

• CVE-2026-73856 – CVSS 8.6 High: Umgehung der Response-Body-Inspektion durch nicht kanonische Groß- und Kleinschreibung des Content-Type-Headers;
• CVE-2026-73857 – CVSS 7.5 High: Memory-Safety-Problem im XML-Request-Body-Parser mit möglichen Auswirkungen von Denial of Service und Memory Disclosure bis zur Beeinflussung des Execution Flow;
• GHSA-5pww-8rfg-9crf – CVSS 8.6 High: Umgehung von Dateinamenkontrollen bei Multipart-Uploads über den RFC-2231-Parameter filename*;
• CVE-2026-61812 – CVSS 5.3: unvollständiges HTML-Entity-Decoding, wodurch WAF-Regeln umgangen werden können;
• CVE-2026-61813 – CVSS 3.7: unzureichende TLS-Hostname-Prüfung bei bestimmten HTTPS-Downloads;
• fehlerhafte Error-Behandlung beim Operator @rxGlobal;
• ein Bypass in der Transformation t:removeComments;
• fehlerhafte Verarbeitung von URL-safe Base64 durch t:base64DecodeExt.

CVE-2026-73856 umgeht die Response-Body-Inspektion

CVE-2026-73856 hat einen CVSS-Score von 8.6 und betrifft libmodsecurity3 bis einschließlich Version 3.0.16.

Das Problem befindet sich in der Entscheidung, ob ModSecurity den Inhalt einer HTTP-Response untersuchen muss.

ModSecurity verglich den Content-Type einer Response case-sensitive mit den MIME-Typen, die über SecResponseBodyMimeType konfiguriert waren.

HTTP-Medientypen sind jedoch nicht von Groß- und Kleinschreibung abhängig. Ein Backend konnte deshalb beispielsweise:

Text/Html

anstelle von:

text/html

zurückgeben.

In einer betroffenen Konfiguration konnte dies dazu führen, dass der Response Body nicht von ModSecurity untersucht wurde. Regeln, die auf RESPONSE_BODY angewiesen sind, wurden dann nicht ausgeführt.

Das ModSecurity Project nennt als mögliche Folgen unter anderem die Offenlegung vollständiger SQL-Fehlermeldungen, Stack Traces oder Debug-Informationen, die eine WAF-Regel eigentlich erkennen oder blockieren sollte.

CVE-2026-73857: Memory-Safety-Problem im XML-Parser

CVE-2026-73857 betrifft libmodsecurity3 3.0.15 und 3.0.16 und hat einen CVSS-Score von 7.5.

Ein nicht authentifizierter Angreifer kann mit einem speziell präparierten HTTP-Request einen nicht initialisierten Pointer im XML-Request-Body-Parser dereferenzieren lassen.

Das ModSecurity Project beschreibt mögliche Auswirkungen von:

• Denial of Service;
• Memory Disclosure;
• Speicherbeschädigung;
• Beeinflussung des Execution Flow.

Unter bestimmten Bedingungen könnte eine Beeinflussung des Ausführungsflusses möglicherweise weiter in Richtung Code Execution ausgebaut werden.

Vservs bezeichnet CVE-2026-73857 jedoch bewusst nicht als einfache oder garantierte unauthenticated Remote-Code-Execution-Schwachstelle. Das Upstream-Advisory bestätigt keine zuverlässig reproduzierbare direkte RCE für jede betroffene Konfiguration.

Bestimmte Konfiguration für CVE-2026-73857 erforderlich

Der verwundbare XML-Codepfad wird nur erreicht, wenn eine der folgenden Einstellungen aktiv ist:

SecParseXmlIntoArgs On

oder:

SecParseXmlIntoArgs OnlyArgs

Diese Funktion ist standardmäßig deaktiviert.

Server, auf denen SecParseXmlIntoArgs nicht aktiviert ist, sind deshalb nicht über diesen spezifischen XML-Parser-Angriffsweg verwundbar.

Sie können jedoch weiterhin von anderen Problemen betroffen sein, die mit demselben ModSecurity Sicherheitsupdate behoben wurden.

Datei-Upload-Regeln können über filename* umgangen werden

Ein weiteres High-Severity-Problem wird als GHSA-5pww-8rfg-9crf geführt und hat ebenfalls einen CVSS-Score von 8.6.

Die Schwachstelle betrifft Multipart-Datei-Uploads.

Ein HTTP-Multipart-Request kann einen Dateinamen über den klassischen Parameter filename angeben. RFC 2231 definiert zusätzlich den erweiterten Parameter filename*.

Verwundbare ModSecurity-Versionen verarbeiteten diesen erweiterten Parameter nicht korrekt, während verschiedene Backend-Frameworks ihn standardkonform interpretieren.

Ein Angreifer kann dadurch ModSecurity einen unauffälligen Dateinamen über filename präsentieren, während die dahinterliegende Anwendung einen anderen Wert aus filename* verarbeitet.

Regeln, die Upload-Dateinamen über Variablen wie MULTIPART_FILENAME oder FILES prüfen, können dadurch den falschen Wert untersuchen.

Bei Webanwendungen mit Datei-Uploads kann dies WAF-Regeln schwächen, die gefährliche Dateiendungen oder verdächtige Dateinamen blockieren sollen.

Transformationen können SQL-Injection-Regeln beeinflussen

Mehrere weitere Korrekturen betreffen Transformationen, die ModSecurity auf Eingaben anwendet, bevor diese gegen Sicherheitsregeln geprüft werden.

Ein Problem befindet sich beispielsweise in t:removeComments. Bestimmte Folgen direkt aufeinanderfolgender Kommentare wurden falsch normalisiert.

Dadurch konnte ModSecurity einen Payload anders interpretieren als die dahinterliegende Webanwendung.

Dies ist insbesondere für WAF-Regeln relevant, die verschleierte SQL-Injection-Payloads vor der eigentlichen Erkennung normalisieren.

Wenn Web Application Firewall und Anwendung dieselben Daten unterschiedlich interpretieren, kann ein Angreifer möglicherweise einen Payload konstruieren, der für die WAF unauffällig erscheint, von der Anwendung jedoch als gefährlicher Befehl verarbeitet wird.

URL-safe Base64 wird jetzt korrekt verarbeitet

Auch die Transformation t:base64DecodeExt enthielt einen Fehler.

Die URL-safe Base64-Zeichen - und _ wurden nicht korrekt dekodiert. Dadurch konnten Sicherheitsregeln, die den dekodierten Inhalt prüfen, einen anderen Wert sehen als die dahinterliegende Anwendung.

URL-safe Base64 wird unter anderem häufig in modernen APIs und JSON Web Tokens verwendet.

Ein Security-Rule-Set, das beispielsweise einen JWT-Bestandteil dekodiert, konnte dadurch bestimmte Payloads übersehen.

Die gepatchten Versionen korrigieren dieses Verhalten.

Werden die ModSecurity-Schwachstellen aktiv ausgenutzt?

Zum Zeitpunkt dieser Veröffentlichung hat Vservs keine zuverlässige Bestätigung aus primären Quellen gefunden, dass diese neu veröffentlichten ModSecurity-Schwachstellen derzeit in größerem Umfang aktiv in freier Wildbahn ausgenutzt werden.

Wir bezeichnen die Schwachstellen deshalb derzeit nicht als bestätigt aktiv ausgenutzt.

Mehrere Probleme ermöglichen jedoch ausdrücklich die Umgehung von Web-Application-Firewall-Kontrollen. Technische Details sind öffentlich verfügbar und korrigierte Upstream-Versionen wurden veröffentlicht.

Das ModSecurity Project empfiehlt für mehrere Advisories ausdrücklich ein sofortiges Upgrade.

Wichtig für Debian 12 und Debian 13

Administratoren, die ModSecurity über eine Linux-Distribution installieren, sollten nicht einfach die installierte Versionsnummer mit der Upstream-Version vergleichen.

Linux-Distributionen übernehmen Sicherheitskorrekturen häufig als Backports, ohne auf dieselbe Upstream-Versionsnummer zu wechseln.

Zum Zeitpunkt dieser Veröffentlichung führt der Debian Security Tracker die ModSecurity-Pakete für Debian 12 Bookworm und Debian 13 Trixie weiterhin als verwundbar für mehrere der neu veröffentlichten Probleme.

Für CVE-2026-73857 werden aktuell unter anderem folgende Pakete als verwundbar geführt:

• Debian 12 Bookworm: modsecurity 3.0.9-1+deb12u2
• Debian 13 Trixie: modsecurity 3.0.14-1+deb13u1

Auch die Debian-Pakete für das Multipart-filename*-Problem werden derzeit noch als verwundbar geführt.

Administratoren sollten deshalb den aktuellen Debian Security Tracker und die Paket-Repositories kontrollieren, bevor Änderungen vorgenommen werden.

Eine selbst kompilierte Upstream-Version über ein von Debian, einem Hosting-Control-Panel oder einem anderen Repository verwaltetes Paket zu installieren, ist nicht automatisch die richtige Lösung. Dadurch können Paketverwaltung, Webserver-Integration oder zukünftige Sicherheitsupdates beeinträchtigt werden.

Temporäre Mitigation für CVE-2026-73857

Ist libmodsecurity3 3.0.17 über den unterstützten Updatekanal noch nicht verfügbar und wird XML-to-ARGS nicht benötigt, kann SecParseXmlIntoArgs deaktiviert werden.

Dadurch wird der spezifische verwundbare Codepfad von CVE-2026-73857 nicht erreicht.

Diese Mitigation schützt jedoch nicht vor den anderen WAF-Bypässen, die mit derselben Security-Version behoben wurden.

Das Update auf ein gepatchtes ModSecurity-Paket bleibt deshalb die strukturelle Lösung.

Was sollten Serveradministratoren jetzt tun?

1. Prüfen, welche ModSecurity-Engine eingesetzt wird: libmodsecurity3 oder mod_security2.
2. Die installierte Paketversion kontrollieren.
3. Feststellen, ob ModSecurity vom Betriebssystem, Hosting-Control-Panel oder über eine eigene Installation verwaltet wird.
4. libmodsecurity3 3.0.17 beziehungsweise mod_security2 2.9.15 installieren, sobald eine korrigierte Version über den unterstützten Updatekanal verfügbar ist.
5. Prüfen, ob SecParseXmlIntoArgs aktiviert ist.
6. Nach dem Update den betreffenden Webserver beziehungsweise die WAF-Komponenten bei Bedarf reloaden oder neu starten.
7. Kontrollieren, ob ModSecurity und die verwendeten Rule Sets ohne Fehler geladen werden.
8. Wichtige Websites und Webanwendungen nach dem Update funktional testen.
9. Eigene ModSecurity-Regeln auf Kompatibilität mit dem korrigierten Parser- und Transformationsverhalten prüfen.

Logs auf mögliche WAF-Bypass-Versuche prüfen

Mehrere der Sicherheitsprobleme sind WAF-Bypässe. Eine erfolgreiche Umgehung kann deshalb gerade dazu führen, dass ein Angriff nicht als normaler ModSecurity-Block im Audit Log erscheint.

ModSecurity-Audit-Logs sollten deshalb zusammen mit Webserver- und Application-Logs ausgewertet werden.

Achten Sie insbesondere auf:

• Multipart-Datei-Uploads mit filename*;
• Requests mit ungewöhnlichen oder mehrfach aufeinanderfolgenden Inline-Kommentaren;
• kodierte Angriffspayloads;
• URL-safe Base64 in unerwarteten Request-Feldern;
• ungewöhnliche XML-Requests, wenn XML-to-ARGS aktiviert ist;
• unerwartete Worker-Abstürze oder Segmentation Faults;
• SQL-Injection-, XSS- oder File-Upload-Payloads, die von der Anwendung empfangen, aber nicht von ModSecurity blockiert wurden;
• unerwartete Upload-Dateien, die nach verdächtigen HTTP-Requests entstanden sind.

Das Auftreten eines solchen Musters beweist nicht automatisch eine erfolgreiche Ausnutzung. Auffälligkeiten sollten mit der betroffenen Anwendung, HTTP-Responsecodes, Quell-IP-Adressen und nachfolgenden Serveraktivitäten korreliert werden.

Eine Web Application Firewall ist eine zusätzliche Schutzschicht

Die Schwachstellen zeigen erneut, warum eine Web Application Firewall niemals die einzige Schutzmaßnahme einer Website oder eines Onlineshops sein sollte.

ModSecurity und Regelwerke wie das OWASP Core Rule Set bilden eine wichtige zusätzliche Sicherheitsschicht, ersetzen jedoch keine sichere und aktuelle Webanwendung.

WordPress Core, Plugins, Themes, Joomla-Erweiterungen, Magento- oder Adobe-Commerce-Komponenten und andere Webanwendungen müssen weiterhin mit ihren eigenen Sicherheitsupdates versorgt werden.

Server-Hardening, Least-Privilege-Berechtigungen, Monitoring und zuverlässige Backups bleiben ebenfalls notwendig.

Managed VPS bei Vservs

Eine sichere Hosting-Umgebung erfordert die kontinuierliche Pflege des Betriebssystems, Webservers, der Web Application Firewall und der gehosteten Anwendungen.

Die W3 Total Cache Sicherheitslücke CVE-2026-87920 ermöglicht es einem nicht angemeldeten Angreifer, schädlichen JavaScript-Code zu speichern, der anschließend in den Browsern von Website-Besuchern ausgeführt werden kann. Die Schwachstelle hat einen CVSS-Score von 7,2 und wird als High eingestuft. Betroffen sind W3 Total Cache-Versionen bis einschließlich 2.10.6. Die Sicherheitskorrektur ist in Version 2.10.7 enthalten.

W3 Total Cache ist auf mehr als 900.000 WordPress-Websites aktiv und gehört damit zu den am häufigsten eingesetzten Caching- und Performance-Plugins für WordPress.

Die Ausnutzbarkeit ist von der Konfiguration abhängig: Laut Wordfence muss die W3-Total-Cache-Option Remove query strings from static resources aktiviert sein.

Was ist die W3 Total Cache Sicherheitslücke CVE-2026-87920?

CVE-2026-87920 ist eine Stored-Cross-Site-Scripting-Schwachstelle in der Verarbeitung von HTML durch W3 Total Cache beim Entfernen von Querystrings aus statischen Ressourcen.

Das Plugin kann URLs im erzeugten HTML umschreiben, um Queryparameter von Ressourcen wie JavaScript- und CSS-Dateien zu entfernen.

In verwundbaren Versionen kann speziell präparierter HTML-Inhalt während dieses Vorgangs fehlerhaft verarbeitet werden. Dadurch kann ein vom Angreifer kontrollierter Wert seinen vorgesehenen HTML-Kontext verlassen.

Der eingeschleuste JavaScript-Code kann anschließend Bestandteil der erzeugten oder gecachten Seite werden und ausgeführt werden, wenn ein anderer Benutzer diese Seite besucht.

Welche W3 Total Cache-Versionen sind verwundbar?

• W3 Total Cache 2.10.6 und älter – verwundbar
• W3 Total Cache 2.10.7 oder neuer – gegen CVE-2026-87920 gepatcht

WordPress.org führt derzeit Version 2.10.7. Der Changelog enthält eine Sicherheitskorrektur für die Browser-Cache-Funktion, bei der das Umschreiben nicht in Anführungszeichen gesetzter URLs beim Entfernen von Querystrings eingeschränkt wurde.

Administratoren sollten auf Version 2.10.7 oder eine neuere verfügbare Version aktualisieren.

Kein WordPress-Login erforderlich

Laut Wordfence kann die dokumentierte Angriffskette ohne authentifiziertes WordPress-Konto erreicht werden.

Ein Angreifer kann schädliche Eingaben potenziell über die WordPress-Kommentarfunktion speichern, wenn Kommentare auf der betroffenen Website möglich sind.

Damit ist die Schwachstelle insbesondere für Websites relevant, die Kommentare oder andere öffentlich zugängliche benutzergenerierte Inhalte akzeptieren.

Bestimmte W3 Total Cache-Einstellung erforderlich

Die W3 Total Cache Sicherheitslücke ist über die dokumentierte Angriffskette nicht auf jeder Installation ausnutzbar.

Laut Wordfence muss folgende Option aktiviert sein:

Remove query strings from static resources

Diese Funktion schreibt URLs von Ressourcen in der HTML-Ausgabe um. Das verwundbare Verhalten tritt während dieses Umschreibprozesses auf.

Websites, auf denen die Option deaktiviert war, sind über diesen spezifischen Angriffsweg nicht verwundbar. Trotzdem sollten alle Installationen mit W3 Total Cache 2.10.6 oder älter aktualisiert werden.

Was bedeutet Stored Cross-Site Scripting?

Stored Cross-Site Scripting bedeutet, dass vom Angreifer kontrollierter JavaScript-Code von der Website gespeichert und später an andere Benutzer ausgeliefert wird.

Dies unterscheidet sich von Reflected XSS, bei dem der schädliche Payload normalerweise in jedem einzelnen Request enthalten sein muss. Ein gespeicherter Payload kann dagegen vorhanden bleiben, bis der betreffende Inhalt entfernt oder bereinigt wird.

Die WPMobile.App Sicherheitslücke CVE-2026-94541 kann es einem nicht authentifizierten Angreifer unter bestimmten Voraussetzungen ermöglichen, WordPress-Passwort-Reset-Links abzugreifen und Benutzerkonten zu übernehmen. Die Schwachstelle hat einen CVSS-Score von 9,8 und wird als Critical eingestuft. Auch Administratorkonten können betroffen sein, wodurch eine vollständige Übernahme der WordPress-Website möglich werden kann.

Wordfence hat außerdem gemeldet, innerhalb eines Zeitraums von 24 Stunden 79 Angriffsversuche gegen CVE-2026-94541 blockiert zu haben. Damit gibt es konkrete Hinweise darauf, dass Angreifer versuchen, die Schwachstelle auszunutzen.

Diese Zahl bedeutet ausdrücklich nicht, dass 79 WordPress-Websites erfolgreich kompromittiert wurden. Es handelt sich um von Wordfence erkannte und blockierte Exploit-Versuche.

Was ist die WPMobile.App Sicherheitslücke CVE-2026-94541?

WPMobile.App ist ein WordPress-Plugin, mit dem WordPress-Websites in Android- und iOS-Anwendungen umgewandelt werden können.

Die Schwachstelle betrifft eine Funktion, mit der ausgehende WordPress-E-Mails in Push-Benachrichtigungen für die zugehörige mobile Anwendung umgewandelt werden können.

Ist die sogenannte mail-to-push-Funktion aktiviert, können Informationen aus ausgehenden WordPress-E-Mails verarbeitet und in der Push-Queue des Plugins gespeichert werden.

Das Sicherheitsproblem entsteht, weil verwundbare Versionen nicht ausreichend überprüfen, ob ein Besucher berechtigt ist, bestimmte Informationen aus dieser Queue abzurufen.

Welche WPMobile.App-Versionen sind verwundbar?

• WPMobile.App 11.82 und älter – verwundbar
• WPMobile.App 11.85 oder neuer – gegen CVE-2026-94541 gepatcht

Version 11.83 deaktivierte die betroffene Mail-to-Push-Funktion vorübergehend. Version 11.84 enthielt zusätzliche Hardening-Maßnahmen. Wordfence empfiehlt für die vollständige Behebung von CVE-2026-94541 ein Update auf WPMobile.App 11.85 oder neuer.

Wie können Passwort-Reset-Links offengelegt werden?

Besonders kritisch wird die Schwachstelle, wenn WordPress eine Anfrage zum Zurücksetzen eines Passworts verarbeitet.

Eine normale WordPress-E-Mail zum Zurücksetzen des Passworts enthält eine eindeutige URL und einen Reset-Key. Wer Zugriff auf diese Informationen erhält, kann unter Umständen ein neues Passwort für das betreffende Konto setzen.

Ist Mail-to-Push aktiviert, können Informationen aus dieser Passwort-Reset-E-Mail ebenfalls in die Push-Queue von WPMobile.App gelangen.

Unter den verwundbaren Bedingungen kann ein nicht angemeldeter Angreifer Informationen aus dieser Queue abrufen und dadurch möglicherweise den Passwort-Reset-Link erhalten.

Anschließend kann der Angreifer den legitimen WordPress-Prozess zum Zurücksetzen des Passworts verwenden, um ein neues Passwort für das Zielkonto festzulegen.

Auch WordPress-Administratorkonten können übernommen werden

Die WPMobile.App Sicherheitslücke ist nicht auf WordPress-Konten mit niedrigen Berechtigungen beschränkt. Auch Passwort-Reset-Informationen von Administratoren können betroffen sein.

Gelingt einem Angreifer die Übernahme eines WordPress-Administratorkontos, können die Auswirkungen erheblich sein.

Ein Administrator kann normalerweise unter anderem:

• weitere Administratorkonten erstellen;
• Plugins und Themes installieren oder verändern;
• über verfügbare WordPress-Funktionen PHP-Code einbringen;
• Website-Inhalte ändern oder löschen;
• WordPress-Sicherheitseinstellungen verändern;
• schädliche Redirects oder Backdoors installieren;
• auf Informationen zugreifen, die über den WordPress-Administrationsbereich verfügbar sind.

Eine erfolgreiche Übernahme eines Administratorkontos sollte deshalb als potenzielle Kompromittierung der vollständigen WordPress-Installation behandelt werden.

Wann ist eine WordPress-Website gefährdet?

Die von Wordfence beschriebene Angriffskette zum Abgreifen von Passwort-Reset-Informationen setzt voraus, dass die Mail-to-Push-Funktion von WPMobile.App aktiviert ist.

Wordfence nennt hierfür die Einstellung:

wpmobile_auto_mail=1

War diese Funktion nicht aktiviert, ist die beschriebene Methode zum Abgreifen von Passwort-Reset-Informationen nicht direkt anwendbar.

Diese Voraussetzung ist jedoch kein Grund, eine veraltete Plugin-Version installiert zu lassen. Websites mit WPMobile.App 11.82 oder älter sollten trotzdem aktualisiert werden.

Angriffsversuche gegen CVE-2026-94541 wurden beobachtet

Wordfence meldet 79 blockierte Angriffe gegen CVE-2026-94541 innerhalb eines Zeitraums von 24 Stunden.

Damit handelt es sich nicht mehr ausschließlich um eine theoretisch interessante Schwachstelle. Angreifer senden bereits Requests, die auf die verwundbare Funktion abzielen.

Aus den verfügbaren Daten lässt sich jedoch nicht ableiten, wie viele Websites tatsächlich erfolgreich kompromittiert wurden.

Vservs beschreibt CVE-2026-94541 deshalb als Schwachstelle, bei der aktive Exploit-Versuche beobachtet wurden, ohne daraus eine bestimmte Zahl erfolgreicher Kompromittierungen abzuleiten.

Was sollten WordPress-Administratoren jetzt tun?

1. Kontrollieren, ob WPMobile.App installiert ist.
2. Die aktuell installierte Plugin-Version überprüfen.
3. Sofort auf WPMobile.App 11.85 oder neuer aktualisieren.
4. Kann nicht sofort aktualisiert werden, das Plugin vorübergehend deaktivieren.
5. Prüfen, ob Mail-to-Push aktiviert war.
6. Administratorkonten auf unerwartete Änderungen kontrollieren.
7. Aktuelle Passwort-Resets und Sicherheitsmeldungen überprüfen.
8. WordPress- und Webserver-Logs auf verdächtige Aktivitäten kontrollieren.

Auf mögliche Exploit-Versuche prüfen

Administratoren von Websites, auf denen eine verwundbare Version installiert war, sollten Webserver-Logs auf ungewöhnliche Requests an WPMobile.App-Funktionen überprüfen.

Nach den veröffentlichten technischen Informationen verdient unter anderem folgender Parameter besondere Aufmerksamkeit:

wpapp_category[]

Das Auftreten dieses Parameters beweist für sich allein keine erfolgreiche Ausnutzung. Requests sollten mit Quell-IP-Adressen, Zeitstempeln, HTTP-Responses und anschließenden WordPress-Aktivitäten abgeglichen werden.

Kontrollieren Sie außerdem:

• unbekannte oder kürzlich erstellte Administratorkonten;
• unerwartete Änderungen an Administrator-E-Mail-Adressen;
• Passwort-Resets, die nicht von legitimen Benutzern angefordert wurden;
• unbekannte Plugins oder Themes;
• kürzlich geänderte PHP-Dateien;
• unerwartete Änderungen an wp-config.php;
• verdächtige neue Dateien unter wp-content;
• ungewöhnliche WordPress-Loginaktivitäten.

Was tun bei Verdacht auf eine Kontoübernahme?

Gibt es Hinweise darauf, dass ein Administratorkonto erfolgreich übernommen wurde, reicht das Installieren des Plugin-Updates nicht mehr aus.

Die WordPress-Installation sollte dann als potenziell kompromittiert behandelt werden. WordPress Core, Plugins, Themes, Must-Use-Plugins, Benutzerkonten, geplante Aufgaben, Dateisystemänderungen und relevante Server-Logs sollten überprüft werden.

Ein Angreifer mit Administratorrechten kann bereits zusätzliche Persistence eingerichtet haben, beispielsweise über ein schädliches Plugin, ein verändertes Theme, eine Webshell oder ein weiteres Administratorkonto.

Administratorpasswörter und andere relevante Zugangsdaten sollten nach Wiederherstellung und Überprüfung der Integrität geändert werden. Bei bestätigter Kompromittierung sollten außerdem bestehende WordPress-Sitzungen ungültig gemacht werden.

Managed WordPress und Managed VPS bei Vservs

WordPress-Schwachstellen werden zunehmend kurz nach Veröffentlichung technischer Details angegriffen. Schnelle Sicherheitsupdates, Monitoring und die Untersuchung ungewöhnlicher Aktivitäten sind deshalb besonders wichtig.

Mit Vservs Managed WordPress übernehmen wir unter anderem technische WordPress-Verwaltung, Sicherheitsupdates, Hardening, Malware-Kontrollen, Backups und Monitoring.

Für Websites, die eine eigene isolierte Serverumgebung benötigen, bietet Vservs außerdem Managed VPS mit technischem Servermanagement, relevanten Betriebssystem- und Sicherheitsupdates, Monitoring und Server-Hardening.

Zusammenfassung

• Plugin: WPMobile.App – Android and iOS App Builder
• CVE: CVE-2026-94541
• Severity: Critical
• CVSS: 9,8
• Betroffene Versionen: 11.82 und älter
• Abgesicherte Version: 11.85 oder neuer
• Mögliche Auswirkungen: nicht authentifizierte Übernahme von WordPress-Konten einschließlich Administratorkonten
• Voraussetzung: Mail-to-Push-Funktion für die beschriebene Angriffskette aktiviert
• Exploit-Status: Wordfence hat Angriffsversuche gegen CVE-2026-94541 beobachtet und blockiert
• Empfehlung: sofort aktualisieren und Benutzerkonten sowie Logs kontrollieren

Quellen

• Wordfence Intelligence – CVE-2026-94541
• WordPress.org – WPMobile.App

Die AcyMailing Sicherheitslücke CVE-2026-94132 kann unter bestimmten Voraussetzungen dazu führen, dass ein Angreifer eine ausführbare PHP-Datei auf einem Joomla-Server speichert und anschließend ausführt. Die kritische Schwachstelle befindet sich in der Mailbox-Actions-Funktion von AcyMailing Enterprise und wird mit einem CVSS-4.0-Score von 9,5 Critical bewertet. AcyMailing-Versionen bis einschließlich 11.0.5 sind betroffen. Die Sicherheitskorrektur ist in AcyMailing 11.1.0 enthalten.

Für CVE-2026-94132 wurde inzwischen öffentliche Proof-of-Concept-Code veröffentlicht. Zusätzlich gibt es ein praktisches Problem für Joomla-Administratoren: Auf bestimmten Installationen kann die AcyMailing Update Site aus Joomla verschwunden sein. Eine verwundbare Installation kann dadurch fälschlicherweise melden, dass keine Aktualisierung verfügbar ist.

Vservs empfiehlt deshalb, die tatsächlich installierte AcyMailing-Version direkt zu kontrollieren und sich bei dieser Schwachstelle nicht ausschließlich auf die Joomla-Updateanzeige zu verlassen.

Was ist die AcyMailing Sicherheitslücke CVE-2026-94132?

CVE-2026-94132 ist eine Unrestricted-File-Upload-Schwachstelle in der Mailbox-Actions-Funktion von AcyMailing Enterprise für Joomla.

Mit Mailbox Actions kann AcyMailing eingehende E-Mails aus einer konfigurierten Mailbox verarbeiten und anhand dieser Nachrichten bestimmte Aktionen ausführen.

Nach den veröffentlichten Informationen wurden MIME-Bestandteile eingehender E-Mails in verwundbaren Versionen unter einem Pfad innerhalb von media/com_acym/upload/ gespeichert, ohne die Dateiendung ausreichend zu kontrollieren.

Dadurch kann jemand, der eine E-Mail an die überwachte Mailbox senden kann, unter den für die Schwachstelle erforderlichen Bedingungen eine Datei mit einer ausführbaren PHP-Endung in einen über das Web erreichbaren Bereich schreiben.

Kann diese Datei anschließend über HTTP aufgerufen und vom Webserver als PHP ausgeführt werden, entsteht Remote Code Execution.

Welche AcyMailing-Versionen sind verwundbar?

Die Joomla CNA nennt folgenden Versionsbereich für CVE-2026-94132:

• AcyMailing 1.0.0 bis einschließlich 11.0.5 – verwundbar
• AcyMailing 11.1.0 oder neuer – Sicherheitskorrektur vorhanden

AcyMailing veröffentlichte Version 11.1.0 am 24. September 2026. Im offiziellen Changelog wird die Behebung eines Sicherheitsproblems in einer bestimmten Mailbox-Actions-Situation bestätigt.

Administratoren sollten deshalb mindestens AcyMailing 11.1.0 einsetzen.

Wie kritisch ist CVE-2026-94132?

Die AcyMailing Sicherheitslücke wird mit einem CVSS-4.0-Score von 9,5 Critical bewertet.

Der veröffentlichte CVSS-Vektor vermeldet unter anderem:

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

Der CVSS-4.0-Vektor bevat daarnaast AT:P: Attack Requirements Present. Dit is belangrijk, omdat niet iedere AcyMailing-installatie automatisch via internet kan worden overgenomen.

Welche Voraussetzungen müssen für einen Angriff erfüllt sein?

Die Schwachstelle befindet sich in einer spezifischen AcyMailing-Funktion. Für den bekannten Angriffsweg muss die betreffende Mailbox-Actions-Funktion verwendet werden.

Ein Angreifer muss außerdem eine Nachricht an die von AcyMailing überwachte Mailbox senden können.

Die Schwachstelle erfordert dagegen kein Joomla-Benutzerkonto und keine Interaktion eines Joomla-Administrators.

Wenn die verwundbare Mailbox-Konfiguration aktiv ist und hochgeladene PHP-Dateien in dem betreffenden Webverzeichnis ausgeführt werden können, kann die Sicherheitslücke zur Ausführung von Code unter den Rechten des PHP- beziehungsweise Webserverprozesses führen.

Was kann ein Angreifer nach erfolgreicher Ausnutzung erreichen?

Remote Code Execution innerhalb einer Joomla-Website kann schwerwiegende Folgen haben.

Abhängig von der Serverkonfiguration und den Dateisystemrechten kann ein Angreifer beispielsweise:

• eine Webshell oder andere Backdoor installieren;
• Joomla-Dateien verändern;
• configuration.php und darin enthaltene Zugangsdaten auslesen;
• auf die Joomla-Datenbank zugreifen;
• Joomla-Benutzer und Super-User-Konten manipulieren;
• SMTP-, API- und andere Application Credentials auslesen;
• Malware oder schädlichen JavaScript-Code in die Website einfügen;
• weitere Persistenzmechanismen auf der Website einrichten.

Die tatsächlichen Möglichkeiten hängen von der Isolation des Hostingaccounts und den Berechtigungen des PHP-Prozesses ab.

Öffentliche Proof-of-Concept für CVE-2026-94132 verfügbar

Für CVE-2026-94132 ist inzwischen öffentliche Proof-of-Concept-Code verfügbar.

Damit sind technische Informationen zur Reproduktion des Angriffs öffentlich zugänglich. Dies senkt die Hürde für weitere Sicherheitsforscher, Scanner und potenzielle Angreifer, die Schwachstelle zu analysieren.

Eine öffentliche PoC ist jedoch nicht dasselbe wie bestätigte aktive Ausnutzung in freier Wildbahn.

Zum Zeitpunkt dieser Veröffentlichung hat Vservs keine zuverlässige Bestätigung dafür gefunden, dass CVE-2026-94132 bereits aktiv gegen Joomla-Websites ausgenutzt wird.

Die aktuellen CISA-Vulnrichment-Daten zum CVE führen den Exploitation-Status ebenfalls als none.

Joomla kann das AcyMailing-Update möglicherweise nicht anzeigen

Zusätzlich zur eigentlichen AcyMailing Sicherheitslücke gibt es ein wichtiges Problem mit der Update-Erkennung innerhalb von Joomla.

Eine technische Untersuchung von mySites.guru zeigt, dass AcyMailing seine Update Site nicht über ein <updateservers>-Element im Joomla-Erweiterungsmanifest definiert. Stattdessen wird der Eintrag während Installation beziehungsweise Aktualisierung über PHP direkt in der Joomla-Datenbank angelegt.

Dies wird problematisch, wenn ein Administrator unter System → Update Sites die Joomla-Funktion Rebuild verwendet.

Joomla entfernt dabei nicht zum Core gehörende Update-Site-Einträge und rekonstruiert sie anschließend anhand der Erweiterungsmanifeste. Da das AcyMailing-Manifest den Update-Server nicht enthält, kann Joomla den entfernten Eintrag nicht wiederherstellen.

Eine ältere AcyMailing-Installation kann anschließend fälschlicherweise den Eindruck erwecken, vollständig aktuell zu sein.

Kontrollieren Sie deshalb die tatsächlich installierte Version

Administratoren sollten bei CVE-2026-94132 nicht ausschließlich darauf vertrauen, dass Joomla eine verfügbare AcyMailing-Aktualisierung meldet.

Kontrollieren Sie ausdrücklich die tatsächlich installierte AcyMailing-Version.

Wird eine Version bis einschließlich 11.0.5 verwendet und bietet Joomla kein Update an, sollte das aktuelle AcyMailing-Paket direkt über AcyMailing bezogen und über die bestehende Installation installiert werden.

AcyMailing sollte dabei nicht zuerst deinstalliert werden. Eine Installation des aktuellen Pakets über die bestehende Installation stellt laut der technischen Analyse auch den fehlenden Update-Site-Eintrag wieder her.

AcyMailing 11.1.0 behebt noch eine zweite Sicherheitslücke

Neben CVE-2026-94132 behebt AcyMailing 11.1.0 außerdem CVE-2026-94131.

Diese zweite Schwachstelle betrifft File-Type Custom Fields und kann unter bestimmten Bedingungen dazu führen, dass ein Benutzer Dateien außerhalb des vorgesehenen Upload-Verzeichnisses löscht.

CVE-2026-94131 wird mit CVSS 8,3 High bewertet.

Ein Update auf AcyMailing 11.1.0 behebt somit zwei relevante Sicherheitsprobleme.

Was sollten Joomla-Administratoren jetzt tun?

1. Die tatsächlich installierte AcyMailing-Version kontrollieren.
2. AcyMailing bis einschließlich 11.0.5 auf Version 11.1.0 oder neuer aktualisieren.
3. Nicht ausschließlich auf die Joomla-Anzeige „Keine Updates verfügbar“ vertrauen.
4. Falls Joomla 11.1.0 nicht anbietet, das aktuelle AcyMailing-Paket direkt beziehen und über die bestehende Installation installieren.
5. AcyMailing nicht zuerst deinstallieren.
6. Prüfen, ob Mailbox Actions beziehungsweise Bounce Handling verwendet werden.
7. Kontrollieren, welche Mailboxen von AcyMailing überwacht werden.
8. Nach dem Update prüfen, ob verwendete AcyMailing-Add-ons weiterhin korrekt funktionieren.

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

Kann AcyMailing nicht unmittelbar aktualisiert werden, sollte die betroffene Mailbox-Actions-Funktion deaktiviert oder so konfiguriert werden, dass der verwundbare Angriffsweg nicht mehr erreichbar ist.

Zusätzlich kann serverseitig verhindert werden, dass PHP-Dateien innerhalb des AcyMailing-Upload-Verzeichnisses ausgeführt werden.

Diese Maßnahmen können die Angriffsfläche reduzieren, sind aber kein dauerhafter Ersatz für die Installation der Sicherheitsversion 11.1.0 oder neuer.

Website auf mögliche Kompromittierung prüfen

Joomla-Websites, die eine verwundbare AcyMailing-Version mit aktiven Mailbox Actions betrieben haben, sollten zusätzlich kontrolliert werden.

Besonders relevant sind:

• unbekannte PHP-Dateien unter media/com_acym/;
• PHP-, PHTML- oder andere ausführbare Dateien in AcyMailing-Uploadverzeichnissen;
• kürzlich erstellte oder unerwartet veränderte PHP-Dateien;
• Webserver-Requests auf unbekannte Dateien unter AcyMailing-Pfaden;
• ungewöhnliche E-Mails oder Anhänge in der überwachten Mailbox;
• unbekannte Joomla-Super-User-Konten;
• unerwartete Änderungen an Joomla-Erweiterungen oder Templates;
• unbekannte geplante Aufgaben oder andere Persistenzmechanismen.

Serveradministratoren können beispielsweise gezielt nach PHP-Dateien unter dem AcyMailing-Medienverzeichnis suchen:

find media/com_acym -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \) -ls

Das Vorhandensein einer PHP-Datei allein beweist noch nicht automatisch einen Angriff, da legitime Dateien abhängig von der Installation vorhanden sein können. Unbekannte oder kürzlich hinzugefügte ausführbare Dateien sollten jedoch untersucht werden.

Was tun, wenn eine unbekannte PHP-Datei gefunden wird?

Wird eine unbekannte Webshell, Backdoor oder andere nicht autorisierte PHP-Datei gefunden, reicht ein einfaches Update von AcyMailing nicht mehr aus.

Die Joomla-Installation sollte dann als potenziell kompromittiert behandelt werden.

Kontrollieren Sie Joomla Core, Erweiterungen, Templates, Benutzerkonten, Datenbank, geplante Aufgaben und relevante Serverlogs. Dateien sollten nach Möglichkeit mit vertrauenswürdigen Originalversionen verglichen werden.

Zugangsdaten, die aus der kompromittierten Joomla-Umgebung erreichbar waren, sollten nach Wiederherstellung der Integrität ebenfalls geändert werden. Dazu können Datenbank-, SMTP-, API- und Administratorzugangsdaten gehören.

Managed VPS bei Vservs

Der Fall CVE-2026-94132 zeigt, dass die Anzeige eines CMS, alle Erweiterungen seien aktuell, nicht in jeder Situation garantiert, dass tatsächlich jede verfügbare Sicherheitsversion installiert ist.

Mit einem Managed VPS von Vservs übernehmen wir unter anderem technische Serververwaltung, relevante Betriebssystem- und Sicherheitsupdates, Monitoring und Server-Hardening.

Bei Unmanaged Hosting und Unmanaged VPS-Servern bleibt die Kontrolle und Installation von CMS-, Erweiterungs- und Server-Sicherheitsupdates in der Verantwortung des Administrators.

Zusammenfassung

• Schwachstelle: CVE-2026-94132
• Software: AcyMailing Enterprise für Joomla
• Typ: Unrestricted Upload of File with Dangerous Type / Remote Code Execution
• CVSS: 9,5 Critical
• Betroffene Versionen: 1.0.0 bis einschließlich 11.0.5
• Abgesicherte Version: 11.1.0 oder neuer
• Authentifizierung erforderlich: kein Joomla-Konto erforderlich
• Angriffsvoraussetzung: verwundbare Mailbox-Actions-Konfiguration und Möglichkeit, die überwachte Mailbox per E-Mail zu erreichen
• Öffentliche PoC: ja
• Aktive Ausnutzung: derzeit nicht bestätigt
• Zusätzlich behoben: CVE-2026-94131, File Deletion, CVSS 8,3 High
• Besonderes Risiko: Joomla kann das verfügbare AcyMailing-Update möglicherweise nicht anzeigen

Quellen

• AcyMailing – offizieller Changelog für Version 11.1.0
• CVE-2026-94132 – Joomla CNA / CVE-Daten
• mySites.guru – technische Analyse der Sicherheitskorrekturen in AcyMailing 11.1.0
• mySites.guru – AcyMailing Update Site kann aus Joomla verschwinden

Das Joomla Sicherheitsupdate 5.4.9 und 6.1.4 behebt insgesamt 16 Sicherheitslücken in Joomla Core. Die Aktualisierung schließt zwei Schwachstellen mit High Severity, mehrere Probleme bei der Zugriffskontrolle, verschiedene Cross-Site-Scripting-Schwachstellen, eine Möglichkeit zur nicht autorisierten Kontoerstellung sowie einen neuen Weg zur Umgehung der Multi-Faktor-Authentifizierung.

Die Sicherheitsversionen wurden am 29. September 2026 veröffentlicht. Websites mit Joomla 5 bis einschließlich 5.4.8 beziehungsweise Joomla 6 bis einschließlich 6.1.3 sollten auf Joomla 5.4.9 beziehungsweise Joomla 6.1.4 aktualisiert werden.

Nicht alle 16 Schwachstellen haben die gleiche technische Auswirkung. Die Kombination aus SSRF, möglicher Directory Deletion, Authentifizierungsproblemen und fehlerhaften Zugriffskontrollen macht dieses Joomla Sicherheitsupdate jedoch für Administratoren besonders relevant.

Welche Joomla-Versionen sollten installiert werden?

Das Joomla Sicherheitsupdate steht in folgenden Versionen zur Verfügung:

• Joomla 5.4.9 oder neuer – Sicherheitskorrekturen enthalten
• Joomla 6.1.4 oder neuer – Sicherheitskorrekturen enthalten

Die einzelnen Sicherheitslücken haben nicht alle exakt denselben betroffenen Versionsbereich. Mehrere Probleme betreffen Joomla 4.0.0 bis einschließlich 5.4.8 sowie Joomla 6.0.0 bis einschließlich 6.1.3. Einige Schwachstellen reichen jedoch bis in ältere Joomla-Versionen zurück.

Websites, die noch Joomla 3 oder nicht mehr unterstützte Joomla-4-Versionen verwenden, sollten das Fehlen eines neuen Updates für ihren Versionszweig nicht als Hinweis darauf betrachten, dass die Installation sicher ist. Für solche Installationen sollte eine Migration auf eine aktuell unterstützte Joomla-Version geplant werden.

Zwei High-Severity-Schwachstellen in Joomla Core

Zwei der insgesamt 16 Sicherheitsprobleme werden vom Joomla Project mit High Severity und High Impact eingestuft.

CVE-2026-90915 – beliebige Verzeichnisse durch Path Traversal löschen

CVE-2026-90915 betrifft die Cache-Purge-Funktion von Joomla. Der Name einer Cache-Gruppe wurde nicht ausreichend validiert, bevor dieser für Dateisystemoperationen verwendet wurde.

Unter den verwundbaren Bedingungen kann ein Angreifer mittels Path Traversal beeinflussen, welches Verzeichnis Joomla zu löschen versucht.

Eine erfolgreiche Ausnutzung kann deshalb dazu führen, dass Verzeichnisse außerhalb des vorgesehenen Joomla-Cache-Verzeichnisses gelöscht werden.

Das Joomla Project nennt Joomla 4.0.0 bis einschließlich 5.4.8 und Joomla 6.0.0 bis einschließlich 6.1.3 als betroffen.

CVE-2026-92222 – Server-Side Request Forgery

CVE-2026-92222 ist eine Server-Side-Request-Forgery-Schwachstelle in der URL-Validierung verschiedener Joomla-Core-Erweiterungen.

Bei Server-Side Request Forgery, kurz SSRF, kann ein Angreifer Netzwerkrequests beeinflussen, die vom Server selbst ausgeführt werden.

Dies kann sicherheitsrelevant sein, weil ein Joomla-Server unter Umständen Systeme, Dienste oder Netzwerkbereiche erreichen kann, die nicht direkt aus dem öffentlichen Internet erreichbar sind.

Die tatsächlichen Auswirkungen hängen von der Netzwerkumgebung, der Serverkonfiguration und den vom Joomla-Server erreichbaren Diensten ab.

Joomla Sicherheitsupdate behebt MFA-Bypass

CVE-2026-92227 betrifft die Remember-Me-Funktion von Joomla und die Multi-Faktor-Authentifizierung.

Laut Joomla konnte ein Remember-Me-Cookie zu früh innerhalb des Authentifizierungsprozesses ausgegeben werden. Unter den betroffenen Bedingungen konnte dadurch bei einer späteren Frontend-Anmeldung die Multi-Faktor-Authentifizierung umgangen werden.

Dies bedeutet nicht, dass ein Angreifer automatisch ohne gültigen Benutzernamen und Passwort auf ein Joomla-Konto zugreifen kann. Die primäre Authentifizierung bleibt relevant.

Die MFA soll jedoch gerade eine zusätzliche Schutzschicht bieten, wenn ein Passwort kompromittiert wurde. Eine Möglichkeit, diesen zweiten Faktor zu umgehen, reduziert deshalb eine wichtige Sicherheitsbarriere.

Kontoerstellung trotz deaktivierter Benutzerregistrierung

CVE-2026-90907 betrifft den profile.save-Controller.

Laut Joomla wurde der Loginstatus nicht ausreichend geprüft. Dadurch konnte ein Besucher unter den verwundbaren Bedingungen ein Benutzerkonto auf Guest-Level erstellen, obwohl die öffentliche Benutzerregistrierung durch den Administrator deaktiviert war.

Ein Guest-Konto ist nicht mit einem Joomla-Super-User-Konto gleichzusetzen und die Schwachstelle sollte deshalb nicht als unmittelbare Administratorübernahme beschrieben werden.

Die nicht autorisierte Kontoerstellung umgeht jedoch ausdrücklich eine Sicherheits- und Konfigurationsentscheidung des Website-Administrators.

Weitere Sicherheitslücken in Joomla 5.4.9 und 6.1.4

Das Joomla Sicherheitsupdate behebt zusätzlich mehrere weitere Probleme in Joomla Core.

Dazu gehören Schwachstellen im Zusammenhang mit:

• Cross-Site Scripting in verschiedenen Joomla-Core-Layouts;
• unzureichenden ACL-Prüfungen in Webservice-Endpunkten;
• nicht autorisierten Editieraktionen über Webservices;
• Zugriff auf Inhalte, die durch Joomla-ACL-Regeln eingeschränkt sein sollten;
• unzureichendem Escaping in HTML-E-Mail-Templates und anderer Ausgabe;
• weiteren Authentifizierungs- und Autorisierungsprüfungen innerhalb von Joomla Core.

Nicht jede Joomla-Website stellt alle betroffenen Funktionen in gleicher Weise zur Verfügung. Das praktische Risiko hängt deshalb unter anderem von der Website-Konfiguration, den verwendeten Funktionen und dem Einsatz der Joomla Web Services API ab.

Werden die neuen Joomla-Sicherheitslücken aktiv ausgenutzt?

Zum Zeitpunkt dieser Veröffentlichung hat Vservs keine zuverlässige Bestätigung dafür gefunden, dass die mit Joomla 5.4.9 und 6.1.4 behobenen neuen Core-Schwachstellen aktiv in freier Wildbahn ausgenutzt werden.

Das Joomla Project meldet in den zu dieser Veröffentlichung geprüften Security Advisories ebenfalls keine bestätigte aktive Ausnutzung.

Auch für die beiden High-Severity-Schwachstellen gibt es derzeit keine zuverlässigen öffentlichen Hinweise auf eine breit angelegte Angriffskampagne.

Dies ist jedoch kein Grund, das Update aufzuschieben. Die Sicherheitskorrekturen sind verfügbar und technische Informationen zu den Schwachstellen sind inzwischen öffentlich dokumentiert.

Wichtig: bekanntes Problem mit Joomla 5.4.9 und der Web Services API

Administratoren von Joomla 5 sollten zusätzlich eine separate, nicht sicherheitsrelevante Regression in Joomla 5.4.9 beachten.

Das Joomla Project hat gemeldet, dass PATCH-Requests über die Web Services API unter Joomla 5.4.9 einen Fatal Error verursachen können.

Joomla 6.1.4 ist von diesem speziellen Problem nicht betroffen.

Joomla-5-Websites, die intensiv PATCH-Requests über die Web Services API verwenden, sollten deshalb die offiziellen Joomla-Informationen und den verfügbaren Workaround in die Updateplanung einbeziehen.

Dieses bekannte Problem sollte nicht als Grund betrachtet werden, eine verwundbare Joomla-Installation dauerhaft ungepatcht zu lassen. Stattdessen sollten API-Tests und der dokumentierte Workaround Bestandteil des Updateprozesses sein.

Was sollten Joomla-Administratoren jetzt tun?

1. Vor dem Update eine vollständige Sicherung der Joomla-Dateien und Datenbank erstellen.
2. Joomla-5-Installationen auf Joomla 5.4.9 oder neuer aktualisieren.
3. Joomla-6-Installationen auf Joomla 6.1.4 oder neuer aktualisieren.
4. Kontrollieren, ob das Update erfolgreich abgeschlossen wurde.
5. Frontend und Joomla Administrator nach dem Update testen.
6. Web-Services-API-Integrationen überprüfen, sofern diese verwendet werden.
7. Joomla-Benutzerkonten und Benutzergruppen auf unerwartete Änderungen kontrollieren.
8. Server- und Joomla-Logs auf ungewöhnliche Zugriffe oder Fehler prüfen.
9. Für Websites mit nicht mehr unterstützten Joomla-Versionen eine Migration planen.

Website auf eine mögliche Kompromittierung prüfen

Da dieses Joomla Sicherheitsupdate 16 unterschiedliche Schwachstellen behebt, gibt es keinen einzelnen universellen Indicator of Compromise, mit dem sich die Ausnutzung aller Probleme zuverlässig nachweisen lässt.

Abhängig von den auf der Website verwendeten Funktionen sollten Administratoren insbesondere folgende Punkte überprüfen:

• unbekannte Joomla-Benutzerkonten;
• unerwartete Guest-, Administrator- oder Super-User-Konten;
• unerwartete Änderungen an Joomla-Benutzergruppen und ACL-Konfigurationen;
• unerklärlich fehlende Verzeichnisse oder Dateien;
• ungewöhnliche Requests an Joomla-Web-Services-API-Endpunkte;
• unerwartete ausgehende Netzwerkrequests von PHP oder Joomla;
• auffällige Remember-Me-Authentifizierungsaktivitäten;
• unerwartete Änderungen an Joomla-Core-Dateien;
• neue oder geänderte Erweiterungen, die keinem Administrator zugeordnet werden können;
• ungewöhnliche administrative Aktivitäten aus dem Zeitraum vor dem Update.

Ein ungewöhnlicher Request, ein unbekanntes Konto oder eine Dateisystemänderung beweist für sich allein noch keine erfolgreiche Ausnutzung einer dieser Schwachstellen. Auffälligkeiten sollten mit Access-Logs, Joomla-Aktivitäten, Datenbankänderungen und Dateisystem-Zeitstempeln abgeglichen werden.

Was tun, wenn verdächtige Aktivitäten gefunden werden?

Wird ein unbekanntes privilegiertes Konto, eine nicht erklärte Dateisystemänderung oder ein anderer deutlicher Hinweis auf nicht autorisierten Zugriff entdeckt, reicht das einfache Installieren von Joomla 5.4.9 oder 6.1.4 nicht mehr aus.

Die Joomla-Installation sollte dann als potenziell kompromittiert behandelt werden.

Joomla Core, Erweiterungen, Templates, Benutzerkonten, geplante Aufgaben und relevante Server-Logs sollten überprüft werden. Anwendungsdateien sollten, wo möglich, mit vertrauenswürdigen Originaldateien verglichen werden.

Zugangsdaten, auf die aus der betroffenen Joomla-Umgebung zugegriffen werden konnte, sollten ebenfalls kontrolliert und nach Wiederherstellung der Integrität gegebenenfalls geändert werden.

Warum dieses Joomla Sicherheitsupdate besondere Aufmerksamkeit verdient

Eine Security-Version mit 16 Korrekturen bedeutet nicht automatisch, dass jede Joomla-Website gleichzeitig über 16 direkt ausnutzbare Angriffswege verfügte.

Die behobenen Schwachstellen betreffen jedoch mehrere wichtige Sicherheitsgrenzen: Dateisystemzugriff, serverseitige Netzwerkrequests, Authentifizierung, Multi-Faktor-Authentifizierung, Benutzerkontoerstellung und das Joomla-Zugriffskontrollsystem.

Die Kombination aus zwei High-Severity-Problemen und mehreren zusätzlichen Autorisierungs- und XSS-Schwachstellen macht eine zeitnahe Aktualisierung sinnvoll, auch wenn derzeit keine aktive Ausnutzung bestätigt ist.

Managed VPS bei Vservs

Die Absicherung eines Content-Management-Systems besteht nicht nur aus Updates für Erweiterungen. Auch Joomla Core und die zugrunde liegende Serverumgebung müssen aktuell gehalten und technisch gepflegt werden.

Mit einem Managed VPS von Vservs übernehmen wir unter anderem die technische Serververwaltung, relevante Betriebssystem- und Sicherheitsupdates, Monitoring und Server-Hardening.

Bei Unmanaged Hosting und Unmanaged VPS-Servern bleibt die Kontrolle und Installation von CMS-, Erweiterungs- und Server-Sicherheitsupdates in der Verantwortung des Administrators.

Zusammenfassung

• Software: Joomla Core
• Anzahl der Sicherheitskorrekturen: 16
• Wichtige High-Severity-Schwachstellen: CVE-2026-90915 und CVE-2026-92222
• Weitere wichtige Probleme: MFA-Bypass, nicht autorisierte Kontoerstellung, XSS und ACL-Schwachstellen
• Abgesicherte Joomla-5-Version: 5.4.9 oder neuer
• Abgesicherte Joomla-6-Version: 6.1.4 oder neuer
• Aktive Ausnutzung: zum Zeitpunkt der Veröffentlichung nicht zuverlässig bestätigt
• Empfehlung: Joomla aktualisieren und Website-Funktionalität anschließend überprüfen

Quellen

• Joomla Project – Joomla 6.1.4 & 5.4.9 Security & Bugfix Release
• Joomla Security Centre – CVE-2026-90915: Arbitrary Directory Deletion
• Joomla Security Centre – CVE-2026-92222: SSRF Vectors
• Joomla Security Centre – CVE-2026-92227: MFA Authentication Bypass

Die GiveWP Sicherheitslücke CVE-2026-97196 ermöglicht es einem nicht authentifizierten Angreifer, die Authentifizierung des beliebten WordPress-Spenden-Plugins zu umgehen. Die Schwachstelle betrifft GiveWP bis einschließlich Version 4.16.9 und wurde mit GiveWP 4.17.0 behoben. Patchstack bewertet die Sicherheitslücke mit einem CVSS-Score von 9,1.

Die GiveWP Sicherheitslücke ist besonders relevant, weil GiveWP auf mehr als 100.000 WordPress-Websites aktiv ist. Laut Patchstack ist kein bestehendes WordPress-Benutzerkonto erforderlich, um die verwundbare Funktion zu erreichen.

Es handelt sich um eine andere Sicherheitslücke als CVE-2026-85113, über die Vservs bereits berichtet hat. Diese Unterscheidung ist wichtig: GiveWP 4.16.9 war die abgesicherte Version für die frühere Schwachstelle, ist durch CVE-2026-97196 nun jedoch selbst verwundbar. Websites müssen deshalb erneut auf GiveWP 4.17.0 oder neuer aktualisiert werden.

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

CVE-2026-97196 ist eine Broken-Authentication-Schwachstelle in GiveWP. Laut Patchstack kann die Schwachstelle einem Angreifer ermöglichen, die normale Anmeldekontrolle zu umgehen oder sich unter den verwundbaren Bedingungen als ein anderer Benutzer zu authentifizieren, ohne dessen Passwort zu kennen.

Die veröffentlichten CVSS-Informationen zeigen, dass die Schwachstelle über das Netzwerk erreichbar ist und kein bereits authentifiziertes WordPress-Benutzerkonto voraussetzt.

• CVE: CVE-2026-97196
• Software: GiveWP – Donation Plugin and Fundraising Platform
• Typ: Broken Authentication
• CVSS: 9,1
• Authentifizierung erforderlich: Nein
• Betroffene Versionen: GiveWP 4.16.9 und älter
• Abgesicherte Version: GiveWP 4.17.0 oder neuer
• Aktive Installationen: mehr als 100.000

Die tatsächlichen Auswirkungen hängen davon ab, auf welches Benutzerkonto ein Angreifer Zugriff erlangen kann und welche Berechtigungen diesem Konto zugewiesen sind. Es wäre deshalb nicht korrekt zu behaupten, dass jede erfolgreiche Ausnutzung automatisch Administratorrechte ermöglicht.

Welche GiveWP-Versionen sind verwundbar?

Die GiveWP Sicherheitslücke betrifft folgende Versionen:

• GiveWP 4.16.9 und älter – verwundbar
• GiveWP 4.17.0 oder neuer – Sicherheitskorrektur vorhanden

WordPress.org führt GiveWP 4.17.0 derzeit als verfügbare Version. Administratoren, die noch 4.16.9 oder eine ältere Version einsetzen, sollten deshalb erneut aktualisieren.

Warum gibt es erneut eine GiveWP-Sicherheitswarnung?

Vservs hat bereits über CVE-2026-85113 in GiveWP berichtet. Für diese frühere Schwachstelle bestand die empfohlene Maßnahme darin, auf GiveWP 4.16.9 zu aktualisieren.

CVE-2026-97196 ist eine davon unabhängige und später veröffentlichte Schwachstelle. GiveWP 4.16.9 kann deshalb nicht mehr als ausreichend abgesichert betrachtet werden.

Wer GiveWP aufgrund der vorherigen Sicherheitswarnung bereits auf Version 4.16.9 aktualisiert hat, muss jetzt erneut auf GiveWP 4.17.0 oder neuer aktualisieren.

Dies ist insbesondere für Administratoren wichtig, die das vorherige Sicherheitsupdate korrekt installiert haben und deshalb möglicherweise davon ausgehen, dass ihre GiveWP-Installation weiterhin vollständig geschützt ist.

Was kann ein Angreifer mit der GiveWP Sicherheitslücke erreichen?

Ein erfolgreicher Authentifizierungs-Bypass kann einem Angreifer nicht autorisierten Zugriff auf ein bestehendes WordPress-Benutzerkonto ermöglichen.

Die praktischen Auswirkungen hängen von den Berechtigungen dieses Kontos ab. Der Zugriff auf ein Benutzerkonto mit niedrigen Rechten hat andere Folgen als der Zugriff auf ein Administrator- oder anderes privilegiertes Konto.

Abhängig vom betroffenen Benutzerkonto kann ein Angreifer möglicherweise Zugriff erhalten auf:

• WordPress-Funktionen, die für den betroffenen Benutzer verfügbar sind;
• GiveWP-Spender- und Spendenfunktionen, auf die das Konto zugreifen darf;
• Kontoeinstellungen und Profilinformationen;
• administrative Funktionen, wenn ein privilegiertes Konto betroffen ist;
• weitere Funktionen, die von installierten WordPress-Plugins bereitgestellt werden.

Der Authentifizierungs-Bypass selbst darf nicht mit einer direkten Remote-Code-Execution-Schwachstelle verwechselt werden. Patchstack klassifiziert CVE-2026-97196 als Broken Authentication und nicht als eigenständige RCE.

Erhält ein Angreifer automatisch Administratorrechte?

Nein. Die derzeit verfügbaren Informationen rechtfertigen nicht die Aussage, dass jede erfolgreiche Ausnutzung automatisch Zugriff auf ein WordPress-Administratorkonto ermöglicht.

Die Folgen hängen davon ab, welche Benutzeridentität übernommen werden kann und welche Berechtigungen dieses Konto besitzt.

Kann ein hoch privilegiertes Konto übernommen werden, können die weiteren Auswirkungen selbstverständlich erheblich sein. Ein WordPress-Administrator kann normalerweise Plugins installieren, Website-Funktionen verändern, Benutzer verwalten und weitere sensible Aktionen durchführen.

Vservs behandelt die Schwachstelle deshalb als kritisches Authentifizierungsproblem, ohne eine garantierte Administratorübernahme zu behaupten.

Wird CVE-2026-97196 aktiv ausgenutzt?

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

Patchstack stuft die Schwachstelle als Problem mit hoher Priorität ein und weist darauf hin, dass Schwachstellen dieses Typs für automatisierte Angriffe interessant sein können.

Die Erwartung einer möglichen zukünftigen Ausnutzung ist jedoch nicht mit einem Nachweis tatsächlich beobachteter Angriffe gleichzusetzen.

Vservs empfiehlt aufgrund der hohen Severity, der fehlenden Authentifizierung und der großen Installationsbasis ein sofortiges Update. CVE-2026-97196 wird derzeit jedoch nicht als nachweislich aktiv ausgenutzte Schwachstelle bezeichnet.

Was sollten WordPress-Administratoren jetzt tun?

1. Die aktuell installierte GiveWP-Version kontrollieren.
2. GiveWP auf Version 4.17.0 oder neuer aktualisieren.
3. Nicht davon ausgehen, dass GiveWP 4.16.9 weiterhin ausreichend abgesichert ist.
4. Kontrollieren, ob das Update erfolgreich abgeschlossen wurde.
5. Nach dem Update Spendenformulare und Zahlungsabläufe testen.
6. WordPress-Benutzerkonten auf unbekannte oder unerwartete Änderungen überprüfen.
7. Sofern entsprechende Logs vorhanden sind, aktuelle Login- und Administratoraktivitäten kontrollieren.
8. Nicht mehr verwendete WordPress-Benutzerkonten entfernen und Berechtigungen nach dem Least-Privilege-Prinzip einschränken.

Kann das Sicherheitsupdate nicht sofort installiert werden, kann GiveWP vorübergehend deaktiviert werden, um den verwundbaren Plugin-Code aus der aktiven WordPress-Umgebung zu entfernen. Dabei müssen selbstverständlich die Auswirkungen auf aktive Spendenformulare und Zahlungsprozesse berücksichtigt werden.

Website auf eine mögliche Kompromittierung prüfen

Da die GiveWP Sicherheitslücke die Authentifizierung betrifft, sollten Administratoren insbesondere auf Hinweise für nicht autorisierte angemeldete Sitzungen und anschließende WordPress-Aktivitäten achten.

Kontrollieren Sie insbesondere:

• unbekannte WordPress-Administratoren oder andere Benutzerkonten;
• unerwartete Änderungen an bestehenden Benutzerrollen;
• unerwartete Änderungen von Passwörtern oder E-Mail-Adressen;
• Login-Aktivitäten von unbekannten IP-Adressen;
• unerwartete Änderungen an GiveWP-Einstellungen;
• nicht erklärte Änderungen an Spenden- oder Zahlungseinstellungen;
• neue Plugins oder Themes, die nicht durch einen Administrator installiert wurden;
• unerwartete Änderungen an WordPress-Dateien oder der Konfiguration;
• administrative Aktivitäten, die keinem bekannten Administrator zugeordnet werden können.

Ein ungewöhnlicher Login oder eine Konfigurationsänderung allein beweist noch keine erfolgreiche Ausnutzung von CVE-2026-97196. Verdächtige Ereignisse sollten mit Webserver-Logs, WordPress-Aktivitätslogs, Benutzersitzungen und Dateisystem-Zeitstempeln abgeglichen werden.

Was tun, wenn nicht autorisierter Zugriff festgestellt wird?

Werden Hinweise auf einen nicht autorisierten Zugriff auf ein privilegiertes WordPress-Konto gefunden, reicht ein einfaches Update von GiveWP nicht mehr aus.

Ein Angreifer mit erweiterten WordPress-Berechtigungen kann bereits ein Plugin installiert, ein Theme verändert, ein weiteres Administratorkonto erstellt oder persistenten PHP-Code an anderer Stelle der Website hinterlegt haben.

Die WordPress-Installation sollte deshalb als potenziell kompromittiert behandelt werden. WordPress Core, Plugins, Themes, Must-Use-Plugins, Benutzerkonten, geplante Aufgaben und relevante Server-Logs sollten kontrolliert werden.

Zugangsdaten, auf die über das kompromittierte Konto zugegriffen werden konnte, sollten ebenfalls überprüft und nach Wiederherstellung der Integrität gegebenenfalls geändert werden.

GiveWP hat mehrere Sicherheitsupdates erhalten

CVE-2026-97196 ist nicht das einzige Sicherheitsproblem, das zuletzt in GiveWP behoben wurde. Das Plugin hat innerhalb kurzer Zeit mehrere Sicherheitsupdates erhalten.

Deshalb ist es besonders wichtig, die aktuelle unterstützte GiveWP-Version einzusetzen und nicht lediglich auf die Mindestversion zu aktualisieren, die in einer älteren Sicherheitswarnung genannt wurde.

GiveWP 4.17.0 enthält laut dem offiziellen Changelog auf WordPress.org außerdem weitere Sicherheitsverbesserungen.

Managed WordPress und Managed VPS bei Vservs

Aktuelle WordPress-Core-, Plugin- und Theme-Versionen sind ein wichtiger Bestandteil der Absicherung einer WordPress-Website.

Mit Vservs Managed WordPress übernehmen wir unter anderem die technische WordPress-Verwaltung, Sicherheitsupdates, Hardening, Malware-Kontrollen, Backups und Monitoring.

Für Websites und Anwendungen, die eine eigene isolierte Serverumgebung benötigen, bietet Vservs außerdem Managed VPS. Dazu gehören unter anderem technische Serververwaltung, relevante Betriebssystem- und Sicherheitsupdates, Monitoring und Server-Hardening.

Bei Unmanaged Hosting und Unmanaged VPS-Servern bleibt die Kontrolle und Installation von WordPress-, Plugin-, Theme- und Server-Sicherheitsupdates in der Verantwortung des Administrators.

Zusammenfassung

• Schwachstelle: CVE-2026-97196
• Software: GiveWP – Donation Plugin and Fundraising Platform
• Typ: Broken Authentication
• CVSS: 9,1
• Authentifizierung erforderlich: Nein
• Betroffene Versionen: GiveWP 4.16.9 und älter
• Abgesicherte Version: GiveWP 4.17.0 oder neuer
• Aktive Installationen: mehr als 100.000
• Aktive Ausnutzung: zum Zeitpunkt der Veröffentlichung nicht zuverlässig bestätigt
• Empfehlung: sofort auf GiveWP 4.17.0 oder neuer aktualisieren

Quellen

• Patchstack – GiveWP CVE-2026-97196 Broken Authentication
• WordPress.org – GiveWP Donation Plugin and Fundraising Platform