Zum Hauptinhalt springen

Autor: Vincent Zeilmaker – Vservs UG

FireBox Sicherheitslücke CVE-2026-76801 Remote Code Execution WordPress

FireBox Sicherheitslücke ermöglicht Remote Code Execution in WordPress

FireBox Sicherheitslücke CVE-2026-76801 kann einem authentifizierten Angreifer ermöglichen, Code auf WordPress-Websites auszuführen, auf denen eine verwundbare Version des FireBox-Plugins installiert ist.

Die Sicherheitslücke betrifft FireBox bis einschließlich Version 3.1.10. Relevante Sicherheitsmaßnahmen wurden mit FireBox 3.1.11 eingeführt. Administratoren sollten auf die neueste unterstützte und verfügbare Version aktualisieren.

CVE-2026-76801 wurde mit einem CVSS-Score von 8.8 (High) bewertet. Zum Zeitpunkt der Veröffentlichung gibt es keine zuverlässige Bestätigung dafür, dass die Sicherheitslücke aktiv in freier Wildbahn ausgenutzt wird.

FireBox Sicherheitslücke CVE-2026-76801

FireBox ist ein WordPress-Plugin für Popups, Formulare, E-Mail-Opt-ins, Exit-Intent-Kampagnen und verschiedene Marketingfunktionen für WooCommerce.

Die Sicherheitslücke betrifft Funktionen, mit denen FireBox benutzerdefinierte PHP-Logik ausführen kann.

Laut den veröffentlichten Informationen verwendet die betroffene Version unzureichende Einschränkungen bei der Kontrolle, welche PHP-Funktionen ausgeführt werden dürfen. Diese Sicherheitskontrollen können umgangen werden, wodurch WordPress-Funktionen aufgerufen werden können, die dem jeweiligen Benutzer normalerweise nicht zur Verfügung stehen sollten.

Zusätzlich werden Werte für PHP-Bedingungen innerhalb der betroffenen FireBox-Funktionalität nicht ausreichend sicher verarbeitet.

Fakten zur FireBox Sicherheitslücke

  • Produkt: FireBox für WordPress und WooCommerce
  • Plattform: WordPress / WooCommerce
  • CVE: CVE-2026-76801
  • Typ: Remote Code Execution / Privilege Escalation
  • Betroffene Versionen: FireBox ≤ 3.1.10
  • Sicherheitsfix: Schutzmaßnahmen ab FireBox 3.1.11
  • Erforderliche Rechte: Author-Rechte können bei betroffenen Konfigurationen ausreichend sein
  • Benutzerinteraktion: nicht erforderlich
  • CVSS: 8.8 High
  • Aktive Ausnutzung: zum Zeitpunkt der Veröffentlichung nicht bestätigt
  • Erforderliche Maßnahme: FireBox auf die neueste unterstützte Version aktualisieren

Was kann ein Angreifer erreichen?

Eine erfolgreiche Ausnutzung dieser FireBox Sicherheitslücke kann einem Angreifer ermöglichen, WordPress-Funktionen aufzurufen, deren Auswirkungen erheblich über die normalen Rechte seines Benutzerkontos hinausgehen.

In den veröffentlichten Informationen werden unter anderem sicherheitsrelevante Funktionen wie folgende genannt:

  • wp_insert_user;
  • update_option;
  • file_put_contents.

Diese Funktionen sind sicherheitskritisch, da sie beispielsweise zur Erstellung von WordPress-Benutzern, zur Änderung der WordPress-Konfiguration oder zum Schreiben von Dateien auf den Server verwendet werden können.

Abhängig von der Konfiguration der betroffenen Website kann ein Angreifer dadurch seine Berechtigungen erweitern und letztlich beliebigen Code innerhalb der WordPress-Umgebung ausführen.

Author-Rechte können ausreichend sein

Für CVE-2026-76801 ist eine Authentifizierung erforderlich. Ein vollständig unauthentifizierter Besucher kann den beschriebenen Angriff daher nicht unmittelbar durchführen.

Diese Voraussetzung reduziert die Angriffsfläche, macht die Sicherheitslücke jedoch nicht ungefährlich.

Auf betroffenen Installationen kann ein WordPress-Benutzer mit der Rolle Author über ausreichende Berechtigungen verfügen, um die verwundbare FireBox-Funktionalität zu erreichen.

Dies kann insbesondere bei Websites relevant sein, die von älteren FireBox-Versionen aktualisiert wurden und bei denen vorhandene Berechtigungen für Kampagnen während des Upgrade-Prozesses erhalten geblieben sind.

Administratoren sollten daher nicht automatisch davon ausgehen, dass ausschließlich WordPress-Administratoren Zugriff auf sicherheitskritische FireBox-Funktionen besitzen.

FireBox sofort aktualisieren

Websites mit FireBox 3.1.10 oder älter sollten umgehend aktualisiert werden.

FireBox 3.1.11 führte zusätzliche Sicherheitsbeschränkungen für benutzerdefiniertes PHP und andere Custom-Code-Funktionen ein.

Vservs empfiehlt, nicht bewusst auf der ersten korrigierten Version zu verbleiben, sondern nach einer Kompatibilitätsprüfung die aktuellste stabile und unterstützte FireBox-Version zu installieren.

Bei geschäftskritischen Websites sollte vor dem Update ein aktuelles Backup erstellt werden. Anschließend sollten sämtliche FireBox- und WooCommerce-Funktionen überprüft werden.

Kontrollieren Sie insbesondere:

  • die installierte FireBox-Version;
  • vorhandene FireBox-Kampagnen;
  • Popup-Funktionen;
  • Formulare und E-Mail-Opt-ins;
  • Exit-Intent-Kampagnen;
  • WooCommerce-Integrationen;
  • benutzerdefiniertes PHP, JavaScript oder CSS innerhalb von FireBox;
  • WordPress- und PHP-Fehlerprotokolle nach dem Update.

FireBox-Berechtigungen überprüfen

Da CVE-2026-76801 ein authentifiziertes WordPress-Benutzerkonto voraussetzt, sollten Administratoren zusätzlich kontrollieren, welche Benutzer und Benutzerrollen Zugriff auf FireBox-Kampagnen und Custom-Code-Funktionen besitzen.

Achten Sie insbesondere auf:

  • Author-Konten, die nicht mehr benötigt werden;
  • unerwartete Änderungen an WordPress-Benutzerrollen;
  • Benutzer, die FireBox-Kampagnen bearbeiten oder veröffentlichen dürfen;
  • unerwarteten PHP-Code in bestehenden Kampagnen;
  • unerwarteten JavaScript-Code oder andere Custom-Code-Inhalte;
  • Benutzerkonten mit zusätzlichen oder unerwarteten Capabilities.

Nicht benötigte Berechtigungen für Funktionen, mit denen benutzerdefinierter Code ausgeführt werden kann, sollten entfernt werden.

Kontrolle auf eine mögliche Kompromittierung

Zum Zeitpunkt der Veröffentlichung sind keine zuverlässigen und allgemein verwendbaren Indicators of Compromise bekannt, mit denen eine Ausnutzung von CVE-2026-76801 eindeutig festgestellt werden kann.

Vservs veröffentlicht daher keine unbestätigten IP-Adressen, Dateinamen oder andere spekulative IoCs.

Administratoren von Websites, auf denen eine verwundbare FireBox-Version eingesetzt wurde, können die Umgebung dennoch gezielt auf folgende Auffälligkeiten überprüfen:

  • unbekannte Administrator- oder andere WordPress-Benutzerkonten;
  • unerwartete Änderungen an WordPress-Optionen;
  • kürzlich erstellte oder veränderte PHP-Dateien;
  • PHP-Dateien an Orten, an denen diese normalerweise nicht vorhanden sein sollten;
  • unerwartete Änderungen an aktiven Plugins oder Themes;
  • verdächtige FireBox-Kampagnen oder benutzerdefinierten PHP-Code;
  • ungewöhnliche Requests an FireBox-REST-API-Funktionen in den Webserver-Logs.

Diese Prüfungen sind allgemeine Kompromittierungschecks. Ein einzelner Fund stellt für sich genommen keinen Beweis dafür dar, dass CVE-2026-76801 tatsächlich ausgenutzt wurde.

Keine bestätigte aktive Ausnutzung

Zum Zeitpunkt der Veröffentlichung gibt es keine zuverlässige Bestätigung dafür, dass CVE-2026-76801 aktiv in freier Wildbahn ausgenutzt wird.

Die Sicherheitslücke ist dennoch relevant, da eine erfolgreiche Ausnutzung zu einer Rechteausweitung und letztlich zur Ausführung von Code innerhalb der betroffenen WordPress-Umgebung führen kann.

Da technische Informationen zur Sicherheitslücke öffentlich verfügbar sind, sollten Administratoren betroffener Websites das Update nicht aufschieben.

Verantwortung für WordPress- und CMS-Sicherheitsupdates

Kunden ohne Managed WordPress/CMS-Wartung oder eine separat vereinbarte Managed-CMS-Dienstleistung sind selbst dafür verantwortlich, WordPress, WooCommerce, andere CMS-Systeme, Plugins, Erweiterungen und Themes rechtzeitig zu aktualisieren.

Wenn eine Website oder ein Dienst aufgrund von Missbrauch, Malware oder nachweislich überfälliger Wartung ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betroffene Website oder den betroffenen Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weiteren Missbrauch, Schäden oder Beeinträchtigungen unserer Infrastruktur und Dienste zu verhindern.

Wiederherstellungsarbeiten an nicht verwalteten Umgebungen außerhalb unserer regulären Geschäftszeiten, an Wochenenden oder Feiertagen hängen von der Schwere des Vorfalls und der verfügbaren Kapazität ab. Wenn kein sofortiges Eingreifen erforderlich ist, können Wiederherstellungsarbeiten ab dem nächsten Werktag durchgeführt werden.

Managed WordPress von Vservs

Sicherheitslücken wie CVE-2026-76801 zeigen, warum die Aktualisierung von WordPress Core allein nicht ausreichend ist. Auch Plugins, Themes, Benutzerberechtigungen und unerwartete Änderungen innerhalb einer Website müssen überwacht werden.

Mit Vservs Managed WordPress übernehmen wir unter anderem WordPress-Core-, Plugin- und Theme-Updates, Security Hardening, Security- und Malware-Monitoring, automatische Backups sowie die technische Verwaltung der WordPress-Umgebung.

Für Unternehmen und Organisationen, die die technische Wartung und Sicherheit ihrer WordPress- oder WooCommerce-Umgebung nicht selbst übernehmen möchten, stehen verschiedene Managed-WordPress-Lösungen zur Verfügung.

Quellen

WPML Sicherheitslücke CVE-2026-17509 SQL-Injection WordPress-Datenbank

SQL-Injection in WPML ermöglicht das Auslesen der WordPress-Datenbank

WPML Sicherheitslücke CVE-2026-17509 ermöglicht einem Angreifer mit lediglich einem WordPress-Benutzerkonto mit Subscriber-Rechten eine SQL-Injection auf Websites, die WPML Multilingual CMS verwenden.

Die Sicherheitslücke betrifft WPML Multilingual CMS bis einschließlich Version 4.9.5. Patchstack führt WPML 4.9.6 als gepatchte Version auf. Websites mit einer betroffenen Version sollten daher umgehend auf eine gepatchte oder neuere verfügbare Version aktualisiert werden.

Der von Wordfence zugewiesene offizielle CVE-Eintrag bewertet die Schwachstelle mit einem CVSS-Score von 6.5 (Medium). Patchstack stuft die Sicherheitslücke als High Priority ein. Zum Zeitpunkt der Veröffentlichung gibt es keine zuverlässige Bestätigung dafür, dass CVE-2026-17509 aktiv in freier Wildbahn ausgenutzt wird.

WPML Sicherheitslücke CVE-2026-17509

WPML Multilingual CMS ist eine weit verbreitete WordPress-Lösung zur Erstellung und Verwaltung mehrsprachiger Websites.

Bei CVE-2026-17509 handelt es sich um eine zeitbasierte SQL-Injection im Zusammenhang mit dem Parameter elementIds. Benutzereingaben werden dabei nicht ausreichend sicher verarbeitet, bevor sie in eine Datenbankabfrage einfließen.

Zusätzlich besteht ein Autorisierungsproblem. Laut CVE-Beschreibung wird der registrierte Authorization Callback unter bestimmten Umständen nicht ausgeführt. Dadurch können authentifizierte WordPress-Benutzer unabhängig von ihrer Rolle auf administrative Übersetzungsfunktionen zugreifen, die normalerweise nicht für sie verfügbar sein sollten.

