Kurz gesagt: Die aktuelle Magento-Sicherheitslücke heißt PHP2Shell und steckt nicht in Magento, sondern in PHP. Ein Magento-Patch schließt sie nicht. Nach dem PHP-Update mit Neustart sollten Sie app/etc/env.php, die Datenbank auf Skimmer und die Liste der Admin-Konten prüfen.
Was PHP2Shell für Magento-Shops bedeutet
Magento Open Source und Adobe Commerce sind große PHP-Anwendungen, die meist mit PHP-FPM laufen. Die Lücken CVE-2026-109618 und CVE-2026-109619 erlauben laut PHP-Team das Ausführen von Schadcode ohne Anmeldung. Ob der Shop selbst aktuell ist, spielt dafür keine Rolle.
Magento-Shops sind seit Jahren ein bevorzugtes Ziel für Kreditkarten-Skimming, bei dem Eingaben im Checkout mitgelesen werden. PHP2Shell öffnet dafür einen weiteren Weg. Palo Alto Networks zählte mehr als 22,6 Millionen exponierte, potenziell verwundbare PHP-Instanzen; welche Shops darunter sind, ist nicht bekannt.
Magento-Sicherheitslücke: PHP-Stand richtig feststellen
Magento zeigt die PHP-Version nicht prominent im Admin an. Prüfen Sie den Stand deshalb im Hosting-Panel für die Domain oder lassen Sie ihn von Ihrem Hoster bestätigen. php -v auf der Kommandozeile zeigt nur das CLI-PHP, mit dem bin/magento und Cronjobs laufen. Das Web-PHP über FPM kann eine andere Version sein, und beide müssen gepatcht sein.
Behobene Upstream-Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35, Backports der Distributionen können ältere Nummern tragen. Welche PHP-Versionen Ihre Magento-Version unterstützt, prüfen Sie laut Systemanforderungen in der Dokumentation von Adobe (experienceleague.adobe.com). Bei Adobe Commerce auf Adobe-Infrastruktur fragen Sie Adobe oder Ihren Betreiber nach dem Stand. Eine Schritt-für-Schritt-Anleitung bietet PHP-Version und Patchstand richtig prüfen.
Wo Schadcode in Magento sitzt
| Ort | Inhalt | Prüfpunkt |
|---|---|---|
app/etc/env.php |
Datenbank, Verschlüsselungsschlüssel, Admin-Pfad | Änderungsdatum, Werte nach Verdacht erneuern |
pub/ |
Dokumentwurzel, pub/media, pub/static |
PHP-Dateien in Medien- und Static-Ordnern |
app/code/ |
eigene Module | unbekannte Module, veränderte Dateien |
vendor/ |
Composer-Pakete, auch Erweiterungen | Abweichungen vom Lockfile |
generated/, var/ |
erzeugter Code, Cache, Logs | Logs sichern, Code neu erzeugen |
| Datenbank | Konfiguration, CMS-Blöcke, Admin-Benutzer | fremde Skripte, neue Admins |
Skimmer liegen in Magento oft in der Datenbank, zum Beispiel in den Einstellungen für zusätzliche Skripte im Seitenkopf oder Seitenfuß und in CMS-Blöcken. Ein reiner Datei-Scan übersieht sie. Ungefährliche Lesezugriffe helfen beim ersten Blick (Tabellenpräfix je nach Installation):
bin/magento info:adminuri
bin/magento module:status
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
Ein bereinigter Checkout bedeutet nicht, dass keine Daten abgeflossen sind. Sichern Sie Logs ab dem 20.10.2026 und Datenbank-Abzüge, bevor Sie Skripte entfernen. Nur so lässt sich später feststellen, ab wann und welche Bestellungen betroffen waren.
Admin-Bereich und Erweiterungen
Der Admin-Pfad ist in Magento frei wählbar und steht in env.php. Ein schwer zu erratender Pfad ist sinnvoll, ersetzt aber keine Zwei-Faktor-Anmeldung und keine Begrenzung auf bekannte Netze. Prüfen Sie die Admin-Benutzer und deren Rollen regelmäßig, ebenso Integrationen und API-Tokens.
Erweiterungen von Drittanbietern sind bei Magento zahlreich: Zahlungsarten, ERP-Anbindungen, Such- und Marketing-Module. Jede bringt Code mit, der bei PHP-Upgrades geprüft werden muss. Setzen Sie composer audit regelmäßig ein und entfernen Sie abgeschaltete Module vollständig.
Denken Sie auch an die Hintergrundprozesse. Magento arbeitet mit Cronjobs und häufig mit Warteschlangen-Consumern, die als eigene PHP-Prozesse über die Kommandozeile laufen. Nach dem PHP-Update müssen diese ebenso neu starten wie PHP-FPM. Nach einem Wechsel der PHP-Hauptversion sollten Sie außerdem den erzeugten Code in generated/ und die statischen Dateien neu bauen lassen und den Shop in einer Testumgebung durchklicken, bevor der Live-Betrieb wieder aufgenommen wird. Wie der Neustart sauber gelingt, beschreibt PHP-FPM und alle Worker neu starten.
Was ein Magento-Update kann und was nicht
Ein Magento-Release oder Sicherheitspatch von Adobe schließt Fehler im Shop-Code. Es patcht nicht PHP, startet keine FPM-Prozesse neu, entfernt keine Skripte aus der Datenbank und löscht keine fremden Admin-Konten. Wurde schon Code ausgeführt, braucht es eine Untersuchung. Wie Sie Hintertüren erkennen, erklärt Webshells erkennen und entfernen.
Für Händler mit Kartenzahlung gilt zusätzlich: Prüfen Sie die Vorgaben Ihres Zahlungsanbieters für Sicherheitsvorfälle und stimmen Sie sich vor dem Erneuern von Schlüsseln mit ihm ab. Ob eine Meldung an die Datenschutzaufsicht nötig ist, klären Sie mit Ihrem Datenschutzbeauftragten oder Anwalt.
Wie hilft PHP SOS konkret?
- Wir klären Web- und CLI-PHP Ihres Magento-Servers und lassen Patch und Neustart bestätigen.
- Wir sichern Logs, Dateien und Datenbank nachvollziehbar, bei Bedarf über unsere IT-Forensik.
- Wir prüfen
env.php,pub/, Module, Konfigurationstabellen, CMS-Blöcke und Admin-Konten. - Wir bereinigen, erneuern Schlüssel und Zugänge und dokumentieren den Zeitraum möglicher Betroffenheit für Datenschutz und Zahlungsanbieter.
Häufige Fragen
Schließt ein Magento-Sicherheitspatch auch PHP2Shell?
Nein. Magento-Patches beheben Fehler im Shop-Code. PHP2Shell liegt im PHP-Interpreter des Servers und wird nur durch ein PHP-Update oder einen bestätigten Backport mit Neustart aller Prozesse geschlossen.
Wo verstecken Angreifer Kreditkarten-Skimmer in Magento?
Häufig nicht in Dateien, sondern in der Datenbank, etwa in Einstellungen für zusätzliche Skripte im Seitenkopf oder in CMS-Blöcken. Deshalb gehört nach einem Verdacht immer auch eine Prüfung der Datenbank dazu.
Wer patcht PHP bei Adobe Commerce in der Cloud?
Das hängt von Ihrem Vertrag und Ihrer Umgebung ab. Fragen Sie Adobe oder Ihren Betreiber schriftlich nach dem PHP-Stand und dem Neustart. Eigene Erweiterungen und Datenbankinhalte bleiben in Ihrer Verantwortung.
Warum ist app/etc/env.php so wichtig?
Die Datei enthält Datenbankzugang, den Verschlüsselungsschlüssel und den Pfad zum Admin-Bereich. Wer sie lesen konnte, kann verschlüsselte Werte entschlüsseln und den Admin finden. Nach einem Verdacht sollten diese Werte erneuert werden.