Sicherheitswarnung · Hoch
Magento-Shops durch schädliche Einbettung in CMS-Blöcken infiziert
· 2 Minuten Lesezeit · Centoculus Security Team
Bekannt seit · Angriffe bestätigt seit
Betroffen: Online-Shops, überwiegend Magento (Versionen nicht angegeben)
Was passiert ist
Am 26. Oktober 2026 haben Forschende eine Kampagne gemeldet, die 953 Online-Shops infiziert hat, die meisten davon mit Magento. Die Kampagne ist seit Juli 2025 aktiv. Die Angreifer liefern einen schädlichen JavaScript-Loader über CMS-Blöcke aus, also die Inhaltsschnipsel, die Magento auf Shopseiten einbindet. Das Skript wird als ausweichend beschrieben, es ist also darauf ausgelegt, einer Erkennung zu entgehen.
Da der Code in den Datenbankinhalten statt in den Anwendungsdateien liegt, kann er Code-Updates überdauern und wird bei dateibasierten Prüfungen leicht übersehen. Die Quelle nennt nicht, wie sich die Angreifer den Zugriff verschafft haben, der zum Ändern der CMS-Blöcke nötig war, und sie führt keine konkreten Magento-Versionen auf.
Wer betroffen ist
Betreiber von Online-Shops, insbesondere von Magento- und Adobe-Commerce-Shops. Agenturen, die mehrere Shops für Kunden betreuen, sollten jeden Shop prüfen, den sie pflegen. Ein Shop, der seit Mitte 2025 unbeaufsichtigt läuft, verdient besondere Aufmerksamkeit, da die Kampagne seitdem aktiv ist.
Was Sie jetzt tun sollten
- Sichern Sie die Datenbank, bevor Sie etwas ändern, damit Sie Nachweise behalten und bei Bedarf wiederherstellen können.
- Öffnen Sie im Magento-Admin unter Inhalte > Blöcke und prüfen Sie jeden Block, auch inaktive. Achten Sie auf
<script>-Tags, Verweise auf unbekannte externe Domains sowie verschleierten oder kodierten Code, den Sie nicht selbst hinzugefügt haben. - Prüfen Sie außerdem Inhalte > Widgets, Inhalte > Seiten sowie die Einstellungen für Kopf- und Fußbereich unter Inhalte > Design > Konfiguration, da eingeschleuste Skripte häufig auch dort platziert werden.
- Entfernen Sie jeden Code, den Sie keinem eigenen Team oder einer bekannten Erweiterung zuordnen können, leeren Sie anschließend den Magento-Cache (
bin/magento cache:flush) sowie einen vorgeschalteten Full-Page-Cache oder CDN-Cache. - Prüfen Sie System > Berechtigungen > Alle Benutzer. Entfernen Sie unbekannte Administratorkonten, setzen Sie die Passwörter aller übrigen Administratoren zurück und aktivieren Sie die Zwei-Faktor-Authentifizierung.
- Tauschen Sie Zugangsdaten aus, die möglicherweise offengelegt wurden: Datenbankpasswort, API-Integrationstoken und SSH/SFTP-Konten.
- Installieren Sie die aktuellen Sicherheitspatches für Magento oder Adobe Commerce und aktualisieren Sie alle Erweiterungen auf ihre neuesten Versionen.
- Beschränken Sie den Zugriff auf das Admin-Panel, zum Beispiel über eine IP-Allowlist oder einen nicht standardmäßigen Admin-Pfad, sofern Ihre Umgebung dies zulässt.
So prüfen Sie, ob Sie betroffen sind
- Durchsuchen Sie die Datenbank nach Skripten in CMS-Inhalten, zum Beispiel:
SELECT block_id, identifier, title, is_active, update_time
FROM cms_block
WHERE content LIKE '%<script%';
SELECT page_id, identifier, update_time
FROM cms_page
WHERE content LIKE '%<script%';
SELECT path, value
FROM core_config_data
WHERE path LIKE 'design/head/%' OR path LIKE 'design/footer/%';
Prüfen Sie jeden Treffer und dessen update_time. Änderungen seit Juli 2025, die niemand in Ihrem Team vorgenommen hat, sind verdächtig.
- Öffnen Sie den Shop in einem Browser mit aktivierten Entwicklerwerkzeugen und prüfen Sie den Netzwerk-Tab auf Anfragen an Domains, die Sie nicht kennen, insbesondere auf der Checkout-Seite.
- Prüfen Sie die Zugriffsprotokolle des Webservers auf Admin-Anmeldungen und POST-Anfragen an den Admin-Bereich von unbekannten IP-Adressen.
- Prüfen Sie, sofern in Ihrer Edition verfügbar, das Admin-Aktionsprotokoll auf Änderungen an CMS-Blöcken.
Wenn Sie eingeschleusten Code finden, gehen Sie davon aus, dass Kundendaten, die im Shop eingegeben wurden, offengelegt worden sein könnten, und erfüllen Sie Ihre Pflichten zur Reaktion auf Sicherheitsvorfälle und zum Datenschutz.
Quellen
Mehr zu Magento
Wenn du CMS oder Shopsysteme betreibst, prüf auch
- WordPress-Plugin-Sicherheitslücken: 5 Plugins, darunter LiteSpeed Cache
- WordPress-Plugin-Schwachstellen: 6 Plugins betroffen, darunter SureCart
- WordPress-Core-Race-Condition ermöglicht Angreifern Codeausführung während Updates, aktiv ausgenutzt
- WordPress-Update behebt Code-Injection-Schwachstelle, Angriffsversuche beobachtet
- Drupal Commerce Core unter aktiver Ausnutzung: Umgehung der Autorisierung (CVE-2026-118539)
- WordPress-Plugin-Schwachstellen: 19 Plugins, darunter W3 Total Cache
- WordPress-Plugin-Schwachstellen: 10 Plugins, darunter Welcart e-Commerce
- CryptoPayment-Gateway-WordPress-Plugin-Schwachstelle CVE-2026-81648 wird nun aktiv ausgenutzt
Weitere Beiträge
Sicherheitswarnungen ·
OpenSSH auf Alpine Linux: Anmeldung ohne Passwort durch überlange Passwörter
Auf Alpine-Linux-Servern mit dem Standardpaket openssh-server können Angreifer sich ohne Passwort bei Konten anmelden, etwa bei Konten, die nur mit SSH-Schlüsseln genutzt werden. OpenSSH 10.6p2 und aktualisierte Alpine-Pakete beheben das Problem.
Sicherheitswarnungen ·
APT-Lücke auf Debian und Ubuntu erlaubt Paketaustausch per MitM und Codeausführung als root
Eine Lücke in APT erlaubt einem Angreifer, der Paket-Downloads manipulieren kann, ein verifiziertes Paket zu ersetzen und Code als root auszuführen. Debian und Ubuntu haben am 4. November Sicherheitshinweise veröffentlicht. Aktualisieren Sie APT auf allen Servern.
Sicherheitswarnungen ·
Ruby on Rails Active Storage: kritische Schwachstelle beim Dateischreiben über ImageMagick-Uploads
Eine kritische Schwachstelle in Ruby on Rails Active Storage erlaubt nicht authentifizierten Angreifern, über einen präparierten Upload beliebige Dateien auf dem Server zu schreiben, wenn ImageMagick die Datei verarbeitet. Aktualisieren Sie auf Rails 8.1.4.1 oder 8.0.5.2.