Ein Angreifer benötigt daher keine Administrator-, Editor- oder Author-Rechte. Ein WordPress-Konto mit Subscriber-Rechten ist ausreichend, um die verwundbare Funktionalität zu erreichen.

Fakten zur WPML Sicherheitslücke

  • Produkt: WPML Multilingual CMS für WordPress
  • CVE: CVE-2026-17509
  • Typ: Time-based SQL Injection / Incorrect Authorization
  • CWE: CWE-89 – SQL Injection
  • Betroffene Versionen: WPML Multilingual CMS ≤ 4.9.5
  • Gepatchte Version: WPML 4.9.6 laut Patchstack
  • Erforderliche Rechte: Subscriber oder höher
  • Benutzerinteraktion: nicht erforderlich
  • Offizieller CVE/Wordfence CVSS: 6.5 Medium
  • Patchstack-Einstufung: High Priority
  • Aktive Ausnutzung: derzeit nicht bestätigt
  • Erforderliche Maßnahme: WPML auf eine gepatchte oder neuere verfügbare Version aktualisieren

Was kann ein Angreifer mit CVE-2026-17509 erreichen?

Ein Angreifer mit einem gültigen WordPress-Konto und mindestens Subscriber-Rechten kann speziell präparierte Daten an die verwundbare WPML-Funktionalität übermitteln.

Da der Parameter elementIds nicht ausreichend abgesichert und die bestehende Datenbankabfrage nicht ausreichend vorbereitet wird, kann ein Angreifer zusätzliche SQL-Abfragen an bestehende Queries anhängen.

Laut der offiziellen CVE-Beschreibung kann dies verwendet werden, um sensible Informationen aus der WordPress-Datenbank auszulesen.

Eine WordPress-Datenbank kann neben normalen Website-Inhalten unter anderem folgende Informationen enthalten:

  • WordPress-Benutzerdaten;
  • Website- und Plugin-Konfigurationen;
  • WooCommerce-Kunden- und Bestelldaten;
  • Anwendungseinstellungen;
  • Konfigurationen von APIs und Integrationen;
  • weitere von Plugins und Themes gespeicherte Informationen.

Welche Informationen tatsächlich zugänglich sind, hängt von der jeweiligen WordPress-Installation und den in der Datenbank gespeicherten Daten ab.

Warum Subscriber-Rechte relevant sind

Die erforderliche Authentifizierung reduziert das Risiko gegenüber einer vollständig unauthentifizierten SQL-Injection. CVE-2026-17509 sollte deshalb jedoch nicht unterschätzt werden.

Subscriber ist die niedrigste standardmäßige Benutzerrolle in WordPress. Auf Websites, auf denen Besucher selbst Benutzerkonten erstellen können, kann ein Angreifer die erforderlichen Zugriffsrechte möglicherweise ohne Unterstützung eines Administrators erhalten.

Dies ist insbesondere relevant für Websites mit:

  • öffentlicher WordPress-Benutzerregistrierung;
  • Mitgliederbereichen;
  • Community-Funktionen;
  • WooCommerce-Kundenkonten;
  • Lernplattformen;
  • Kunden- oder Benutzerportalen;
  • Plugins, die automatisch WordPress-Benutzerkonten erstellen.

Administratoren sollten daher nicht davon ausgehen, dass Subscriber-Rechte automatisch bedeuten, dass nur vertrauenswürdige Benutzer die verwundbare Funktionalität erreichen können.

WPML auf Version 4.9.6 oder neuer aktualisieren

Die dauerhafte Lösung für diese WPML Sicherheitslücke besteht darin, die betroffene WPML Multilingual CMS Installation zu aktualisieren.

Patchstack nennt WPML 4.9.6 als gepatchte Version. Betroffene Installationen sollten daher mindestens auf Version 4.9.6 oder eine neuere unterstützte Version aktualisiert werden.

Wenn für die jeweilige Umgebung bereits eine neuere stabile WPML-Version verfügbar ist, empfehlen wir nach einer Kompatibilitätsprüfung die Installation der aktuellen unterstützten Version.

Bei geschäftskritischen WordPress-Websites sollte vor dem Update ein aktuelles Backup erstellt werden. Anschließend sollte überprüft werden, ob sämtliche mehrsprachigen Funktionen weiterhin korrekt arbeiten.

Kontrollieren Sie insbesondere:

  • die aktuell installierte WPML-Version;
  • Frontend-Seiten in allen konfigurierten Sprachen;
  • Sprachumschalter;
  • übersetzte Beiträge und Seiten;
  • WPML Translation Management;
  • WooCommerce-Produkte und Checkout, sofern vorhanden;
  • WPML-Erweiterungen und zusätzliche Übersetzungsplugins;
  • PHP-, WordPress- und Datenbank-Fehlerprotokolle nach dem Update.

WordPress-Benutzerkonten kontrollieren

Da für eine Ausnutzung ein gültiges WordPress-Benutzerkonto erforderlich ist, sollten Administratoren von Websites, auf denen eine betroffene WPML-Version eingesetzt wurde, zusätzlich die vorhandenen Benutzerkonten überprüfen.

Achten Sie insbesondere auf:

  • kürzlich angelegte Benutzerkonten, die nicht erklärt werden können;
  • unerwartete Subscriber-Konten;
  • Konten, die über externe Registrierungsfunktionen erstellt wurden;
  • unerwartete Änderungen an bestehenden Benutzern oder Benutzerrollen;
  • unnötig aktivierte öffentliche Benutzerregistrierung.

Wenn eine öffentliche Benutzerregistrierung für die Website nicht erforderlich ist, sollte überprüft werden, ob diese tatsächlich deaktiviert wurde.

Kontrolle auf eine mögliche Kompromittierung

Zum Zeitpunkt der Veröffentlichung sind keine zuverlässigen und allgemein verwendbaren Indicators of Compromise bekannt, mit denen eine Ausnutzung von CVE-2026-17509 eindeutig festgestellt werden kann.

Vservs veröffentlicht daher keine unbestätigten IP-Adressen, Dateinamen oder andere spekulative IoCs.

Bei einer möglicherweise betroffenen Website können Administratoren die Umgebung dennoch gezielt auf folgende Auffälligkeiten überprüfen:

  • unbekannte oder unerwartet angelegte WordPress-Benutzer;
  • verdächtige Aktivitäten von Subscriber-Konten;
  • ungewöhnliche Requests an WPML-Funktionen in den Webserver-Logs;
  • unerwartete Datenbankaktivitäten;
  • nicht erklärbare Änderungen an WordPress-Benutzern oder Konfigurationen;
  • neue PHP-Dateien oder andere Dateien, die nicht zur normalen Website-Installation gehören.

Diese Kontrollen können bei der Erkennung ungewöhnlicher Aktivitäten helfen. Sie stellen für sich genommen jedoch keinen Beweis dafür dar, dass CVE-2026-17509 tatsächlich ausgenutzt wurde.

Keine bestätigte aktive Ausnutzung

Zum Zeitpunkt der Veröffentlichung gibt es keine zuverlässige Bestätigung dafür, dass CVE-2026-17509 aktiv in freier Wildbahn ausgenutzt wird.

Der offizielle, von Wordfence zugewiesene CVE-Eintrag bewertet die Sicherheitslücke mit CVSS 3.1 6.5 Medium. Patchstack stuft die Schwachstelle als High Priority ein und empfiehlt eine schnelle Behebung.

Das Fehlen bestätigter Angriffe ist kein Grund, das Update aufzuschieben. Die technischen Informationen zur Sicherheitslücke sind öffentlich bekannt und eine gepatchte Version ist verfügbar.

Verantwortung für WordPress- und CMS-Updates

Kunden ohne Managed WordPress/CMS-Wartung oder eine separat vereinbarte Managed-CMS-Dienstleistung sind selbst dafür verantwortlich, WordPress, andere CMS-Systeme, Plugins, Erweiterungen und Themes rechtzeitig zu aktualisieren.

Wenn eine Website oder ein Dienst aufgrund von Missbrauch, Malware oder nachweislich überfälliger Wartung ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betroffene Website oder den betroffenen Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weiteren Missbrauch, Schäden oder Beeinträchtigungen unserer Infrastruktur und Dienste zu verhindern.

Wiederherstellungsarbeiten an nicht verwalteten Umgebungen außerhalb unserer regulären Geschäftszeiten, an Wochenenden oder Feiertagen hängen von der Schwere des Vorfalls und der verfügbaren Kapazität ab. Wenn kein sofortiges Eingreifen erforderlich ist, können Wiederherstellungsarbeiten ab dem nächsten Werktag durchgeführt werden.

Managed WordPress von Vservs

Die rechtzeitige Erkennung und Behebung von Sicherheitslücken wie CVE-2026-17509 ist ein wichtiger Bestandteil des technischen Betriebs einer professionellen WordPress-Umgebung.

Mit Vservs Managed WordPress übernehmen wir unter anderem WordPress-Core-, Plugin- und Theme-Updates, Security Hardening, Security- und Malware-Monitoring, automatische Backups sowie die technische Verwaltung der WordPress-Umgebung.

Für Unternehmen und Organisationen, die die technische Wartung und Sicherheit ihrer WordPress-Umgebung nicht selbst übernehmen möchten, stehen verschiedene Managed-WordPress-Lösungen zur Verfügung.

Quellen

Magento Security Update APSB26-138 acht kritische Sicherheitslücken

Magento Security Update behebt acht kritische Sicherheitslücken

Magento Security Update APSB26-138 wurde von Adobe am 8. September 2026 für Adobe Commerce, Adobe Commerce B2B und Magento Open Source veröffentlicht. Das Update behebt acht kritische Sicherheitslücken.

Die Schwachstellen können unter anderem zu Privilege Escalation und zur Umgehung von Sicherheitsmechanismen führen. Laut Adobe können sechs der acht Sicherheitslücken ohne Authentifizierung ausgenutzt werden.

Der höchste CVSS-Score beträgt 9.3. Zum Zeitpunkt der Veröffentlichung sind Adobe keine Exploits in freier Wildbahn für die acht mit APSB26-138 behobenen Schwachstellen bekannt.

Wichtig ist, dass dieses Magento Security Update den separaten Zero-Day-Hotfix für CVE-2026-75650 nicht ersetzt. Adobe weist ausdrücklich darauf hin, dass der Hotfix für CVE-2026-75650 zusätzlich zu den September-Sicherheitsupdates installiert werden muss.

Magento Security Update APSB26-138

Adobe hat APSB26-138 als neues Sicherheitsupdate für Adobe Commerce und Magento Open Source veröffentlicht.

Das Update enthält Sicherheitskorrekturen für acht CVEs:

  • CVE-2026-76200 – Stored Cross-Site Scripting;
  • CVE-2026-76201 – Stored Cross-Site Scripting;
  • CVE-2026-77111 – Incorrect Authorization;
  • CVE-2026-77109 – Incorrect Authorization in Adobe Commerce B2B;
  • CVE-2026-77774 – Incorrect Authorization;
  • CVE-2026-76202 – Incorrect Authorization;
  • CVE-2026-77110 – Path Traversal;
  • CVE-2026-77108 – Incorrect Authorization in Adobe Commerce B2B.

Adobe klassifiziert alle acht Schwachstellen als Critical.

Wichtige Informationen zum Magento Security Update

  • Adobe Bulletin: APSB26-138
  • Veröffentlichungsdatum: 8. September 2026
  • Produkte: Adobe Commerce, Adobe Commerce B2B und Magento Open Source
  • Anzahl der Schwachstellen: 8
  • Höchster Schweregrad: Critical
  • Höchster CVSS-Score: 9.3
  • Mögliche Auswirkungen: Privilege Escalation und Security Feature Bypass
  • Ohne Authentifizierung ausnutzbar: 6 von 8 Schwachstellen
  • Aktive Ausnutzung: Adobe sind derzeit keine Exploits in freier Wildbahn bekannt
  • Adobe Priority Rating: 2
  • Maßnahme: September-2026-Sicherheitsupdate installieren
  • Zusätzliche Maßnahme: separaten CVE-2026-75650-Hotfix prüfen und installieren

Zwei Schwachstellen mit CVSS 9.3

Die am höchsten bewerteten Schwachstellen in APSB26-138 sind CVE-2026-76200 und CVE-2026-76201.

