Die Schwachstellen mit den Kennungen CVE-2026-109618 und CVE-2026-109619 ermöglichen unter bestimmten Voraussetzungen die Ausführung fremden Codes auf dem Server, und das unter Umständen ganz ohne vorherige Anmeldung. Beide wurden mit einem Schweregrad von 9,2 bewertet.

Warum ältere Magento Shops besonders betroffen sind

Magento 1 benötigt in vielen Installationen noch PHP 5.x oder PHP 7.x. Auch ältere Magento 2 Installationen sind häufig an bestimmte PHP Versionen gebunden.

Ein Wechsel auf PHP 8.3 oder 8.4 kann deshalb dazu führen, dass der Shop nicht mehr funktioniert. Veraltete Bibliotheken, individuelle Erweiterungen und Anpassungen am Magento Core machen den Wechsel mitunter zu einem größeren Projekt.

Das Problem dabei: PHP 5.x und PHP 7.x erhalten keine regulären Sicherheitsupdates mehr. Ein Shop, der gestern noch problemlos funktionierte, kann heute also einer erheblichen zusätzlichen Gefahr ausgesetzt sein.

Übrigens sind auch ältere PHP 8 Versionen betroffen. Allein die Versionsnummer 8 bedeutet noch nicht, dass ein System sicher ist.

Was können Shopbetreiber jetzt tun?

Die gute Nachricht ist, dass nicht zwingend sofort der komplette Magento Shop modernisiert werden muss, um das Risiko zumindest vorübergehend zu reduzieren.

Je nach Serverkonfiguration kommen unter anderem folgende Maßnahmen infrage:

• Webserver absichern: Gefährliche Anfragen möglichst bereits durch Apache, nginx oder eine vorgeschaltete Firewall abweisen.
• PHP Konfiguration härten: Bestimmte PHP Funktionen deaktivieren und die Verarbeitung von Anfragen serverseitig begrenzen.
• Adminbereich schützen: Den Magento Administrationsbereich zusätzlich absichern und unnötige öffentliche Zugriffsmöglichkeiten reduzieren.
• Hosting prüfen: Klären, ob der Anbieter Sicherheitskorrekturen für die verwendete alte PHP Version bereitstellt.
• Magento Erweiterungen kontrollieren: Nicht mehr benötigte Funktionen entfernen und gefährdete Schnittstellen möglichst einschränken.

Wichtig: Diese Maßnahmen ersetzen keinen Sicherheitspatch für PHP selbst. Sie können bestimmte Angriffsmöglichkeiten einschränken, bieten aber keinen vollständigen Schutz. Im Zweifelsfall muss ein gefährdetes System vorübergehend vom öffentlichen Zugriff getrennt werden.

Warum nicht einfach PHP aktualisieren?

Wer einen aktuellen Magento 2 Shop betreibt, kann oftmals vergleichsweise unkompliziert auf eine unterstützte PHP Version wechseln, sofern die installierten Erweiterungen mitspielen.

Bei Magento 1 oder älteren Magento 2 Versionen sieht es anders aus. Hier müssen zunächst die technischen Abhängigkeiten untersucht werden. Eventuell lassen sich einzelne Erweiterungen anpassen, an anderer Stelle wird eine umfassendere Aktualisierung notwendig.

Ein pauschaler Wechsel der PHP Version ist deshalb keine gute Idee. Schließlich soll der Shop nach der Sicherheitsmaßnahme auch weiterhin vollständig funktionieren.

Ich unterstütze Sie bei der Absicherung Ihres Magento Shops

Sie betreiben einen Magento 1 oder Magento 2 Shop mit PHP 5.6, 7.4 oder einer anderen veralteten PHP Version und wissen nicht, wie Sie auf die aktuellen Sicherheitslücken reagieren sollen?

Dann kontaktieren Sie mich gerne.

Ich prüfe Ihre bestehende Magento Installation, die PHP Umgebung und die Möglichkeiten zur kurzfristigen Absicherung. Dabei geht es zunächst darum, das tatsächliche Risiko zu bewerten und sinnvolle Maßnahmen umzusetzen, ohne unnötig in einen funktionierenden Shop einzugreifen.

Wenn eine dauerhafte Aktualisierung erforderlich ist, erarbeiten wir anschließend einen passenden Weg. Von der Anpassung einzelner Erweiterungen bis zum vollständigen Magento Update.

Weiterführende Informationen

Die offiziellen Informationen zu den Schwachstellen, betroffenen PHP Versionen und verfügbaren Sicherheitsupdates finden Sie direkt beim PHP Entwicklungsteam.

Die URL Rewrites einer bestimmten SKU lassen sich mit folgender Abfrage anzeigen:

SELECT
    p.sku,
    u.store_id,
    s.code AS store_code,
    s.name AS store_name,
    u.request_path,
    u.target_path,
    u.redirect_type
FROM url_rewrite AS u
JOIN catalog_product_entity AS p
    ON u.entity_id = p.entity_id
LEFT JOIN store AS s
    ON s.store_id = u.store_id
WHERE u.entity_type = 'product'
  AND p.sku = 'MEINE-SKU'
