Die Magento-2-Sicherheitslücke sorgt für Nacharbeit in vielen Shops. Ein betroffener Dienstleister hat den angegriffenen Shop forensisch ausgewertet und meldet sich mit Zahlen: 343 Backdoors, sechs Angreifer-IPs – und trotzdem kein einziger erfolgreicher Zugriff. Die Erkenntnisse sind für jeden Magento-Betreiber relevant.
Inhaltsverzeichnis
Fasse den Artikel im Bullet-Stil zusammen.
Zwei Backdoor-Typen im Einsatz
Insgesamt 343 Backdoor-Dateien wurden im Shop gefunden – 334 .php-Dateien und 9 .phtml-Dateien. Die Code-Analyse zeigt zwei klar unterschiedliche Varianten.
Typ 1 „cfg_ok_v3″ (rund 277 Dateien): Passwortgeschützt via MD5-Hash. Nutzt file_put_contents und move_uploaded_file – kann beliebige Dateien schreiben und weitere Backdoors nachladen.
Typ 2 „*index.php“ (rund 66 Dateien): Cookie-basierte Authentifizierung, und der entscheidende Unterschied: eval(base64_decode($_REQUEST["id"])). Das ist Full Remote Code Execution – beliebige PHP-Commands, kein Umweg. Dieser Typ ist deutlich gefährlicher.
Sechs verschiedene Angreifer-IPs wurden protokolliert, verteilt auf DigitalOcean, Vultr und weitere Hoster.
343 Backdoors, null erfolgreiche Zugriffe
Trotz der Backdoor-Welle: Kein einziger Request endete mit HTTP 200 auf eine der Schaddateien. Alle Zugriffe liefen auf 404 oder 301. Die wahrscheinliche Ursache: Der Shop-Admin läuft auf einer separaten Subdomain. Der Angreifer konnte die Dateien hochladen, aber den korrekten Web-Path zum Ausführen nicht ermitteln. Die echte Domain blieb unbekannt.
Das ist eine wichtige Erkenntnis: Upload und Ausführung sind zwei verschiedene Schritte. Wer seinen Admin isoliert, kappt den zweiten.
Was bisherige Empfehlungen nicht abdecken
Der Dienstleister identifiziert drei Lücken in den bisher kursierenden Schutzempfehlungen:
1. .phtml-Dateien werden vergessen. Der Apache-Block muss nicht nur .php blockieren, sondern auch .phtml:
<FilesMatch ".ph(p|tml)$">
Require all denied
</FilesMatch>2. Nicht nur custom_options betroffen. Backdoors tauchten auch in /pub/media/product-backgrounds/ auf. Empfehlung: Das gesamte /pub/media/-Verzeichnis härten, nicht nur den bekannten Unterordner.
3. Die bestehende .htaccess wird überschrieben. In custom_options/ liegt bereits eine .htaccess mit „Require all denied“ – sie wird vom Angriff ignoriert. Schutz muss auf VirtualHost-Ebene erfolgen, nicht per .htaccess.
Sofortmaßnahme: Apache VirtualHost-Config
Das funktioniert laut dem Dienstleister getestet: Selbst wenn die Backdoor hochgeladen wird, führt Apache sie nicht aus (403 Forbidden).
<Directory /var/www/PFAD/pub/media/custom_options>
Require all denied
</Directory>
<DirectoryMatch "^/var/www/PFAD/pub/media">
<FilesMatch ".ph(p|tml)$">
Require all denied
</FilesMatch>
</DirectoryMatch>Forensik-Checks für betroffene Betreiber
Wer seinen Shop jetzt prüfen will, kann mit diesen Befehlen starten:
# Backdoor-Dateien suchen
find /var/www/PFAD/pub/media/ -name "*.php" -o -name "*.phtml"
# Apache-Logs prüfen
grep "custom_options.*.php" access.log
# Admin-User seit März anlegen
SELECT * FROM admin_user WHERE created >= '2026-03-01';
# CMS-Blöcke auf Skimmer prüfen
SELECT * FROM cms_block WHERE content LIKE '%<script%';Zusätzlich empfiehlt der Dienstleister einen Cron-Job, der täglich nach neuen PHP-Dateien in /pub/media/ sucht und Alarm schlägt. Blockieren allein reicht nicht – ohne Monitoring bleibt man blind.
Offene Frage: Gab es erfolgreiche Zugriffe?
Der Dienstleister fragt explizit in die Community: Hat jemand HTTP-200-Antworten auf .php-Dateien in custom_options in seinen Logs? In seinem Fall nur 404 und 301. Wer das gegenteilige erlebt hat – tatsächliche Datenexfiltration – sollte sich melden. Das würde das Lagebild erheblich schärfen.
Wer betroffen ist oder Hinweise hat: Kommentare sind offen – und Wortfilter dankt für die detaillierte Auswertung, die anderen Händlern jetzt konkret weiterhilft.