Bei beiden Sicherheitsproblemen handelt es sich um Stored-Cross-Site-Scripting-Schwachstellen, die unter CWE-79 klassifiziert sind.

Adobe bewertet beide Schwachstellen mit einem CVSS-Score von 9.3 und nennt Privilege Escalation als mögliche Auswirkung.

Laut Adobe ist für die Ausnutzung keine Authentifizierung erforderlich. Eine Benutzerinteraktion ist jedoch notwendig.

Vier Incorrect-Authorization-Schwachstellen

APSB26-138 behebt außerdem mehrere Sicherheitsprobleme, die durch unzureichende Autorisierungskontrollen verursacht werden.

CVE-2026-77111 hat einen CVSS-Score von 8.7 und kann zur Umgehung von Sicherheitsmechanismen führen. Laut Adobe sind für die Ausnutzung eine Authentifizierung und hohe Benutzerrechte erforderlich.

CVE-2026-77109 betrifft Adobe Commerce B2B und hat einen CVSS-Score von 8.6. Die Schwachstelle kann ohne Authentifizierung ausgenutzt werden und zu Privilege Escalation führen.

CVE-2026-77774 hat ebenfalls einen CVSS-Score von 8.6. Eine Authentifizierung ist nicht erforderlich. Eine erfolgreiche Ausnutzung kann zur Umgehung von Sicherheitsmechanismen führen.

CVE-2026-76202 hat einen CVSS-Score von 8.2 und kann ohne Authentifizierung ausgenutzt werden. Die mögliche Auswirkung ist Privilege Escalation.

Path-Traversal-Schwachstelle in Adobe Commerce

Eine weitere mit dem Magento Security Update behobene Schwachstelle ist CVE-2026-77110.

Adobe klassifiziert diese als Improper Limitation of a Pathname to a Restricted Directory, allgemein als Path Traversal bezeichnet.

CVE-2026-77110 hat einen CVSS-Score von 7.6. Eine erfolgreiche Ausnutzung kann zur Umgehung von Sicherheitsmechanismen führen.

Laut Adobe sind für die Ausnutzung dieser Schwachstelle hohe Benutzerrechte erforderlich.

Adobe Commerce B2B Schwachstelle CVE-2026-77108

Mit CVE-2026-77108 wird außerdem eine weitere Schwachstelle behoben, die speziell Adobe Commerce B2B betrifft.

Diese Incorrect-Authorization-Schwachstelle hat einen CVSS-Score von 7.5 und kann ohne Authentifizierung ausgenutzt werden.

Adobe nennt Privilege Escalation als mögliche Auswirkung.

Welche Adobe-Commerce-Versionen sind betroffen?

Laut Adobe sind folgende Adobe-Commerce-Versionen von den in APSB26-138 behobenen Schwachstellen betroffen:

  • 2.4.9-2026-aug und früher;
  • 2.4.8-2026-aug und früher;
  • 2.4.7-2026-aug und früher;
  • 2.4.6-2026-aug und früher;
  • 2.4.5-2026-aug und früher;
  • 2.4.4-2026-aug und früher.

Adobe hat folgende September-2026-Updates veröffentlicht:

  • 2.4.9-2026-sep;
  • 2.4.8-2026-sep;
  • 2.4.7-2026-sep;
  • 2.4.6-2026-sep;
  • 2.4.5-2026-sep;
  • 2.4.4-2026-sep.

Adobe Commerce B2B Versionen

Für Adobe Commerce B2B nennt Adobe folgende betroffene Versionszweige:

  • 1.5.3-2026-aug und früher;
  • 1.5.2-2026-aug und früher;
  • 1.4.2-2026-aug und früher;
  • 1.3.4-2026-aug und früher;
  • 1.3.3-2026-aug und früher.

Die entsprechenden September-Updates sind:

  • 1.5.3-2026-sep;
  • 1.5.2-2026-sep;
  • 1.4.2-2026-sep;
  • 1.3.4-2026-sep;
  • 1.3.3-2026-sep.

Magento Open Source aktualisieren

Für Magento Open Source nennt Adobe folgende betroffene Versionen:

  • 2.4.9-2026-aug und früher;
  • 2.4.8-2026-aug und früher;
  • 2.4.7-2026-aug und früher;
  • 2.4.6-2026-aug und früher.

In APSB26-138 nennt Adobe folgende aktualisierte Magento-Open-Source-Versionen:

  • 2.4.9-2026-sep;
  • 2.4.8-2026-sep;
  • 2.4.7-2026-sep.

Für die jeweils eingesetzte Magento-Version sollten vor einem Update der Produktionsumgebung immer die aktuellen Adobe Release Notes und Installationshinweise geprüft werden.

Keine aktive Ausnutzung von APSB26-138 bekannt

Zum Zeitpunkt der Veröffentlichung gibt Adobe an, dass keine Exploits in freier Wildbahn für die acht mit APSB26-138 behobenen Schwachstellen bekannt sind.

Diese Unterscheidung ist wichtig. Die Schwachstellen aus diesem Magento Security Update sollten nicht als aktiv ausgenutzt bezeichnet werden, solange dafür keine zuverlässige Bestätigung vorliegt.

Damit unterscheidet sich die Situation deutlich von CVE-2026-75650, für die Adobe eine aktive Ausnutzung bestätigt hat.

Wichtig: CVE-2026-75650 benötigt einen separaten Hotfix

Dies ist derzeit einer der wichtigsten Punkte für Administratoren von Magento und Adobe Commerce.

Adobe hat am 7. September 2026 das separate Sicherheitsbulletin APSB26-146 für die kritische Zero-Day-Schwachstelle CVE-2026-75650 veröffentlicht.

Diese Schwachstelle hat einen CVSS-Score von 10.0, ermöglicht Arbitrary Code Execution ohne Authentifizierung und wird laut Adobe aktiv in freier Wildbahn ausgenutzt.

Adobe weist deshalb in APSB26-138 ausdrücklich darauf hin, dass Administratoren den Hotfix für CVE-2026-75650 zusätzlich zu den Sicherheitsupdates aus APSB26-138 installieren müssen.

Die alleinige Installation des neuen September-Sicherheitsupdates darf daher nicht als Bestätigung betrachtet werden, dass CVE-2026-75650 ebenfalls behoben wurde.

Beide Magento-Sicherheitsupdates kontrollieren

Administratoren sollten deshalb zwei separate Sicherheitsmaßnahmen überprüfen:

  • ob das September-2026-Sicherheitsupdate aus APSB26-138 installiert wurde;
  • ob der separate CVE-2026-75650-Hotfix aus APSB26-146 korrekt angewendet wurde.

Für CVE-2026-75650 stellt Adobe den Hotfix VULN-39341 bereit.

Da diese Zero-Day-Schwachstelle aktiv ausgenutzt wird, sollte zusätzlich untersucht werden, ob die Umgebung bereits vor der Installation des Hotfixes kompromittiert worden sein könnte. Das nachträgliche Patchen entfernt keine möglicherweise bereits installierte Malware oder Webshells.

Warum ein schnelles Update wichtig ist

Obwohl Adobe derzeit keine aktive Ausnutzung der acht APSB26-138-Schwachstellen meldet, können mehrere dieser Sicherheitsprobleme ohne Authentifizierung ausgenutzt werden.

Bei einer öffentlich erreichbaren E-Commerce-Umgebung sollte ein solches Sicherheitsupdate deshalb nicht unnötig aufgeschoben werden.

Magento- und Adobe-Commerce-Installationen verarbeiten zudem häufig sensible Kunden- und Bestelldaten und sind mit externen Systemen verbunden, beispielsweise:

  • Zahlungsanbietern;
  • ERP- und Buchhaltungssystemen;
  • Versandplattformen;
  • Lager- und Fulfilment-Systemen;
  • Marketingdiensten;
  • externen APIs;
  • Deployment- und Verwaltungssystemen.

Eine Schwachstelle, die Privilege Escalation oder die Umgehung von Sicherheitsmechanismen ermöglicht, kann daher Auswirkungen haben, die über den Onlineshop selbst hinausgehen.

Update zunächst in einer kontrollierten Umgebung testen

Bei geschäftskritischen Magento- und Adobe-Commerce-Umgebungen empfehlen wir, Sicherheitsupdates so schnell wie möglich zu installieren, dabei jedoch einen kontrollierten Updateprozess einzuhalten.

Erstellen Sie vorher ein aktuelles Backup, prüfen Sie individuelle Module und Erweiterungen von Drittanbietern und testen Sie das Update nach Möglichkeit zunächst in einer Staging-Umgebung.

Nach dem Update sollten mindestens folgende Bereiche überprüft werden:

  • Frontend und Checkout;
  • Zahlungsmethoden;
  • Magento Cronjobs;
  • API-Integrationen;
  • ERP- und Fulfilment-Anbindungen;
  • Administrationsfunktionen;
  • individuelle Module und Themes;
  • Magento- und Serverlogs auf neue Fehler.

Verantwortung für CMS-Sicherheitsupdates

Kunden ohne Managed WordPress/CMS-Wartung oder einen separat vereinbarten Managed-CMS-Service sind selbst dafür verantwortlich, Magento, Adobe Commerce, WordPress, andere CMS-Software, Plugins, Extensions und Themes rechtzeitig zu aktualisieren.

Wenn eine Website durch Missbrauch, Malware oder nachweisbar überfällige Wartung ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betroffene Website oder den betreffenden Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weiteren Missbrauch, Schäden oder Beeinträchtigungen unserer Infrastruktur und Dienste zu verhindern.

Wiederherstellungsarbeiten an nicht gemanagten Umgebungen außerhalb unserer regulären Geschäftszeiten, an Wochenenden oder Feiertagen sind von der Schwere des Vorfalls und unserer Verfügbarkeit abhängig. Wenn keine sofortige Intervention erforderlich ist, können die Wiederherstellungsarbeiten ab dem nächsten Werktag aufgenommen werden.

Managed Hosting von Vservs

Dieses Magento Security Update zeigt erneut, dass die Verwaltung einer geschäftskritischen E-Commerce-Umgebung weit über die Wartung des zugrunde liegenden Servers hinausgeht.

Security Advisories, Magento-Updates, Extensions, Serversicherheit, Monitoring, Backups und die Integrität des Onlineshops müssen gemeinsam überwacht werden.

Wenn Sie die vollständige technische Verwaltung einer Magento-, Adobe-Commerce- oder anderen geschäftskritischen E-Commerce-Umgebung nicht selbst übernehmen möchten, kontaktieren Sie Vservs, um die Möglichkeiten für Managed Hosting und Managed VPS zu besprechen.

Quellen

Magento CVE-2026-75650 Zero-Day wird aktiv ausgenutzt

Kritische Magento Zero-Day CVE-2026-75650 wird aktiv ausgenutzt

Magento CVE-2026-75650 ist eine kritische Zero-Day-Sicherheitslücke in Adobe Commerce und Magento Open Source, die bereits aktiv in freier Wildbahn ausgenutzt wird.

Die Schwachstelle erreicht die maximale CVSS-Bewertung von 10.0 Critical. Ein entfernter Angreifer kann die Sicherheitslücke ohne Benutzerkonto, Authentifizierung oder Benutzerinteraktion ausnutzen und beliebigen Code innerhalb eines anfälligen Onlineshops ausführen.

Adobe bestätigt, dass CVE-2026-75650 aktiv in freier Wildbahn ausgenutzt wird, und hat am 7. September 2026 ein dringendes Sicherheitsupdate veröffentlicht.

Aufgrund der Schwere von Magento CVE-2026-75650 und der bestätigten aktiven Ausnutzung sollten Administratoren von Magento Open Source und Adobe Commerce sofort handeln.

Magento CVE-2026-75650 wird aktiv ausgenutzt

CVE-2026-75650 wird durch eine fehlerhafte Verarbeitung spezieller Elemente innerhalb einer Template Engine von Adobe Commerce und Magento Open Source verursacht.

Die Schwachstelle ist als CWE-1336 – Improper Neutralization of Special Elements Used in a Template Engine klassifiziert.

Durch speziell präparierte Eingaben kann ein entfernter Angreifer beliebigen Code innerhalb der betroffenen Shop-Umgebung ausführen.

Für die Ausnutzung ist keine Authentifizierung erforderlich. Auch ein Administrator oder Besucher muss keinen Link öffnen oder eine andere Aktion durchführen.

