Magento-Sicherheitspatches: Monatliche isolierte Patches erklärt

Für Engineering Manager und Entwickler:innen, die Adobe Commerce, Magento Open Source oder Mage-OS betreiben.

Bisher war der Fahrplan simpel: Du wartest auf das nächste Patch-Release (2.4.8-p5 → 2.4.8-p6) und spielst es ein. Das reicht nicht mehr. Adobe liefert Sicherheitsfixes inzwischen jeden Monat als isolierte Patches aus, und wer nur auf das große Release wartet, ist unter Umständen wochenlang angreifbar. Hier erfährst du, was sich geändert hat, was das für deine Plattform heißt und wie wir damit umgehen.

TL;DR

• Monatliche isolierte Sicherheitspatches gibt es jetzt jeweils am Patch Tuesday (dem zweiten Dienstag im Monat), und zwar für Adobe Commerce on Cloud, Adobe Commerce on-premises und Magento Open Source.
• Die -pN-Releases bleiben und sind weiterhin die kumulative Sicherheitsbasis. Jeder isolierte Patch landet später im nächsten -pN-Release.
• Isolierte Patches bauen aufeinander auf, sind aber nicht kumulativ. Du brauchst erst die aktuelle -p-Basis und dann jeden verpassten Patch in der richtigen Reihenfolge.
• Hotfixes für akute Fälle wie Zero-Days kommen zuerst als einzelne Patch-Dateien. Danach wandern sie in die Cloud Patches und schließlich in ein -p-Release.
• Auf Adobe Commerce Cloud läuft das meiste automatisch über die Cloud Patches for Commerce (ece-tools). Für Open Source und Mage-OS gibt es dieses Tool nicht. Dort patchst du überwiegend von Hand.
• Unsere Empfehlung: Sicherheitsfixes so schnell wie möglich einspielen, und zwar über den Kanal, den deine Plattform am besten unterstützt.

Was sich bei Adobe geändert hat

Schwachstellen werden schneller gefunden als früher. Adobe verweist selbst darauf, dass KI-gestützte Analyse große Codebasen viel schneller nach Fehlern durchforstet als jedes manuelle Review. Das Zeitfenster zwischen Veröffentlichung eines Fixes und ersten Angriffen wird damit kürzer. Monate auf das nächste Jahres-Release zu warten, ist ein echtes Risiko.

Adobes Antwort darauf sind isolierte Sicherheitspatches im Monatsrhythmus: kleine Änderungen, die ausschließlich Sicherheitslücken schließen und bestimmte CVEs beheben. Weil Adobe dafür weder Abhängigkeiten neu auflösen noch den kompletten Regressionstest eines Composer-Releases durchlaufen muss, sind sie schnell gebaut, geprüft und ausgeliefert. Für dich sind sie außerdem leichter zu überblicken und einzuspielen.

Die Patch-Typen

Hier stolpern Teams am häufigsten

1. Erst die Basis. Adobe testet isolierte Patches nur gegen das jeweils aktuelle reine Security--p-Release deiner Linie. Bist du schon mit der Basis im Rückstand, musst du zuerst upgraden.
2. Die Reihenfolge zählt. Hast du Juli und August verpasst, spielst du erst den Juli-Patch ein, dann August, dann September. Die neueste Datei allein reicht nicht.
3. Die Komponenten müssen passen. Jede Patch-Datei gilt für eine bestimmte Komponentenversion (CE, EE, B2B, Page Builder). Nimm nur die Datei, die zu deiner Installation gehört.
4. Ein -p-Release beginnt die Kette von vorn. Es enthält alle Fixes, die vorher als isolierte Patches erschienen sind.
5. Die Versionsnummer allein sagt nicht alles. Das Commerce Version Tool von Adobe zeigt dir, welche Patches installiert sind, welche fehlen und für welche CVEs dein Shop noch angreifbar ist. Die Ausgabe ist maschinenlesbar, du kannst das Tool also auch in der CI laufen lassen.

Was das für Entscheider heißt

Das empfehlen wir je Plattform

Die Faustregel ist überall dieselbe: Nimm zuerst den Weg, den der Hersteller am besten integriert hat, und greife nur dann zu manuellen Patch-Dateien, wenn es nicht anders geht.

Adobe Commerce on Cloud

Ein paar Tipps:

• Binde den Patch-Befehl als Composer-Hook (Post-Install und Post-Update) ein. Dann werden Patches bei jedem composer install und composer update automatisch angewendet.
• Schau vor dem manuellen Einspielen in deine installierte Cloud-Patches-Version. Der Fix kann dort schon enthalten sein, und ein zweites Anwenden führt zu Konflikten oder doppelten Änderungen.
• Kommt ein manuell eingespielter Fix später über Option 1 oder 2 ins Projekt, nimm den manuellen Patch wieder aus der Konfiguration.
• Mit der Adobe Commerce Patching Automation kannst du als Cloud-Kunde Patches außerdem direkt im Admin einspielen oder zurücknehmen.

Adobe Commerce on-premises

Hier gibt es keine Cloud Patches. Prüf zuerst, auf welcher -p-Basis du bist, und lade dann für jede installierte Komponente die passende isolierte Patch-Datei herunter. Spiel die Patches der Reihe nach ein (zum Beispiel mit cweagans/composer-patches) und kontrolliere das Ergebnis anschließend mit dem Commerce Version Tool.

Magento Open Source

• Es gibt sowohl -pN-Releases als auch monatliche isolierte Patches, letztere als einzelne Dateien.
• ece-tools und Cloud Patches gibt es für Open Source nicht.
• In der Praxis gehst du so vor: Steckt der Fix in einem -p-Release, upgradest du darauf. Wenn nicht, spielst du die isolierte Patch-Datei für deine Version mit einem Composer-Patch-Tool ein.
• Für Basis, Reihenfolge und passende Komponenten gelten dieselben Regeln wie oben.

Mage-OS

Mage-OS ist ein Community-Fork mit eigenen Releases und eigenen Paketen (mage-os/*). ece-tools kommt dort nicht zum Einsatz.

• Der bevorzugte Weg: Upgrade auf das neueste Mage-OS-Release, das den Fix enthält. Mage-OS übernimmt Adobes Sicherheitsfixes in eigene Releases, oft schon nach wenigen Tagen. Verlass dich aber nicht darauf, sondern lies die Release Notes zur jeweiligen CVE.
• Bis zum nächsten Release: Du kannst Adobes isolierte Sicherheitspatches auch auf Mage-OS anwenden. Meistens klappt das ohne Probleme. Mage-OS bringt aber viele Verbesserungen gegenüber dem Upstream-Code mit, deshalb passt ein Patch gelegentlich nicht sauber. Dann hilft in der Regel die große, aktive Mage-OS-Community schnell weiter. Schau außerdem nach, ob das Projekt selbst einen Patch oder ein Advisory veröffentlicht hat.
• Immer erst auf Staging testen: Adobes Patch-Dateien verweisen auf Pfade in magento/*-Paketen. Dein Composer-Patch-Tool muss deshalb eventuell auf die mage-os/*-Pakete umgestellt werden. Prüf, ob der Patch zu deiner exakten Mage-OS-Version passt und ob die betroffene Funktion danach noch läuft.
• Behalte beides im Blick: Adobes Security Bulletins (was ist verwundbar?) und die Release-Kanäle von Mage-OS (wie und wann wird es für dich behoben?).

Eine einfache Routine

1. Patch Tuesday (zweiter Dienstag): Lies das Adobe Security Bulletin und die Release Notes.
2. Bewerten: Lass, wo möglich, das Commerce Version Tool laufen und prüfe, welche CVEs dich betreffen und welche Komponenten involviert sind.
3. Kanal wählen: Die Prioritätstabellen oben helfen dir dabei.
4. Auf Staging einspielen und die Regressionstests durchlaufen lassen, vor allem für Checkout, Admin und alles, was die gepatchte Komponente berührt.
5. In Production ausrollen, über euren normalen Change-Prozess.
6. Dokumentieren: Notiere Patch, CVE und Datum. Entferne manuelle Patch-Einträge, sobald ein Release den Fix enthält.
7. Einmal im Jahr auf das neueste -p-Release wechseln, damit die Patch-Kette wieder bei null beginnt.

Quellen

• Adobe: Monthly isolated security patching policy
• Adobe: Introducing enhanced security patch deployment and communications in Adobe Commerce
• Mage-OS

---

Bild von Fellipe Ditadi auf Unsplash+