ORDER BY u.store_id, u.request_path;

request_path enthält die im Shop sichtbare URL, während target_path auf das interne Magento Ziel verweist. Über store_id bzw. store_name lässt sich erkennen, für welche Store View der jeweilige Rewrite gilt.

Mehrere Treffer für dasselbe Produkt sind deshalb nicht automatisch doppelte oder fehlerhafte Einträge. Unterschiedliche store_id Werte bedeuten in der Regel, dass Magento für verschiedene Store Views eigene Rewrites führt.

Interessant ist außerdem redirect_type. Der Wert 0 steht für einen normalen Rewrite ohne Weiterleitung, 301 und 302 entsprechend für permanente beziehungsweise temporäre Weiterleitungen.

Gerade nach Änderungen am URL Key, Migrationen oder Importen lässt sich damit schnell erkennen, welche Rewrite Einträge Magento für ein Produkt tatsächlich gespeichert hat.

grep -RInP 'ObjectManager\s*::\s*getInstance\s*\(' app/code

Gefunden werden damit beispielsweise Stellen wie:

$objectManager = \Magento\Framework\App\ObjectManager::getInstance();

$productRepository = $objectManager->get(
    \Magento\Catalog\Api\ProductRepositoryInterface::class
);

Der reguläre Ausdruck berücksichtigt auch unterschiedliche Leerzeichen rund um :: und vor der öffnenden Klammer. Mit -R wird rekursiv gesucht, -n gibt die Zeilennummer aus und -P aktiviert die Perl kompatiblen regulären Ausdrücke von grep.

Auch typische anschließende Aufrufe über eine Variable namens $objectManager lassen sich suchen:

grep -RInP '\$objectManager\s*->\s*(get|create)\s*\(' app/code

Direkte ObjectManager Nutzung gilt im eigenen Magento Code in der Regel als Bad Practice. Der wichtigste Grund ist, dass die tatsächlichen Abhängigkeiten einer Klasse dadurch versteckt werden. Am Konstruktor ist nicht mehr erkennbar, welche Services die Klasse benötigt, weil diese erst irgendwo innerhalb einer Methode aus dem ObjectManager geholt werden.

Das macht den Code schwerer verständlich und vor allem schwerer testbar. Bei sauberer Dependency Injection kann eine benötigte Abhängigkeit in einem Unit Test einfach durch ein Mock Objekt ersetzt werden. Holt sich die Klasse ihren Service dagegen selbst über den globalen ObjectManager, muss der Test zusätzlich diesen versteckten Zugriff berücksichtigen.

Auch z.B. Änderungen werden unnötig schwieriger. Benötigt eine Klasse fünf Services über den Konstruktor, ist dies sofort sichtbar. Werden dieselben fünf Services über verschiedene Methoden verteilt aus dem ObjectManager geladen, erkennt man diese Abhängigkeiten erst beim Lesen des gesamten Codes.

Sauberer ist deshalb die direkte Übergabe über den Konstruktor:

use Magento\Catalog\Api\ProductRepositoryInterface;

public function __construct(
    private ProductRepositoryInterface $productRepository
) {
}

Magento kann die konkrete Implementierung anschließend selbst über seine Dependency Injection Konfiguration auflösen. Preferences, Proxies, Plugins und andere Mechanismen des Object Managers funktionieren dabei weiterhin, nur die Klasse selbst muss nicht wissen, wie ihre Abhängigkeit erzeugt wird.

Der ObjectManager ist also nicht grundsätzlich etwas Schlechtes, Magento selbst basiert schließlich darauf. Problematisch ist normalerweise der direkte Zugriff aus dem eigenen Anwendungscode, weil damit aus Dependency Injection praktisch ein versteckter Service Locator wird.

bin/magento setup:db:status

Magento vergleicht dabei den aktuellen Datenbankstand mit den installierten Modulen und meldet, ob noch ein Upgrade erforderlich ist.

Ist alles aktuell, muss setup:upgrade nicht unnötig erneut ausgeführt werden. Zeigt Magento dagegen einen abweichenden Stand, sollte das Upgrade durchgeführt werden.

bin/magento setup:upgrade

bin/magento module:status

Magento trennt die Ausgabe in List of enabled modules und List of disabled modules. Dadurch sieht man schnell, ob eine Extension wirklich geladen wird oder nur noch im Dateisystem vorhanden ist.

Ein einzelnes Modul lässt sich ebenfalls direkt prüfen:

bin/magento module:status Vendor_Module

Gerade nach Deployments, Updates oder manuellen Änderungen in app/code ist das eine schnelle Möglichkeit zu kontrollieren, ob Magento das betreffende Modul tatsächlich als aktiv führt.

Wichtig ist dabei: Ein vorhandener Modulordner bedeutet noch nicht automatisch, dass das Modul aktiviert ist.

bin/magento indexer:status

Steht bei einem Indexer Reindex required, kann dieser gezielt neu aufgebaut werden. Zuerst lässt sich mit folgendem Befehl die jeweilige Indexer ID anzeigen:

bin/magento indexer:info

Anschließend kann z.B. nur der Produktpreisindex neu aufgebaut werden:

bin/magento indexer:reindex catalog_product_price

Natürlich lassen sich mit bin/magento indexer:reindex auch alle Indexer auf einmal aufbauen. Gerade bei größeren Magento 2 Shops ist es aber oft sinnvoller, zunächst zu prüfen, welcher Indexer überhaupt betroffen ist.

Mit der folgenden SQL Abfrage können Sie die 20 größten Tabellen inklusive Daten, Index und Gesamtgröße anzeigen:

SELECT
    TABLE_NAME AS Tabelle,
    TABLE_ROWS AS Zeilen,
    ROUND(DATA_LENGTH / 1024 / 1024, 2) AS Daten_MB,
    ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS Index_MB,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS Gesamt_MB,
    ROUND(DATA_LENGTH / 1024 / 1024 / 1024, 3) AS Daten_GB,
    ROUND(INDEX_LENGTH / 1024 / 1024 / 1024, 3) AS Index_GB,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024 / 1024, 3) AS Gesamt_GB
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'MAGENTO_DATENBANK'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC
LIMIT 20;

MAGENTO_DATENBANK muss dabei durch den tatsächlichen Namen der Magento Datenbank ersetzt werden. Dieser steht beispielsweise in app/etc/env.php unter dbname.

Interessant sind vor allem Gesamt_MB beziehungsweise Gesamt_GB, da hier Daten und Indizes zusammengezählt werden. So fällt schnell auf, wenn beispielsweise eine Cron, Quote, Log oder Extension Tabelle ungewöhnlich viel Platz belegt.

Die Spalte Zeilen sollte bei InnoDB nur als ungefährer Wert betrachtet werden. Für die Suche nach besonders großen Tabellen sind dagegen DATA_LENGTH und INDEX_LENGTH entscheidend.

Die Abfrage verändert keine Daten und eignet sich deshalb gut als erster Überblick, bevor genauer untersucht wird, warum eine Magento Datenbank so groß geworden ist.

Flush Magento Cache sagt vereinfacht: Lösche die Cache Einträge, von denen Magento weiß, dass sie zu Magento gehören.

bin/magento cache:clean

bzw.

bin/magento c:c

Magento räumt also seine eigenen Cache Daten auf, lässt den verwendeten Cache Speicher selbst aber bestehen.

Flush Cache Storage sagt dagegen: Leere den gesamten Cache Speicher, den Magento gerade verwendet.

bin/magento cache:flush

bzw.

bin/magento c:f

Am einfachsten lässt es sich mit einer Schublade vergleichen: cache:clean nimmt nur die Magento Sachen aus der Schublade. cache:flush kippt den kompletten Inhalt der Schublade aus. Danach ist die Schublade leer.

Das wird beispielsweise bei Redis wichtig. Nutzt noch eine andere Anwendung denselben Redis Speicher, kann Flush Cache Storage auch deren Cache Daten entfernen.

Für das normale Cache Leeren reicht deshalb in der Regel Flush Magento Cache. Flush Cache Storage ist die gröbere Variante und sinnvoll, wenn wirklich der gesamte verwendete Cache Speicher geleert werden soll.

Der Wartungsmodus mit freigegebener eigener IP wird so aktiviert:

bin/magento maintenance:enable --ip=123.123.123.123

Für normale Besucher erscheint anschließend die Wartungsseite, während die freigegebene IP den Shop weiterhin aufrufen kann.

Der aktuelle Status lässt sich jederzeit prüfen:

bin/magento maintenance:status

Nach Abschluss der Arbeiten wird der Wartungsmodus wieder deaktiviert:

bin/magento maintenance:disable

Das ist besonders praktisch bei z.B. Magento Updates oder Deployments, da sich das Frontend bereits testen lässt, ohne den Shop vorher wieder für alle Besucher freizugeben.

Magento bringt dafür mit dem LockManagerInterface bereits einen passenden Mechanismus mit. Vor dem eigentlichen Prozess wird ein Lock gesetzt. Existiert dieser bereits, beendet sich der zweite Lauf direkt wieder.

use Magento\Framework\Lock\LockManagerInterface;

class Import
{
    public function __construct(
        private LockManagerInterface $lockManager
    ) {
    }

    public function execute(): void
    {
        $lockName = 'vendor_module_import';

        if (!$this->lockManager->lock($lockName, 0)) {
            return;
        }

        try {
            // Run import
        } finally {
            $this->lockManager->unlock($lockName);
        }
    }
}

Der Name des Locks sollte für den jeweiligen Prozess eindeutig sein. Solange vendor_module_import gesperrt ist, kann kein zweiter Lauf mit demselben Lock gleichzeitig starten.

Wichtig ist das finally: Auch wenn innerhalb des Cronjobs eine Exception entsteht, wird der Lock anschließend wieder freigegeben.

Magento verwendet den Lock Mechanismus selbst an verschiedenen Stellen, unter anderem um parallele Prozesse voneinander fernzuhalten. Für längere eigene Cronjobs ist LockManagerInterface deshalb deutlich sauberer als eine selbst gebaute Statusdatei oder ein Flag in der Datenbank.