Wichtige Informationen zu Magento CVE-2026-75650

  • Produkte: Adobe Commerce, Adobe Commerce B2B und Magento Open Source
  • CVE: CVE-2026-75650
  • Adobe Bulletin: APSB26-146
  • Adobe Hotfix: VULN-39341
  • Schwachstelle: Template Injection / Arbitrary Code Execution
  • CWE: CWE-1336
  • Schweregrad: Critical
  • CVSS: 10.0
  • Authentifizierung erforderlich: nein
  • Benutzerinteraktion erforderlich: nein
  • Exploit-Status: aktive Ausnutzung von Adobe bestätigt
  • Adobe Priority Rating: 1
  • Sicherheitslösung: Adobe Hotfix VULN-39341 installieren
  • Erforderliche Maßnahmen: sofort patchen, Umgebung auf Kompromittierung untersuchen und möglicherweise offengelegte Zugangsdaten ersetzen

Welche Magento- und Adobe-Commerce-Versionen sind betroffen?

Adobe nennt die folgenden Adobe-Commerce-Versionen als betroffen:

  • 2.4.9-2026-aug und früher;
  • 2.4.8-2026-aug und früher;
  • 2.4.7-2026-aug und früher;
  • 2.4.6-2026-aug und früher;
  • 2.4.5-2026-aug und früher;
  • 2.4.4-2026-aug und früher.

Für Adobe Commerce B2B sind folgende Versionszweige betroffen:

  • 1.5.3-2026-aug und früher;
  • 1.5.2-2026-aug und früher;
  • 1.4.2-2026-aug und früher;
  • 1.3.4-2026-aug und früher;
  • 1.3.3-2026-aug und früher.

Für Magento Open Source nennt Adobe:

  • 2.4.9-2026-aug und früher;
  • 2.4.8-2026-aug und früher;
  • 2.4.7-2026-aug und früher;
  • 2.4.6-2026-aug und früher.

Adobe hat für diese Schwachstelle einen separaten VULN-39341-Hotfix veröffentlicht. Die alleinige Kontrolle der sichtbaren Magento-Versionsnummer reicht daher nicht aus, um festzustellen, ob eine Umgebung geschützt ist.

Aktive Angriffe auf Magento CVE-2026-75650

Bei dieser Schwachstelle handelt es sich nicht nur um ein theoretisches Sicherheitsrisiko.

Adobe bestätigt ausdrücklich, dass CVE-2026-75650 aktiv in freier Wildbahn ausgenutzt wird.

Eine erfolgreiche Kompromittierung kann es einem Angreifer ermöglichen, dauerhaften Zugriff auf die Shop-Umgebung einzurichten, beispielsweise durch die Installation einer Backdoor oder Webshell.

Ein Onlineshop, der vor der Installation des Hotfixes öffentlich erreichbar und anfällig war, sollte deshalb nicht automatisch als sicher betrachtet werden, nur weil der Patch inzwischen installiert wurde.

Das Patchen verhindert eine erneute Ausnutzung über diese Schwachstelle, entfernt jedoch keine möglicherweise bereits installierte Malware.

Remote Code Execution ohne Anmeldung

Der veröffentlichte CVSS-Vektor für CVE-2026-75650 lautet:

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

Dies bedeutet unter anderem:

  • der Angriff kann über das Netzwerk durchgeführt werden;
  • die Angriffskomplexität ist gering;
  • es sind keine Benutzerrechte erforderlich;
  • es ist keine Benutzerinteraktion erforderlich;
  • die Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit sind hoch.

Eine erfolgreiche Remote Code Execution kann einem Angreifer ermöglichen, Dateien zu verändern, Malware oder Webshells zu installieren, Shop-Daten auszulesen und dauerhaften Zugriff auf die Umgebung einzurichten.

Für E-Commerce-Umgebungen ist dies besonders kritisch, da Magento und Adobe Commerce üblicherweise Zugriff auf Datenbanken, API-Tokens, Zahlungsanbieter und zahlreiche externe Integrationen besitzen.

Adobe Hotfix VULN-39341 sofort installieren

Adobe hat die Schwachstelle mit Priority Rating 1 eingestuft und empfiehlt, den verfügbaren Hotfix auf betroffenen Umgebungen unverzüglich zu installieren.

Für Adobe Commerce on-premises, Adobe Commerce on Cloud und Magento Open Source muss der passende VULN-39341-Patch installiert werden.

Adobe gibt an, dass der Hotfix offiziell mit den August-2026-Versionen der unterstützten Produktzweige getestet wurde. Er kann möglicherweise auch mit anderen unterstützten Versionen funktionieren, deren Kompatibilität wurde von Adobe jedoch nicht offiziell bestätigt.

Verwenden Sie deshalb ausschließlich den offiziellen Adobe-Hotfix und kontrollieren Sie sorgfältig, ob dieser erfolgreich installiert wurde.

Da Magento CVE-2026-75650 bereits aktiv ausgenutzt wird, sollte mit der Installation nicht bis zum nächsten regulären Wartungsfenster gewartet werden.

Nur patchen reicht nicht aus

Da CVE-2026-75650 bereits ausgenutzt wurde, bevor das Sicherheitsupdate verfügbar war, empfiehlt Adobe zusätzliche Maßnahmen.

Nach Installation des Hotfixes müssen der Commerce Encryption Key sowie möglicherweise offengelegte Zugangsdaten ersetzt werden.

Adobe weist ausdrücklich darauf hin, dass allein das Rotieren des Commerce Encryption Keys nicht ausreichend ist. Zugangsdaten, die zuvor entschlüsselt oder von einem Angreifer ausgelesen wurden, bleiben gültig, bis sie beim jeweiligen Dienst widerrufen oder ersetzt werden.

Welche Zugangsdaten sollten ersetzt werden?

Nach dem Patchen sollte überprüft werden, welche sensiblen Zugangsdaten aus der Magento-Umgebung erreichbar gewesen sein könnten.

  • Adobe Commerce/Magento Encryption Key;
  • Passwörter von Admin-Panel-Benutzern;
  • REST-, SOAP- und GraphQL-Integrationstokens;
  • OAuth Client Secrets;
  • API-Zugangsdaten von Zahlungsanbietern;
  • Datenbankbenutzer und Passwörter;
  • SSH- und Deployment-Keys;
  • Zugangsdaten von Cron- und anderen Service-Accounts;
  • API-Keys von Versand-, Steuer- und anderen externen Integrationen.

Zugangsdaten externer Dienste müssen beim jeweiligen Anbieter widerrufen und neu erstellt werden. Eine Änderung der in Magento gespeicherten Konfiguration allein macht bereits kompromittierte Zugangsdaten nicht zwangsläufig ungültig.

Prüfen, ob der Magento-Hotfix tatsächlich installiert ist

Adobe weist darauf hin, dass anhand der Magento-Versionsnummer allein nicht immer eindeutig festgestellt werden kann, ob CVE-2026-75650 behoben wurde.

Bei Adobe Commerce on Cloud kann der Status des VULN-39341-Hotfixes unter anderem mit folgendem Befehl überprüft werden:

vendor/bin/magento-patches -n status | grep "39341\|Status"

Der Hotfix muss dabei mit dem Status Applied angezeigt werden.

Bei anderen Installationstypen muss kontrolliert werden, ob der offizielle Adobe-Patch erfolgreich und ohne Fehler installiert wurde.

Magento auf mögliche Kompromittierung überprüfen

Da Magento CVE-2026-75650 aktiv ausgenutzt wird, sollten Administratoren die Umgebung nicht nur patchen, sondern auch untersuchen, ob sie möglicherweise bereits kompromittiert wurde.

Überprüfen Sie unter anderem:

  • kürzlich erstellte oder veränderte PHP-Dateien;
  • unerwartete Dateien in beschreibbaren Magento-Verzeichnissen;
  • unbekannte Webshells oder andere ausführbare Dateien;
  • unerwartete Änderungen an Templates und CMS-Inhalten;
  • neue oder unbekannte Magento-Administratorkonten;
  • unerwartete Änderungen an Integrationen oder API-Tokens;
  • ungewöhnliche Cronjobs;
  • unbekannte Prozesse unter dem Webserver-Benutzer;
  • unerwartete ausgehende Netzwerkverbindungen;
  • verdächtige HTTP-Anfragen aus dem Zeitraum, in dem der Shop anfällig war;
  • Dateiänderungen, die nicht durch ein reguläres Deployment erklärt werden können.

Eine vollständige serverseitige Malware- und Integritätsprüfung ist dringend zu empfehlen, wenn ein anfälliger Onlineshop vor der Installation des Hotfixes öffentlich erreichbar war.

Ein erfolgreicher Patch entfernt keine vorhandene Malware

Bei einer aktiv ausgenutzten Remote-Code-Execution-Schwachstelle ist dies ein besonders wichtiger Unterschied.

Der VULN-39341-Hotfix verhindert eine weitere Ausnutzung über CVE-2026-75650, entfernt jedoch keine Backdoors, Webshells oder andere Malware, die möglicherweise bereits vor dem Patchen installiert wurde.

Werden Hinweise auf eine Kompromittierung gefunden, sollte die Umgebung als Sicherheitsvorfall behandelt werden.

In diesem Fall müssen nicht nur die Magento-Installation, sondern auch der zugrunde liegende Server, Benutzerkonten, Datenbank, Cronjobs, SSH-Zugänge und externe Integrationen überprüft werden.

Warum diese Magento-Sicherheitslücke besonders kritisch ist

Ein Magento- oder Adobe-Commerce-Onlineshop verarbeitet in der Regel wesentlich mehr sensible Informationen und externe Integrationen als eine einfache Website.

Neben Kunden- und Bestelldaten bestehen häufig Verbindungen zu:

  • Zahlungsanbietern;
  • ERP- und Buchhaltungssystemen;
  • Versandplattformen;
  • Marketing- und Analytics-Diensten;
  • Lager- und Fulfilment-Systemen;
  • externen APIs;
  • Deployment- und Verwaltungssystemen.

Kann ein Angreifer beliebigen Code innerhalb der Shop-Umgebung ausführen, können dadurch auch Zugangsdaten und Informationen verbundener Systeme gefährdet sein.

Verantwortung für CMS-Sicherheitsupdates

Kunden ohne Managed WordPress/CMS-Wartung oder einen separat vereinbarten Managed-CMS-Service sind selbst dafür verantwortlich, Magento, Adobe Commerce, WordPress, andere CMS-Software, Plugins, Extensions und Themes rechtzeitig zu aktualisieren.

Wenn eine Website durch Missbrauch, Malware oder nachweisbar überfällige Wartung ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betroffene Website oder den betreffenden Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weiteren Missbrauch, Schäden oder Beeinträchtigungen unserer Infrastruktur und Dienste zu verhindern.

Wiederherstellungsarbeiten an nicht gemanagten Umgebungen außerhalb unserer regulären Geschäftszeiten, an Wochenenden oder Feiertagen sind von der Schwere des Vorfalls und unserer Verfügbarkeit abhängig. Wenn keine sofortige Intervention erforderlich ist, können die Wiederherstellungsarbeiten ab dem nächsten Werktag aufgenommen werden.

Managed Hosting von Vservs

Magento CVE-2026-75650 zeigt, dass bei geschäftskritischen E-Commerce-Umgebungen nicht nur die Verwaltung des zugrunde liegenden Servers wichtig ist. Auch Security Advisories, Anwendungspatches, Extensions, Malware-Erkennung und die Integrität des Onlineshops müssen aktiv überwacht werden.

Wenn Sie die vollständige technische Verwaltung einer geschäftskritischen Magento-, Adobe-Commerce- oder anderen E-Commerce-Umgebung nicht selbst übernehmen möchten, kontaktieren Sie Vservs, um die Möglichkeiten für Managed Hosting und Managed VPS zu besprechen.

Quellen

TYPO3 Security Update CVE-2026-77132 und CVE-2026-85400

TYPO3 Security Update behebt zwei neue Core-Sicherheitslücken

TYPO3 hat ein neues Security Update veröffentlicht, das zwei Sicherheitslücken im TYPO3 Core behebt.

Die Schwachstellen werden als CVE-2026-77132 und CVE-2026-85400 geführt. Abhängig von der verwendeten TYPO3-Version und den Backend-Berechtigungen können Backend-Benutzer dadurch Informationen abrufen, auf die sie keinen Zugriff haben sollten, oder ihre Berechtigungen erweitern.

Administratoren von TYPO3-Installationen sollten ihre eingesetzten Versionen überprüfen und betroffene Systeme zeitnah aktualisieren.

TYPO3 Security Update veröffentlicht

Am 8. September 2026 hat TYPO3 neue Security Advisories für zwei Schwachstellen im TYPO3 Core veröffentlicht.

Es handelt sich um:

  • CVE-2026-77132 – Information Disclosure über den Backend Localization Wizard;
  • CVE-2026-85400 – fehlende Autorisierung bei Low-Level-Kommandos mit möglicher Rechteausweitung.

Zum Zeitpunkt der Veröffentlichung gibt es keine bestätigten Hinweise auf eine aktive Ausnutzung dieser beiden Sicherheitslücken.

Die wichtigsten Sicherheitsinformationen

  • Produkt: TYPO3 CMS
  • Schwachstellen: CVE-2026-77132 und CVE-2026-85400
  • Auswirkungen: Information Disclosure und Privilege Escalation
  • Höchster Schweregrad: High
  • Höchster CVSS-Score: 7.5
  • Unauthentifizierter Remote-Angriff: nein
  • Exploit-Status: keine bestätigte aktive Ausnutzung bekannt
  • Erforderliche Maßnahme: betroffene TYPO3-Installationen auf eine gepatchte Version aktualisieren

CVE-2026-77132: Information Disclosure

Die erste Schwachstelle wird als CVE-2026-77132 geführt und von TYPO3 unter TYPO3-CORE-SA-2026-022 dokumentiert.

Die Sicherheitslücke betrifft den Backend Localization Wizard. Aufgrund unzureichender Autorisierungsprüfungen bei AJAX-Routen kann ein Backend-Benutzer mit eingeschränkten Berechtigungen möglicherweise Informationen abrufen, die außerhalb seiner vorgesehenen Zugriffsrechte liegen.

Die Schwachstelle wird als Information Disclosure klassifiziert.

TYPO3 bewertet das Problem mit dem Schweregrad Medium und einem CVSS-4.0-Score von 5.3.

Von CVE-2026-77132 betroffene TYPO3-Versionen

Die Sicherheitslücke betrifft mehrere TYPO3-Versionszweige.

  • TYPO3 10.0.0 bis 10.4.59 – Update auf 10.4.60;
  • TYPO3 11.0.0 bis 11.5.53 – Update auf 11.5.54;
  • TYPO3 12.0.0 bis 12.4.48 – Update auf 12.4.49;
  • TYPO3 13.0.0 bis 13.4.34 – Update auf 13.4.35;
  • TYPO3 14.0.0 bis 14.3.6 – Update auf 14.3.7.

Administratoren, die einen dieser Versionszweige einsetzen, sollten die entsprechende gepatchte Version installieren.

CVE-2026-85400: Rechteausweitung

Die zweite Schwachstelle, CVE-2026-85400, ist schwerwiegender und wird von TYPO3 als TYPO3-CORE-SA-2026-023 dokumentiert.

Das Problem betrifft fehlende Autorisierungsprüfungen für bestimmte Low-Level-Kommandos von TYPO3.

Ein TYPO3-Backend-Administrator, der nicht über System-Maintainer-Rechte verfügt, kann unter bestimmten Voraussetzungen über den TYPO3 Scheduler eigentlich eingeschränkte Kommandos ausführen.

Betroffen sind Funktionen zum Lesen, Anzeigen und Ändern der TYPO3-Konfiguration.

Dadurch könnte ein Angreifer, der bereits über ein entsprechend privilegiertes Backend-Konto verfügt, seine Berechtigungen weiter erhöhen und möglicherweise System-Maintainer-Rechte erhalten.

Abhängig von den ausgeführten Kommandos kann darüber hinaus eine Störung der TYPO3-Installation möglich sein.

Von CVE-2026-85400 betroffene TYPO3-Versionen

CVE-2026-85400 betrifft:

  • TYPO3 14.2.0 bis 14.3.6.

Die Sicherheitslücke wurde behoben in:

  • TYPO3 14.3.7.

TYPO3 stuft diese Schwachstelle als High mit einem CVSS-Score von 7.5 ein.

TYPO3 auf eine sichere Version aktualisieren

Administratoren sollten zunächst feststellen, welcher TYPO3-Versionszweig aktuell eingesetzt wird, und anschließend auf das entsprechende Security Release aktualisieren.

Für aktuelle TYPO3-14-Installationen bedeutet dies ein Update auf mindestens:

TYPO3 14.3.7

Für ältere Versionszweige, die von CVE-2026-77132 betroffen sind, sollte die im Security Advisory genannte gepatchte Version installiert werden.

TYPO3 gibt an, dass speziell für das Security Release TYPO3 14.3.7 kein Datenbank-Update erforderlich ist. Nach dem Update sollte die Installation dennoch kontrolliert werden. Je nach Umgebung sollten außerdem die Anwendungscaches geleert und bei Bedarf der TYPO3 Database Analyzer ausgeführt werden.

Backend-Konten und Berechtigungen überprüfen

Diese Schwachstellen unterscheiden sich von vielen kritischen CMS-Sicherheitslücken, da ein externer Angreifer ohne Anmeldung dadurch nicht unmittelbar Remote-Zugriff auf den Server erhält.

Trotzdem sollten TYPO3-Administratoren die Sicherheit des Backends überprüfen.

Kontrollieren Sie insbesondere:

  • alle aktiven TYPO3-Backend-Konten;
  • Administrator-Konten, die nicht mehr benötigt werden;
  • vergebene System-Maintainer-Rechte;
  • Backend-Benutzergruppen und deren Berechtigungen;
  • unerwartet erstellte oder geänderte Scheduler-Tasks;
  • ungewöhnliche Änderungen an der TYPO3-Konfiguration;
  • aktuelle Backend-Anmeldungen;
  • neu angelegte Konten ohne nachvollziehbaren administrativen Grund.

Nicht mehr benötigte Administrator-Konten sollten deaktiviert oder entfernt werden. Berechtigungen sollten grundsätzlich nach dem Prinzip der geringstmöglichen Rechte vergeben werden.

Keine bestätigte aktive Ausnutzung

Zum Zeitpunkt der Veröffentlichung gibt es keine zuverlässige Bestätigung, dass CVE-2026-77132 oder CVE-2026-85400 aktiv in freier Wildbahn ausgenutzt werden.

Vservs bezeichnet diese Schwachstellen daher nicht als aktiv ausgenutzt.

Es wurden außerdem keine verlässlichen schwachstellenspezifischen Indicators of Compromise veröffentlicht, die eine Zuordnung bestimmter IP-Adressen, Dateinamen oder anderer Artefakte zu diesen Sicherheitslücken rechtfertigen würden.

Administratoren sollten sich deshalb auf das Update von TYPO3 sowie die Kontrolle von Backend-Zugängen und Konfigurationsänderungen konzentrieren und keine unbestätigten IoCs verwenden.

Warum das TYPO3 Security Update wichtig ist

TYPO3 wird häufig für Unternehmenswebsites, Portale und andere professionelle Webprojekte eingesetzt, bei denen mehrere Administratoren, Redakteure oder externe Agenturen Zugriff auf das Backend besitzen.

Autorisierungsschwachstellen sind in solchen Umgebungen besonders relevant. Wird ein Backend-Konto kompromittiert oder verfügt ein Benutzer über zu weitreichende Berechtigungen, kann eine zusätzliche Rechteausweitung die möglichen Auswirkungen erheblich vergrößern.

TYPO3 Core und installierte Extensions sollten deshalb konsequent auf einem aktuellen und unterstützten Sicherheitsstand gehalten werden.

Verantwortung für CMS-Updates

Kunden ohne Managed WordPress/CMS-Wartung oder einen separat vereinbarten Managed-CMS-Service sind selbst dafür verantwortlich, CMS-Software, Plugins, Extensions und Themes rechtzeitig zu aktualisieren.

Wenn eine Website durch Missbrauch, Malware oder nachweisbar überfällige Wartung ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betroffene Website oder den betreffenden Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weiteren Missbrauch, Schäden oder Beeinträchtigungen unserer Infrastruktur und Dritter zu verhindern.

Wiederherstellungsarbeiten an nicht gemanagten Umgebungen außerhalb unserer regulären Geschäftszeiten, an Wochenenden oder Feiertagen sind von der Schwere des Vorfalls und der Verfügbarkeit abhängig. Wenn keine sofortige Intervention erforderlich ist, können die Wiederherstellungsarbeiten ab dem nächsten Werktag aufgenommen werden.

Managed Hosting von Vservs

Die Absicherung eines geschäftskritischen CMS umfasst mehr als die Verwaltung des zugrunde liegenden Servers. Auch TYPO3 Core, Extensions, Administrator-Konten und aktuelle Security Advisories müssen regelmäßig überprüft werden.

Vservs bietet Managed Hosting und Managed Server für geschäftskritische Websites und CMS-Umgebungen mit Serververwaltung, Monitoring, Sicherheitswartung und technischer Betreuung.

Kontaktieren Sie Vservs, wenn Sie eine Managed-Lösung für Ihre TYPO3- oder eine andere CMS-Umgebung besprechen möchten.

Quellen

WooCommerce Sicherheitslücke CVE-2026-48888 Denial of Service

WooCommerce Sicherheitslücke CVE-2026-48888 kann Onlineshops lahmlegen

Eine neue WooCommerce Sicherheitslücke kann von einem Angreifer ausgenutzt werden, um einen WordPress-Onlineshop über das Internet unerreichbar zu machen.

Die Sicherheitslücke wird als CVE-2026-48888 geführt und hat einen CVSS-Score von 7.5 (High). Für einen Angriff sind weder ein WordPress-Benutzerkonto noch andere Zugangsdaten oder eine Benutzerinteraktion erforderlich.

WooCommerce-Versionen vor 11.1.0 sind betroffen. Die Sicherheitslücke wurde in WooCommerce 11.1.0 behoben.

Betreiber von WooCommerce-Onlineshops sollten deshalb die aktuell installierte Version überprüfen und betroffene Installationen auf mindestens WooCommerce 11.1.0 aktualisieren.

WooCommerce Sicherheitslücke CVE-2026-48888

CVE-2026-48888 betrifft eine unzureichende Begrenzung des Verbrauchs von Systemressourcen innerhalb von WooCommerce. Die Sicherheitslücke wird unter CWE-770: Allocation of Resources Without Limits or Throttling eingeordnet.

Ein externer Angreifer kann speziell präparierte HTTP-Anfragen an eine verwundbare WooCommerce-Installation senden und dadurch einen übermäßig hohen Verbrauch von Systemressourcen verursachen.

Die Folge kann ein Denial of Service (DoS) sein. Der Onlineshop reagiert dann sehr langsam oder ist für reguläre Besucher und Kunden vollständig nicht mehr erreichbar.

Die wichtigsten Informationen

  • Produkt: WooCommerce für WordPress
  • Hersteller: Automattic
  • CVE: CVE-2026-48888
  • Schweregrad: High
  • CVSS: 7.5
  • CWE: CWE-770 – Allocation of Resources Without Limits or Throttling
  • Typ: HTTP Denial of Service
  • Betroffene Versionen: WooCommerce vor Version 11.1.0
  • Gepatchte Version: WooCommerce 11.1.0 und neuer
  • Authentifizierung erforderlich: Nein
  • Benutzerinteraktion erforderlich: Nein
  • Exploit-Status: Zum Zeitpunkt der Veröffentlichung keine bestätigte aktive Ausnutzung bekannt
  • CISA KEV: Zum Zeitpunkt der Veröffentlichung nicht gelistet
  • Erforderliche Maßnahme: WooCommerce auf mindestens Version 11.1.0 aktualisieren

Warum ist diese Sicherheitslücke relevant?

WooCommerce ist für viele Unternehmen ein geschäftskritischer Bestandteil ihrer Website. Wird ein Onlineshop durch einen Denial-of-Service-Angriff unerreichbar, können Besucher keine Produkte aufrufen, Warenkörbe verwenden oder Bestellungen abschließen.

Laut dem veröffentlichten CVSS-Vektor hat CVE-2026-48888 keine direkte Auswirkung auf die Vertraulichkeit oder Integrität von Daten. Das primäre Risiko betrifft die Verfügbarkeit des Onlineshops.

Diese Unterscheidung ist wichtig: Nach den derzeit verfügbaren Informationen handelt es sich nicht um eine Remote-Code-Execution-Sicherheitslücke und ein Angreifer erhält dadurch nicht automatisch Zugriff auf WordPress oder WooCommerce.

Angriff ohne WordPress-Konto möglich

Die Sicherheitslücke ist über das Netzwerk erreichbar und erfordert keine Authentifizierung.

Der veröffentlichte CVSS-Vektor lautet:

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

Daraus geht hervor, dass der Angriff über das Netzwerk durchgeführt werden kann, eine geringe Angriffskomplexität aufweist, keine Benutzerrechte benötigt und keine Benutzerinteraktion voraussetzt.

Die Auswirkung auf die Verfügbarkeit wird als High eingestuft.

WooCommerce auf mindestens Version 11.1.0 aktualisieren

Alle WooCommerce-Versionen vor 11.1.0 fallen in den veröffentlichten betroffenen Versionsbereich.

WooCommerce 11.1.0 wird als nicht betroffen geführt.

Administratoren sollten deshalb überprüfen, welche WooCommerce-Version tatsächlich aktiv ist, und eine verwundbare Installation auf mindestens Version 11.1.0 oder eine neuere unterstützte Version aktualisieren.

Bei geschäftskritischen Onlineshops sollte vor dem Update ein verwendbares Backup erstellt werden. Nach der Aktualisierung sollten mindestens Produktseiten, Warenkorb, Checkout, Zahlungsmethoden sowie vorhandene individuelle Anpassungen und WooCommerce-Erweiterungen getestet werden.

Keine bestätigte aktive Ausnutzung

Zum Zeitpunkt der Veröffentlichung gibt es keine zuverlässige Bestätigung, dass CVE-2026-48888 aktiv in freier Wildbahn ausgenutzt wird.

Die Sicherheitslücke wurde am 8. September 2026 veröffentlicht. Zum Zeitpunkt dieser Veröffentlichung wurde in den überprüften Quellen keine bestätigte aktive Ausnutzung festgestellt und CVE-2026-48888 ist nicht im CISA Known Exploited Vulnerabilities Catalog aufgeführt.

Dies bedeutet jedoch nicht, dass verwundbare WooCommerce-Installationen nicht aktualisiert werden müssen. Für einen Angriff ist keine Authentifizierung erforderlich und ein Sicherheitsupdate steht zur Verfügung.

Auf ungewöhnliche Serverlast achten

Für CVE-2026-48888 wurden zum Zeitpunkt der Veröffentlichung keine zuverlässigen spezifischen Indicators of Compromise oder schädlichen IP-Adressen veröffentlicht.

IP-Adressen sollten deshalb nicht aufgrund unbestätigter Informationen pauschal blockiert werden.

Bei unerwarteten Performanceproblemen einer verwundbaren WooCommerce-Installation können Administratoren unter anderem auf folgende Auffälligkeiten achten:

  • plötzlich stark erhöhte Anzahl von HTTP-Anfragen;
  • große Mengen ähnlicher Anfragen an WooCommerce-Funktionen;
  • ungewöhnlich viele PHP-FPM-Prozesse;
  • deutlich erhöhte CPU- oder Speicherauslastung;
  • lang laufende PHP-Prozesse;
  • unerwartet hohe Datenbanklast;
  • HTTP-Fehler 502, 503 oder 504 während hoher Last;
  • auffällige Muster in Webserver-Access- und Error-Logs;
  • WAF- oder Rate-Limit-Warnungen im gleichen Zeitraum.

Diese Anzeichen beweisen für sich allein keine Ausnutzung von CVE-2026-48888. Vergleichbare Symptome können auch durch legitimen Traffic, Bots, fehlerhafte Plugins oder andere technische Probleme verursacht werden.

Rate Limiting als zusätzlicher Schutz

Rate Limiting auf Webserver-, Reverse-Proxy-, CDN- oder WAF-Ebene kann dabei helfen, die Auswirkungen automatisierter HTTP-Angriffe zu begrenzen.

Solche Maßnahmen müssen sorgfältig konfiguriert werden. Zu aggressive Limits können auch reguläre Besucher, API-Integrationen, Zahlungsanbieter oder andere WooCommerce-Funktionen beeinträchtigen.

Rate Limiting ist außerdem kein Ersatz für das Sicherheitsupdate. Die primäre Maßnahme gegen CVE-2026-48888 ist die Aktualisierung auf WooCommerce 11.1.0 oder neuer.

Zusätzliche Auswirkungen auf Shared-Hosting-Umgebungen

Ein Resource-Exhaustion-Angriff muss sich nicht ausschließlich auf den angegriffenen Onlineshop auswirken.

Wenn mehrere Websites Ressourcen auf demselben Server gemeinsam nutzen, kann eine extreme CPU-, Speicher-, PHP- oder Datenbankauslastung unter bestimmten Umständen auch andere Websites auf derselben Infrastruktur beeinträchtigen.

Dies ist einer der Gründe, warum Vservs bei ungewöhnlicher Ressourcenauslastung oder Angriffen aktiv eingreifen kann, um die Stabilität der Hosting-Infrastruktur zu schützen.

Verantwortung für CMS-Updates

Kunden ohne Managed WordPress/CMS-Wartung oder einen separaten Managed-CMS-Service sind selbst dafür verantwortlich, WordPress, WooCommerce, andere CMS-Systeme, Plugins, Erweiterungen und Themes rechtzeitig zu aktualisieren.

Wenn eine Website durch Missbrauch, Malware oder nachweisbar überfällige Wartung ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betroffene Website oder den entsprechenden Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weitere Schäden, Missbrauch oder Störungen unserer Infrastruktur und Dienste zu verhindern.

Wiederherstellungsarbeiten an nicht verwalteten Umgebungen außerhalb unserer regulären Geschäftszeiten, an Wochenenden oder Feiertagen hängen von der Schwere des Vorfalls und unserer Verfügbarkeit ab. Wenn kein sofortiges Eingreifen erforderlich ist, können die Wiederherstellungsarbeiten ab dem nächsten Werktag durchgeführt werden.

Managed WordPress von Vservs

WooCommerce-Onlineshops verwenden neben WordPress Core häufig zahlreiche Plugins, Zahlungsmodule, Versandlösungen und weitere Erweiterungen. Eine rechtzeitige technische Wartung ist deshalb sowohl für die Sicherheit als auch für die Verfügbarkeit wichtig.

Bei Managed WordPress von Vservs werden relevante Sicherheitsupdates, technische Wartung, Monitoring und Kontrollen im Rahmen der vereinbarten Managed-Dienstleistung von uns übernommen.

Wenn Sie die technische Wartung und Sicherheitsupdates Ihrer geschäftlichen WordPress- oder WooCommerce-Umgebung nicht selbst durchführen möchten, informieren Sie sich über unsere Managed-WordPress-Lösungen.

Quellen

Magento StyleSmuggler Zero-Day wird aktiv ausgenutzt

Kritische Magento StyleSmuggler Zero-Day wird aktiv ausgenutzt

Die Magento StyleSmuggler Zero-Day wird derzeit aktiv gegen Magento- und Adobe-Commerce-Onlineshops ausgenutzt. Die kritische Schwachstelle ermöglicht es Angreifern, schädliche Inhalte über GraphQL-Anfragen in Magento einzuschleusen und anschließend Code auf dem Server auszuführen. Die ersten Angriffe wurden Anfang September 2026 entdeckt.

Betreiber von Magento-2- und Adobe-Commerce-Umgebungen sollten ihre Systeme unverzüglich kontrollieren. Besonders wichtig: Auffällige E-Mails mit fehlgeschlagenen PayPal-Transaktionen können im Zusammenhang mit einem Angriff stehen, sind für sich allein jedoch kein Beweis für eine erfolgreiche Kompromittierung.

Was ist Magento StyleSmuggler?

StyleSmuggler ist die Bezeichnung für eine Angriffsmethode gegen Magento 2 und Adobe Commerce. Die Angreifer missbrauchen dabei GraphQL-Funktionen und manipulierte Style-Daten, um schädliche Inhalte in die Magento-Umgebung einzuschleusen.

Der Angriff ist besonders gefährlich, weil die eingeschleusten Daten zunächst unauffällig erscheinen können und erst bei der späteren Verarbeitung innerhalb von Magento ihre schädliche Wirkung entfalten.

Die wichtigsten Informationen

  • Produkt: Magento 2 / Adobe Commerce
  • Bezeichnung: StyleSmuggler
  • Typ: Zero-Day / Code Injection
  • Mögliche Folge: Remote Code Execution und vollständige Kompromittierung des Onlineshops
  • Angriffsweg: manipulierte GraphQL-Anfragen
  • Exploit-Status: aktive Angriffe beobachtet
  • Erste beobachtete Angriffe: 4. September 2026
  • Öffentliche Bekanntgabe: 5. September 2026
  • Maßnahme: Magento-Umgebung unverzüglich überprüfen und verfügbare Sicherheitsmaßnahmen anwenden

Warum ist StyleSmuggler kritisch?

Ein erfolgreicher Angriff kann es einem Angreifer ermöglichen, eigenen Code innerhalb der Magento-Umgebung auszuführen.

Dadurch kann ein Angreifer unter anderem:

  • Malware oder Webshells installieren;
  • Magento- und PHP-Dateien verändern;
  • Kunden- und Bestelldaten auslesen;
  • Checkout- oder Zahlungsprozesse manipulieren;
  • Administratorkonten oder andere Zugänge einrichten;
  • JavaScript-Skimmer installieren;
  • Cronjobs oder andere Persistenzmechanismen einrichten;
  • versuchen, weiteren Zugriff auf die Serverumgebung zu erhalten.

PayPal-Fehlermeldungen können ein Hinweis sein

Ein auffälliges Merkmal der beobachteten StyleSmuggler-Angriffe ist, dass Magento gezielt dazu gebracht werden kann, die E-Mail „Payment Transaction Failed Reminder“ zu erzeugen.

Dadurch können Shopbetreiber unerwartete Meldungen über fehlgeschlagene PayPal-Transaktionen erhalten.

Eine solche E-Mail ist jedoch kein Beweis dafür, dass ein Shop kompromittiert wurde. Sie sollte vielmehr als möglicher Indikator betrachtet werden, der eine weitere technische Untersuchung rechtfertigt.

Auch wenn die betreffende E-Mail aufgrund einer fehlerhaften Mailkonfiguration oder aus anderen Gründen nicht zugestellt wird, kann der eigentliche Angriff trotzdem erfolgreich gewesen sein.

Was sollten Sie jetzt tun?

  1. Überprüfen Sie öffentlich erreichbare Magento-2- und Adobe-Commerce-Installationen.
  2. Kontrollieren Sie Webserver-Logs auf verdächtige GraphQL-Anfragen.
  3. Prüfen Sie insbesondere Anfragen an /graphql mit ungewöhnlichen styles-Parametern.
  4. Kontrollieren Sie kürzlich erstellte oder veränderte PHP-, PHTML- und JavaScript-Dateien.
  5. Überprüfen Sie laufende Prozesse und Cronjobs auf unbekannte Einträge.
  6. Kontrollieren Sie Magento-Administratorkonten auf unbekannte Benutzer.
  7. Überprüfen Sie Checkout- und Zahlungsdateien auf Manipulationen.
  8. Sichern Sie relevante Logs und andere Spuren, bevor verdächtige Komponenten entfernt werden.

Technische Hinweise auf einen StyleSmuggler-Angriff

Bei den beobachteten Angriffen wurden verschiedene Indicators of Compromise (IoCs) festgestellt. Das Vorhandensein eines einzelnen Indikators beweist nicht automatisch eine Kompromittierung, sollte jedoch untersucht werden.

  • ungewöhnliche POST-Anfragen an /graphql;
  • GraphQL-Anfragen mit verdächtigen styles-Parametern;
  • ein verdächtiger Prozess mit einer Bezeichnung ähnlich [kworker/u:8:0];
  • eine verdächtige Datei beziehungsweise ein Prozess unter ~/.local/share/.gvfsd/gvfsd-user;
  • unbekannte Cronjobs, die beispielsweise alle fünf Minuten ausgeführt werden;
  • unerwartete Änderungen an Magento-, PHP- oder JavaScript-Dateien.

Nach einer Kompromittierung reicht ein Patch nicht aus

Wenn ein Angreifer bereits Code auf dem Magento-System ausgeführt hat, reicht das spätere Schließen der ursprünglichen Schwachstelle nicht aus.

Angreifer können Webshells, zusätzliche Benutzerkonten, Cronjobs, manipulierte PHP-Dateien oder andere Persistenzmechanismen eingerichtet haben.

Bei einer bestätigten Kompromittierung sollten relevante Zugangsdaten und Secrets überprüft und gegebenenfalls ersetzt werden. Dazu gehören Magento-Administratorkonten, Datenbank-Zugangsdaten, API-Schlüssel, Integrations-Tokens und Zugangsdaten zu angebundenen Diensten.

Bei einem Onlineshop sollte außerdem besonders sorgfältig geprüft werden, ob Checkout- oder Zahlungsprozesse manipuliert wurden.

Verantwortung für Magento-Updates und Sicherheit

Kunden ohne Managed-Magento- beziehungsweise Managed-CMS-Wartung sind selbst dafür verantwortlich, Magento, Adobe Commerce, Erweiterungen, Themes und andere Komponenten rechtzeitig zu aktualisieren und verfügbare Sicherheitsmaßnahmen anzuwenden.

Wenn ein Onlineshop aufgrund von Missbrauch, Malware oder nachweislich überfälliger Wartung ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betreffende Website oder den Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weitere Schäden, Missbrauch oder die Verbreitung von Malware zu verhindern.

Vservs kann Magento-Umgebungen untersuchen

Bei einer kritischen Magento-Sicherheitsmeldung ist nicht nur die Installation eines Updates wichtig. Wenn eine Umgebung während eines aktiven Angriffs verwundbar und öffentlich erreichbar war, sollte zusätzlich untersucht werden, ob bereits eine Kompromittierung stattgefunden hat.

Vservs kann Magento- und Serverumgebungen technisch untersuchen, Logs und verdächtige Dateien kontrollieren und bei der Absicherung oder Wiederherstellung unterstützen.

Für einen sicheren und professionell betreuten Serverbetrieb bietet Vservs außerdem Managed VPS Hosting für anspruchsvolle Websites, Onlineshops und Unternehmensanwendungen.

Quellen

Magento Schwachstelle CVE-2026-75650 aktiv ausgenutzt

Kritische Magento Schwachstelle CVE-2026-75650 wird aktiv ausgenutzt

Eine kritische Sicherheitslücke in Adobe Commerce und Magento Open Source wird aktiv von Angreifern ausgenutzt. Die als CVE-2026-75650 registrierte Schwachstelle kann zur Ausführung von Schadcode auf betroffenen Magento-Systemen führen. Adobe bewertet die Sicherheitslücke mit einem CVSS-Score von 10.0 und damit mit der höchstmöglichen Kritikalitätsstufe.

Betreiber von Magento- und Adobe-Commerce-Onlineshops sollten deshalb unverzüglich prüfen, ob ihre Umgebung betroffen ist, den verfügbaren Sicherheitsfix installieren und Systeme, die während des gefährdeten Zeitraums öffentlich erreichbar waren, zusätzlich auf eine mögliche Kompromittierung untersuchen.

Magento Schwachstelle CVE-2026-75650

Die Schwachstelle betrifft Adobe Commerce und Magento Open Source und steht im Zusammenhang mit der Verarbeitung von Templates. Unter bestimmten Voraussetzungen kann ein Angreifer manipulierte Eingaben einschleusen und dadurch die Ausführung von nicht vorgesehenem Code erreichen.

Da Magento-Onlineshops geschäftskritische Daten verarbeiten und häufig direkt mit Zahlungs-, Kunden- und Bestellsystemen verbunden sind, kann eine erfolgreiche Ausnutzung erhebliche Auswirkungen haben.

Die wichtigsten Informationen

  • Produkt: Adobe Commerce / Magento Open Source
  • CVE: CVE-2026-75650
  • Adobe Bulletin: APSB26-146
  • Schweregrad: Critical
  • CVSS: 10.0
  • Typ: Template Injection / Remote Code Execution
  • Mögliche Folge: vollständige Kompromittierung des Onlineshops
  • Exploit-Status: aktive Ausnutzung beobachtet
  • Maßnahme: Sicherheitsfix unverzüglich installieren und Umgebung kontrollieren

Warum ist diese Magento Schwachstelle kritisch?

Remote Code Execution gehört zu den schwerwiegendsten Sicherheitsproblemen für einen öffentlich erreichbaren Webshop. Gelingt die Ausnutzung, kann ein Angreifer eigenen Code innerhalb der betroffenen Umgebung ausführen.

Abhängig von der Magento- und Serverkonfiguration kann ein Angreifer anschließend unter anderem:

  • Magento-Dateien verändern;
  • Malware oder Webshells installieren;
  • Kunden- und Bestelldaten auslesen;
  • Zahlungsprozesse manipulieren;
  • Administratorkonten oder andere Zugänge einrichten;
  • Checkout-Seiten manipulieren oder Skimming-Code installieren;
  • Cronjobs und andere Persistenzmechanismen einrichten;
  • versuchen, zusätzlichen Zugriff auf die Serverumgebung zu erhalten.

CVE-2026-75650 wird aktiv ausgenutzt

Besonders wichtig ist, dass es sich nicht lediglich um eine theoretische Schwachstelle handelt. Es wurden aktive Angriffe auf Magento- und Adobe-Commerce-Umgebungen beobachtet.

Öffentlich erreichbare Magento-Systeme sollten deshalb nicht nur gepatcht werden. Wenn eine betroffene Installation vor der Installation des Sicherheitsfixes erreichbar war, sollte zusätzlich überprüft werden, ob bereits ein Angriff stattgefunden hat.

Adobe Sicherheitsfix VULN-39341

Adobe hat für die Schwachstelle Sicherheitsinformationen und den Hotfix VULN-39341 veröffentlicht. Betreiber betroffener Adobe-Commerce- und Magento-Open-Source-Installationen sollten den für ihre Umgebung vorgesehenen Sicherheitsfix unverzüglich anwenden.

Nach der Installation sollte technisch überprüft werden, ob der Patch korrekt angewendet wurde und ob die produktive Magento-Umgebung tatsächlich geschützt ist.

Was sollten Sie jetzt tun?

  1. Überprüfen Sie die eingesetzte Magento- beziehungsweise Adobe-Commerce-Version.
  2. Prüfen Sie anhand der Adobe-Sicherheitsinformationen, ob Ihre Installation betroffen ist.
  3. Installieren Sie den verfügbaren Sicherheitsfix beziehungsweise Hotfix VULN-39341 unverzüglich.
  4. Kontrollieren Sie anschließend, ob der Patch erfolgreich angewendet wurde.
  5. Überprüfen Sie öffentlich erreichbare betroffene Systeme auf Hinweise auf eine Kompromittierung.
  6. Sichern Sie relevante Logs, bevor verdächtige Dateien oder Prozesse entfernt werden.

Magento auf eine mögliche Kompromittierung prüfen

Aufgrund der aktiven Ausnutzung empfehlen wir bei zuvor verwundbaren Installationen eine zusätzliche technische Untersuchung.

  • Überprüfen Sie kürzlich erstellte oder veränderte PHP-, PHTML- und JavaScript-Dateien.
  • Kontrollieren Sie Magento-Administratorkonten auf unbekannte Benutzer.
  • Überprüfen Sie Module und Themes auf unerwartete Änderungen.
  • Kontrollieren Sie Webserver- und PHP-Logs auf ungewöhnliche Requests und Fehler.
  • Überprüfen Sie Magento-Cronjobs und Server-Crontabs auf unbekannte Aufgaben.
  • Kontrollieren Sie laufende Prozesse auf ungewöhnliche oder unbekannte Prozesse.
  • Überprüfen Sie Webverzeichnisse und temporäre Verzeichnisse auf Webshells oder andere verdächtige Dateien.
  • Kontrollieren Sie Checkout- und Zahlungsdateien auf unbekannten JavaScript-Code oder andere Manipulationen.
  • Überprüfen Sie verfügbare WAF-, Malware- und Sicherheitslogs.

Nach einer Kompromittierung reicht der Patch nicht aus

Wenn ein Angreifer die Schwachstelle bereits erfolgreich ausgenutzt hat, entfernt die Installation des Sicherheitsfixes keine zuvor installierten Backdoors oder andere Veränderungen.

Ein Angreifer kann zusätzliche PHP-Dateien, Webshells, Benutzerkonten, Cronjobs oder andere Persistenzmechanismen eingerichtet haben.

Bei einer bestätigten Kompromittierung sollten relevante Zugangsdaten und Secrets überprüft und gegebenenfalls ersetzt werden. Dazu können Magento-Administratorkonten, Datenbank-Zugangsdaten, API-Schlüssel, Integrations-Tokens und Zugangsdaten zu angebundenen Diensten gehören.

Bei Onlineshops sollte außerdem besonders sorgfältig geprüft werden, ob Checkout- oder Zahlungsprozesse manipuliert wurden.

Verantwortung für Magento-Updates

Kunden ohne Managed-Magento- beziehungsweise Managed-CMS-Wartung sind selbst dafür verantwortlich, Magento, Adobe Commerce, Erweiterungen, Themes und andere Komponenten rechtzeitig zu aktualisieren und verfügbare Sicherheitsfixes zu installieren.

Wenn ein Onlineshop aufgrund von Missbrauch, Malware oder nachweislich überfälliger Wartung ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betreffende Website oder den Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weitere Schäden, Missbrauch oder die Verbreitung von Malware zu verhindern.

Managed VPS Hosting von Vservs

Kritische Magento-Schwachstellen wie CVE-2026-75650 zeigen, dass die Sicherheit eines Onlineshops nicht ausschließlich von Magento selbst abhängt. Auch Betriebssystem, PHP, Datenbank, Webserver und die technische Serverkonfiguration müssen kontinuierlich gepflegt werden.

Mit Managed Hosting von Vservs können Unternehmen den technischen Betrieb ihrer Serverumgebung durch Vservs betreuen lassen.

Benötigen Sie Unterstützung bei der Installation des Magento-Sicherheitsfixes oder möchten Sie prüfen lassen, ob Ihr Onlineshop bereits kompromittiert wurde? Vservs kann die Umgebung technisch untersuchen und bei der Absicherung oder Wiederherstellung unterstützen.

Quellen

Elementor Pro Schwachstelle CVE-2026-32475 aktiv ausgenutzt

Kritische Elementor Pro Schwachstelle CVE-2026-32475 wird aktiv ausgenutzt

Eine kritische Sicherheitslücke in Elementor Pro wird derzeit aktiv von Angreifern ausgenutzt. Die als CVE-2026-32475 registrierte Schwachstelle kann es Angreifern ermöglichen, schädliche Dateien auf eine WordPress-Website hochzuladen und dadurch unter bestimmten Voraussetzungen Schadcode auf dem Server auszuführen.

Aufgrund der aktiven Ausnutzung sollten Betreiber von WordPress-Websites mit Elementor Pro unverzüglich überprüfen, welche Version installiert ist, das Plugin aktualisieren und anfällige Installationen zusätzlich auf Hinweise auf eine mögliche Kompromittierung untersuchen.

Elementor Pro Schwachstelle CVE-2026-32475

Elementor Pro ist die kommerzielle Erweiterung des weit verbreiteten Elementor Page Builders für WordPress. Das Plugin bietet zusätzliche Widgets, Formulare, dynamische Inhalte und weitere Funktionen zur Erstellung und Verwaltung von Websites.

Die Schwachstelle ermöglicht unter bestimmten Voraussetzungen das Hochladen von Dateien, die normalerweise nicht akzeptiert werden sollten. Gelingt es einem Angreifer, eine ausführbare PHP-Datei auf dem Server abzulegen und anschließend aufzurufen, kann dies zur Ausführung von Schadcode führen.

Die wichtigsten Informationen

  • Produkt: Elementor Pro
  • CVE: CVE-2026-32475
  • Schweregrad: Critical
  • Typ: Arbitrary File Upload
  • Mögliche Folge: Remote Code Execution
  • Betroffene Versionen: bis einschließlich 4.2.1
  • Gepatchte Version: 4.2.2 oder neuer
  • Exploit-Status: aktive Ausnutzung beobachtet
  • Maßnahme: unverzüglich aktualisieren und Website kontrollieren

Warum ist diese Schwachstelle kritisch?

Eine Schwachstelle, über die ausführbare Dateien auf eine Website hochgeladen werden können, kann weitreichende Folgen haben. Nach erfolgreicher Ausnutzung kann ein Angreifer versuchen, die Kontrolle über die WordPress-Installation zu übernehmen.

Abhängig von der Konfiguration kann ein Angreifer anschließend unter anderem:

  • Malware oder Webshells installieren;
  • WordPress-Dateien verändern;
  • zusätzliche Administratorkonten erstellen;
  • Plugins oder Themes manipulieren;
  • Daten aus der Website oder Datenbank auslesen;
  • Besucher auf schädliche Websites umleiten;
  • Spam- oder Phishing-Seiten installieren;
  • weitere Backdoors oder Persistenzmechanismen einrichten.

Elementor Pro wird aktiv angegriffen

Besonders wichtig ist, dass es sich nicht nur um eine theoretische Sicherheitslücke handelt. Sicherheitsforscher haben aktive Exploit-Versuche gegen verwundbare Elementor-Pro-Installationen beobachtet.

Websites, auf denen eine betroffene Elementor-Pro-Version öffentlich erreichbar war, sollten deshalb nicht ausschließlich aktualisiert werden. Zusätzlich sollte kontrolliert werden, ob die Schwachstelle möglicherweise bereits ausgenutzt wurde.

Was sollten Sie jetzt tun?

  1. Überprüfen Sie alle WordPress-Websites, auf denen Elementor Pro installiert ist.
  2. Kontrollieren Sie die tatsächlich installierte Plugin-Version.
  3. Aktualisieren Sie Elementor Pro unverzüglich auf Version 4.2.2 oder eine neuere sichere Version.
  4. Überprüfen Sie nach dem Update, ob die neue Version tatsächlich aktiv ist.
  5. Kontrollieren Sie kürzlich hochgeladene und veränderte Dateien.
  6. Überprüfen Sie die Website zusätzlich auf Hinweise auf eine mögliche Kompromittierung.

Wenn Elementor Pro nicht mehr benötigt wird, sollte eine veraltete Installation nicht deaktiviert auf der Website verbleiben, sondern vollständig entfernt werden.

Auf mögliche Kompromittierung prüfen

Da aktive Angriffe beobachtet werden, empfehlen wir bei Websites, auf denen eine anfällige Version installiert war, eine zusätzliche Sicherheitskontrolle.

  • Überprüfen Sie Upload-Verzeichnisse auf unbekannte PHP-, PHTML- oder andere ausführbare Dateien.
  • Kontrollieren Sie kürzlich erstellte oder veränderte PHP-Dateien.
  • Überprüfen Sie WordPress-Benutzer auf unbekannte Administratorkonten.
  • Kontrollieren Sie Plugins und Themes auf unerwartete Änderungen oder Ergänzungen.
  • Überprüfen Sie Webserver-Logs auf ungewöhnliche POST- und Upload-Anfragen.
  • Kontrollieren Sie WordPress-Cron und Server-Crontabs auf unbekannte Aufgaben.
  • Überprüfen Sie verfügbare Malware-, WAF- und Sicherheitslogs.

Nach einem erfolgreichen Angriff reicht ein Update nicht aus

Wenn ein Angreifer bereits eine schädliche Datei hochgeladen und ausgeführt hat, wird diese durch ein Update von Elementor Pro nicht automatisch entfernt.

Ein Angreifer kann zusätzliche Backdoors, PHP-Dateien, Administratorkonten, Plugins oder Cronjobs eingerichtet haben, um den Zugriff dauerhaft aufrechtzuerhalten.

Sichern Sie relevante Logs und andere Spuren, bevor verdächtige Dateien oder Benutzerkonten entfernt werden.

Bei einer bestätigten Kompromittierung sollten relevante Zugangsdaten geändert und bestehende WordPress-Sitzungen ungültig gemacht werden. Dazu gehören je nach Vorfall WordPress-Passwörter, Datenbank-Zugangsdaten, API-Schlüssel und weitere sicherheitsrelevante Zugangsdaten.

Verantwortung für CMS-Updates

Kunden ohne Managed WordPress/CMS-Wartung oder einen separaten Managed-CMS-Service sind selbst dafür verantwortlich, WordPress, andere CMS-Software, Plugins, Erweiterungen und Themes rechtzeitig zu aktualisieren.

Wenn eine Website aufgrund von Missbrauch, Malware oder nachweislich überfälliger Wartung ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betreffende Website oder den Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weitere Schäden, Missbrauch oder die Verbreitung von Malware zu verhindern.

Wiederherstellungsarbeiten an nicht verwalteten Umgebungen außerhalb unserer regulären Geschäftszeiten, an Wochenenden oder Feiertagen sind von der Schwere des Vorfalls und unserer Verfügbarkeit abhängig. Wenn kein sofortiges Eingreifen erforderlich ist, können Wiederherstellungsarbeiten ab dem nächsten Werktag durchgeführt werden.

Managed WordPress von Vservs

Aktiv ausgenutzte Schwachstellen wie CVE-2026-32475 zeigen, warum WordPress-Plugins kontinuierlich überwacht und Sicherheitsupdates zeitnah installiert werden sollten.

Bei Managed WordPress von Vservs werden relevante Sicherheitsupdates, technische Wartungsarbeiten und Kontrollen im Rahmen der vereinbarten Managed-Dienstleistung von uns durchgeführt.

Möchten Sie die technische Wartung und Sicherheitsupdates Ihrer WordPress-Umgebung nicht selbst durchführen? Dann informieren Sie sich über unsere Managed-WordPress-Lösungen.

Quellen

Ninja Forms File Uploads Schwachstelle CVE-2026-0740

Kritische Ninja Forms File Uploads Schwachstelle CVE-2026-0740

Im WordPress-Plugin Ninja Forms File Uploads wurde eine kritische Sicherheitslücke entdeckt. Die als CVE-2026-0740 registrierte Schwachstelle ermöglicht unter bestimmten Voraussetzungen das Hochladen beliebiger Dateien ohne Authentifizierung. Dadurch kann ein Angreifer Schadcode auf einer WordPress-Website platzieren und möglicherweise Remote Code Execution erreichen.

Websites, auf denen eine anfällige Version von Ninja Forms File Uploads installiert ist, sollten daher unverzüglich aktualisiert werden. Da ein erfolgreicher Angriff weitreichenden Zugriff auf die Website ermöglichen kann, empfehlen wir zusätzlich eine Kontrolle auf mögliche Hinweise auf eine Kompromittierung.

Ninja Forms File Uploads Schwachstelle CVE-2026-0740

Ninja Forms File Uploads erweitert Ninja Forms um Funktionen zum Hochladen und Verarbeiten von Dateien über WordPress-Formulare.

Die Schwachstelle betrifft die Validierung hochgeladener Dateien. Unter bestimmten Umständen kann ein nicht authentifizierter Angreifer die vorgesehenen Sicherheitsprüfungen umgehen und Dateien mit gefährlichen Dateitypen auf den Server hochladen.

Kann eine hochgeladene PHP-Datei anschließend über den Webserver aufgerufen werden, kann dies zur Ausführung von Schadcode auf dem Server führen.

Die wichtigsten Informationen

  • Produkt: Ninja Forms File Uploads
  • CVE: CVE-2026-0740
  • Schweregrad: Critical
  • Typ: Unauthenticated Arbitrary File Upload
  • Mögliche Folge: Remote Code Execution
  • Authentifizierung erforderlich: nein
  • Betroffene Versionen: bis einschließlich 3.3.26
  • Gepatchte Version: 3.3.27 oder neuer
  • Maßnahme: unverzüglich aktualisieren

Warum ist diese Schwachstelle kritisch?

Für einen Angriff ist kein bestehendes WordPress-Benutzerkonto erforderlich. Ein Angreifer kann daher versuchen, eine öffentlich erreichbare Website direkt über das Internet anzugreifen.

Wenn es gelingt, eine ausführbare Datei auf den Server hochzuladen und anschließend aufzurufen, kann der Angreifer eigenen PHP-Code innerhalb der Website ausführen.

Abhängig von der Konfiguration kann ein erfolgreicher Angreifer anschließend unter anderem:

  • Malware oder Webshells installieren;
  • WordPress-Dateien verändern;
  • Administratorkonten erstellen;
  • Daten aus der WordPress-Datenbank auslesen;
  • Plugins oder Themes manipulieren;
  • Besucher auf schädliche Websites umleiten;
  • Spam- oder Phishing-Inhalte installieren;
  • weitere Persistenzmechanismen einrichten.

Was sollten Sie jetzt tun?

  1. Überprüfen Sie alle WordPress-Websites, auf denen Ninja Forms File Uploads installiert ist.
  2. Kontrollieren Sie die tatsächlich installierte Plugin-Version.
  3. Aktualisieren Sie das Plugin unverzüglich auf Version 3.3.27 oder eine neuere sichere Version.
  4. Überprüfen Sie nach dem Update, ob die neue Version tatsächlich aktiv ist.
  5. Kontrollieren Sie Upload-Verzeichnisse auf unbekannte oder verdächtige Dateien.
  6. Überprüfen Sie betroffene Websites zusätzlich auf Hinweise auf eine mögliche Kompromittierung.

Wenn ein sofortiges Update nicht möglich ist und die Upload-Funktion nicht zwingend benötigt wird, sollte die betreffende Erweiterung bis zur Installation einer sicheren Version deaktiviert werden.

Auf mögliche Kompromittierung prüfen

Da die Schwachstelle das Hochladen ausführbarer Dateien ermöglichen kann, empfehlen wir bei Websites, auf denen eine anfällige Version öffentlich erreichbar war, eine zusätzliche Sicherheitskontrolle.

  • Überprüfen Sie Upload-Verzeichnisse auf unbekannte PHP-, PHTML- oder andere ausführbare Dateien.
  • Kontrollieren Sie kürzlich erstellte oder veränderte PHP-Dateien.
  • Überprüfen Sie WordPress-Benutzer auf unbekannte Administratorkonten.
  • Kontrollieren Sie installierte Plugins und Themes auf unerwartete Änderungen.
  • Überprüfen Sie Webserver-Logs auf verdächtige Upload- und POST-Anfragen.
  • Kontrollieren Sie WordPress-Cron und Server-Crontabs auf unbekannte Aufgaben.
  • Überprüfen Sie verfügbare Malware-, WAF- und Sicherheitslogs.

Nach einem erfolgreichen Angriff reicht ein Update nicht aus

Wenn ein Angreifer bereits eine schädliche Datei hochgeladen und ausgeführt hat, entfernt ein nachträgliches Update des Plugins diese Datei nicht automatisch.

Der Angreifer kann zusätzliche Webshells, PHP-Dateien, Administratorkonten, Plugins oder Cronjobs eingerichtet haben, um seinen Zugriff aufrechtzuerhalten.

Sichern Sie relevante Logs und andere Spuren, bevor verdächtige Dateien oder Benutzerkonten entfernt werden.

Bei einer bestätigten Kompromittierung sollten relevante Zugangsdaten geändert und bestehende WordPress-Sitzungen ungültig gemacht werden. Dazu gehören je nach Vorfall WordPress-Passwörter, Datenbank-Zugangsdaten, API-Schlüssel und andere sicherheitsrelevante Zugangsdaten.

Verantwortung für CMS-Updates

Kunden ohne Managed WordPress/CMS-Wartung oder einen separaten Managed-CMS-Service sind selbst dafür verantwortlich, WordPress, andere CMS-Software, Plugins, Erweiterungen und Themes rechtzeitig zu aktualisieren.

Wenn eine Website aufgrund von Missbrauch, Malware oder nachweislich überfälliger Wartung ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betreffende Website oder den Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weitere Schäden, Missbrauch oder die Verbreitung von Malware zu verhindern.

Wiederherstellungsarbeiten an nicht verwalteten Umgebungen außerhalb unserer regulären Geschäftszeiten, an Wochenenden oder Feiertagen sind von der Schwere des Vorfalls und unserer Verfügbarkeit abhängig. Wenn kein sofortiges Eingreifen erforderlich ist, können Wiederherstellungsarbeiten ab dem nächsten Werktag durchgeführt werden.

Managed WordPress von Vservs

Kritische Schwachstellen wie CVE-2026-0740 zeigen, warum insbesondere WordPress-Erweiterungen mit Datei-Upload-Funktionen kontinuierlich überwacht und zeitnah aktualisiert werden sollten.

Bei Managed WordPress von Vservs werden relevante Sicherheitsupdates, technische Wartungsarbeiten und Kontrollen im Rahmen der vereinbarten Managed-Dienstleistung von uns durchgeführt.

Möchten Sie die technische Wartung und Sicherheitsupdates Ihrer WordPress-Umgebung nicht selbst durchführen? Dann informieren Sie sich über unsere Managed-WordPress-Lösungen.

Quellen