CVE-2026-75650 in Adobe Commerce und Magento: Shop patchen und anschließend untersuchen

Adobe hat einen Notfall-Hotfix für CVE-2026-75650 veröffentlicht. Die kritische Schwachstelle in Adobe Commerce und Magento Open Source kann eine nicht authentifizierte Remote-Code-Ausführung ermöglichen. Adobe bewertet den Fehler mit CVSS 10,0 und erklärt, dass er aktiv ausgenutzt wird. Auch das Australian Cyber Security Centre und Singapurs Cyber Security Agency haben betroffene Organisationen aufgefordert, sofort zu patchen.

Für Betreiber ist der entscheidende Unterschied, ob eine Schwachstelle geschlossen wurde oder ob nachgewiesen ist, dass der Shop nicht bereits kompromittiert war. Das erste ist eine Aufgabe der Softwarewartung. Das zweite gehört zur Incident Response. Ein Shop, der während des Ausnutzungszeitraums erreichbar war, gilt nicht allein deshalb als sauber, weil sein Patch-Status inzwischen korrekt aussieht.

Das Problem unterscheidet sich damit deutlich von einem routinemäßigen Monatsupdate. Öffentliche Berichte beschreiben Angriffe, die vor dem Adobe-Hotfix vom 7. September begonnen haben. Der Forscher, der das Problem veröffentlicht hat, berichtet außerdem, dass Angreifer ihre Payloads verändern und aktive Shops gezielt ansprechen. Die sicherste Reaktion ist deshalb eine kurze, geordnete Abfolge: jede betroffene Installation ermitteln, den Hersteller-Fix einspielen, Beweise sichern, Host und Anwendung untersuchen, möglicherweise offengelegte Geheimnisse rotieren und den Shop erst danach wieder in den normalen Betrieb überführen.

Was CVE-2026-75650 betrifft

CVE-2026-75650 ist ein Fehler bei der unzureichenden Neutralisierung in einer Template-Engine. Adobe stuft die Auswirkung als beliebige Codeausführung ein, verlangt keine Authentifizierung und weist der Schwachstelle einen CVSS-3.1-Basiswert von 10,0 zu. Dieser Wert beschreibt einen über das Netzwerk erreichbaren Angriffsweg ohne erforderliche Berechtigungen oder Benutzerinteraktion und mit potenziell hohen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.

Zur betroffenen Produktfamilie gehören Adobe Commerce, Adobe Commerce B2B und Magento Open Source. Das Adobe-Bulletin vom 7. September führt Adobe-Commerce-Versionen von 2.4.4 bis 2.4.9 als betroffen auf, einschließlich Releases mit dem Build-Kennzeichen 2026-August. Für Adobe Commerce B2B nennt es die Versionen 1.3.3 bis 1.5.3, für Magento Open Source die Versionen 2.4.6 bis 2.4.9. Für die genaue Kombination aus Paket und Build ist das Adobe-Bulletin maßgeblich. Betreiber sollten die laufende Installation und den ausgerollten Code damit abgleichen, statt sich allein auf den Namen der Produktfamilie zu verlassen.

Das Australian Cyber Security Centre ergänzt ein für die Triage wichtiges Detail: Für die Ausnutzung muss der Endpunkt /graphql offengelegt sein. Daraus folgt nicht, dass ein Shop mit Internetzugang sicher wäre, wenn GraphQL nur aufgrund einer Entwicklungsannahme deaktiviert, selektiv gefiltert oder über einen Load-Balancer, ein CDN, einen alternativen Hostnamen oder eine alte Route erreichbar ist. Teams sollten die Erreichbarkeit aus der tatsächlichen öffentlichen Bereitstellung prüfen und außerdem administrative oder Staging-Umgebungen einbeziehen, die von außerhalb des vertrauenswürdigen Netzes erreichbar sind.

Die betroffene Software betreibt Onlineshops, verarbeitet Kundenbestellungen und verbindet Zahlungs-, Fulfillment-, Analyse- und weitere Geschäftssysteme. Die Schwachstelle beschränkt sich daher nicht auf den Webserver. Eine erfolgreiche Kompromittierung könnte einen Weg zu Zugangsdaten, Integrationstokens, kundenbezogenen Anwendungsdaten, Bestellabläufen oder anderen Diensten schaffen, die dem Commerce-Prozess zur Verfügung stehen. Die konkrete Geschäftsauswirkung hängt von den Berechtigungen des Dienstkontos, der Host-Konfiguration sowie den in der Anwendung gespeicherten oder von ihr erreichbaren Geheimnissen ab.

Warum der Zeitpunkt die Reaktion verändert

Adobe veröffentlichte APSB26-146 am 7. September 2026 mit der höchsten Prioritätsstufe. Im Bulletin erklärt Adobe, dass das Unternehmen von einer Ausnutzung in freier Wildbahn weiß. Sansec, das seine Recherche am 5. September veröffentlichte, berichtete von beobachteten Angriffen ab dem 4. September und bezeichnete das Problem zum Zeitpunkt der Veröffentlichung als nicht authentifizierte Zero-Day-Schwachstelle zur Remote-Code-Ausführung. Die Sansec-Seite wurde am 13. September aktualisiert und erklärt, der Notfall-Fix sei drei Tage nach der ersten bestätigten Ausnutzung veröffentlicht worden.

Diese Daten bilden eine klare Risikogrenze. Jeder Shop, der vor der Bereitstellung des Fixes erreichbar war, braucht eine Bewertung der Exposition, selbst wenn kein offensichtlicher Ausfall aufgetreten ist. Ein Angreifer mit Codeausführung muss weder die Startseite verändern noch den Checkout unterbrechen, um Schaden anzurichten. Er kann Zugangsdaten unauffällig sammeln, eine Webshell oder einen Hintergrundprozess installieren, Anwendungscode verändern, Persistenz einrichten oder den Shop als Sprungbrett nutzen. Ein normaler Ablauf für Kunden ist kein Beleg dafür, dass der Host sauber ist.

Dass keine öffentlich bestätigte Kampagne gegen eine bestimmte Branche bekannt ist, sollte bei einzelnen Betreibern keine Entwarnung auslösen. Das australische Advisory erklärt, dass Informationen über aktive Ausnutzung vorliegen, aber keine Hinweise auf eine gezielte Auswahl genau eines Sektors. Das bedeutet: Das Problem ist branchenübergreifend. Jede Organisation mit der betroffenen Plattform muss ihre Exposition anhand von Versionen, Erreichbarkeit des Endpunkts, Logs und Bereitstellungshistorie selbst bewerten.

Die erste Entscheidung: patchen oder eindämmen

Ist der Shop betroffen und kann der Hotfix sicher eingespielt werden, besteht die unmittelbare Maßnahme darin, die Installationsanweisungen von Adobe für den Hotfix zu CVE-2026-75650 zu befolgen. Sansec bezeichnet den Fix als Adobe-Hotfix VULN-39341, der als Composer-Patch ausgeliefert wird. Das genaue Paket, der unterstützte Release und das Bereitstellungsverfahren müssen sich aus den Adobe-Release-Notes und der Supportvereinbarung des Betreibers ergeben. Ein aus einem nicht überprüften Forum kopierter Patch ist kein Ersatz. Ebenso wenig beweist ein gewöhnliches Ergebnis von security:patch-status, dass dieser Notfall-Fix installiert ist.

Vor Änderungen in der Produktion sollte ein geschütztes Backup der relevanten Anwendungsdateien, Konfigurationen, Datenbanken und Logs erstellt werden. Halten Sie die aktuelle Version, die Paket-Lockdatei, den ausgerollten Commit oder die Artefaktkennung, die laufenden PHP- und Webserver-Versionen sowie den Zeitpunkt der Momentaufnahme fest. Bewahren Sie eine Kopie außerhalb des möglicherweise kompromittierten Hosts auf. So kann nach der Änderung verglichen werden, was passiert ist, und ein Nebeneffekt des Patchens lässt sich von einem bereits vorhandenen Eindringen unterscheiden.

Kann der Hotfix nicht sofort angewendet werden, sollte die Exposition während der Vorbereitung der Bereitstellung reduziert werden. Das australische Advisory empfiehlt, bei Bedarf auf eine Version mit dem Patch zu aktualisieren und, falls für die eingesetzte Version kein Patch verfügbar ist, den Zugriff einzuschränken und zu überwachen. Praktisch kann das bedeuten, den öffentlichen Zugriff vorübergehend zu begrenzen, den verwundbaren Endpunkt an einer vertrauenswürdigen Edge-Kontrolle zu sperren oder die Website in einen kontrollierten Wartungsmodus zu versetzen. Eine Regel in der Web Application Firewall kann opportunistischen Datenverkehr reduzieren, ist aber nur eine kompensierende Maßnahme und kein Ersatz für den Adobe-Fix.

Bei nicht unterstützten Zweigen ist besondere Vorsicht angebracht. Sansec berichtet, dass die von Adobe getestete Hotfix-Abdeckung an unterstützte Releases mit dem Kennzeichen 2026-August gebunden ist und ältere Zweige zwar betroffen, aber von Adobe nicht in gleicher Weise verifiziert seien. Nutzt eine Organisation eine Version außerhalb des Supports, sollte sie den Commerce-Verantwortlichen oder einen qualifizierten Incident-Response-Dienstleister einbeziehen, ein unterstütztes Upgrade oder einen geprüften Backport testen und keine ungetestete Änderung in einer Umgebung vornehmen, die weiterhin aktiv Transaktionen verarbeitet.

Patchen beendet die Aufgabe nicht

Der häufigste operative Fehler bei einer aktiv ausgenutzten Schwachstelle besteht darin, bei der Versionsprüfung aufzuhören. Ein Patch verhindert, dass der bekannte Angriffsweg erneut funktioniert. Er entfernt jedoch keinen Code, der vor dem Patch geschrieben wurde, macht kopierte Zugangsdaten nicht ungültig und zeigt nicht, auf welche externen Systeme ein kompromittierter Prozess zugegriffen hat.

Beginnen Sie die Untersuchung mit einer präzisen Zeitleiste. Ermitteln Sie für jede internetseitige Commerce-Instanz, wann sie verwundbar war, wann der Endpunkt /graphql erreichbar war, wann erste verdächtige Anfragen auftauchten, wann der Hotfix installiert wurde und ob die Anwendung danach neu gestartet oder erneut ausgerollt wurde. Beziehen Sie CDN-, WAF-, Reverse-Proxy-, Load-Balancer-, Webserver-, PHP-FPM-, Anwendungs-, Betriebssystem-, Scheduled-Task- und Cloud-Audit-Logs ein. Verwenden Sie eine einheitliche Zeitzone und bewahren Sie die Originaldateien auf, bevor Sie sie filtern oder rotieren.

Suchen Sie auf mehreren Ebenen nach Belegen, statt sich auf ein einzelnes Muster zu verlassen. Prüfen Sie am Rand ungewöhnliche Anfragen an GraphQL, Anfragespitzen, die nicht zum normalen Shopverkehr passen, unerwartete User-Agents, wiederholte Fehler sowie Datenverkehr von Hosting-Providern oder Netzen ohne Bezug zu legitimen Kunden. Untersuchen Sie in der Anwendung Änderungen an Templates, Aktivitäten bei Benachrichtigungen zu fehlgeschlagenen Zahlungen, unerwartete CMS- oder Konfigurationsänderungen, neue Administratorkonten, veränderte Integrationsberechtigungen und ungewöhnliche Schreibvorgänge in Report-, Media- oder Cache-Verzeichnissen. Suchen Sie auf dem Host nach neuen Prozessen, neuen geplanten Aufgaben, veränderten Startdateien, unerwarteten PHP-Dateien und ausgehenden Verbindungen, die der Commerce-Prozess normalerweise nicht herstellt.

Sansec beschreibt ein zweistufiges Muster, bei dem ein Angreifer Code im Zusammenhang mit dem Magento-Template-System vergiftet und Magento später dazu bringt, diesen Code über einen Pfad für Benachrichtigungen zu fehlgeschlagenen Zahlungen zu rendern. Dieses Verhalten liefert Verteidigern nützliche Fragen, ohne den Exploit nachstellen zu müssen: Haben Benachrichtigungen zu fehlgeschlagenen Zahlungen plötzlich zugenommen? Wurden templatebezogene Daten außerhalb einer regulären Bereitstellung verändert? Hat ein Commerce-Worker ungefähr zur selben Zeit ungewöhnliche Dateien geschrieben oder eine ungewöhnliche ausgehende Verbindung aufgebaut? Ein einzelnes Signal ist kein Beweis. Abgelehnte Zahlungen, Erweiterungen und geplante Wartungsarbeiten können ähnliche Ereignisse erzeugen. Befunde müssen deshalb mit Bereitstellungsdaten und Anfrage-Logs korreliert werden.

Fügen Sie beim Einholen von Hilfe keine sensiblen Logs, Kundendaten, Sitzungsdaten oder Geheimnisse in öffentliche Issue-Tracker ein. Teilen Sie nur die minimal erforderlichen, bereinigten Belege mit dem Adobe-Support, einem vertrauenswürdigen Incident-Response-Dienstleister oder der zuständigen nationalen Cyber-Sicherheitsbehörde. Das Advisory aus Singapur verweist Administratoren auf das Hersteller-Bulletin und den NVD-Eintrag. Das australische Advisory nennt einen Kanal für Unterstützung und die Meldung von Vorfällen.

Geheimnisse, die rotiert werden müssen

Findet die Untersuchung eine Ausnutzung oder kann der Betreiber nicht belegen, dass keine Ausnutzung stattgefunden hat, sollten Zugangsdaten in einer Reihenfolge rotiert werden, die dem Angreifer möglichst wenig Gelegenheit gibt, der Änderung zu folgen. Sichern Sie zuerst die Identitäts- und Administrationssysteme, mit denen der Host und die Bereitstellung verwaltet werden. Rotieren Sie anschließend den Commerce-Verschlüsselungsschlüssel und jedes Geheimnis, das möglicherweise durch ihn geschützt, aus ihm abgeleitet oder gemeinsam mit ihm gespeichert wurde.

Dazu können Administratorkennwörter, REST-, SOAP- und GraphQL-Integrationstokens, OAuth-Clientgeheimnisse, Zugangsdaten von Zahlungsdienstleistern, Datenbankpasswörter, SSH-Schlüssel, Bereitstellungsschlüssel, Cloud-Zugangsdaten und API-Schlüssel von Erweiterungen gehören. Rotieren Sie diese am jeweiligen Ausstellungsort und ändern Sie nicht nur einen Wert in der Commerce-Konfiguration. Wer beispielsweise eine Zahlungszugangsdaten im Shop ändert, macht den alten Schlüssel beim Zahlungsanbieter nicht ungültig. Der Anbieter muss ihn ausstellen oder widerrufen. Dasselbe gilt für Cloud-IAM, Quellcodeverwaltung, Monitoring, Versand- und Marketingplattformen.

Die Rotation sollte von einer Zugriffsprüfung begleitet werden. Entfernen Sie ungenutzte Integrationen, verringern Sie Berechtigungen, verkürzen Sie Tokenlaufzeiten, sofern dies praktikabel ist, bestätigen Sie den Widerruf alter Zugangsdaten und prüfen Sie Authentifizierungslogs auf Nutzung nach der letzten legitimen Bereitstellung. Wurde dasselbe Geheimnis in einer anderen Umgebung wiederverwendet, behandeln Sie diese Umgebungen bis zur Prüfung als exponiert. Eine Rotation, bei der eine vergessene Kopie auf einem Staging-Host oder in einer CI-Variablen aktiv bleibt, erzeugt nur den Anschein einer Wiederherstellung.

Das alleinige Ändern des Commerce-Verschlüsselungsschlüssels ist keine vollständige Reaktion. Es kann künftig mit dem neuen Schlüssel geschriebene Werte schützen, aber nichts zurückholen oder löschen, was ein Angreifer bereits gelesen hat. Es entfernt auch keine Webshell, keine geplante Aufgabe, keine veränderte Erweiterung und keine gestohlene Sitzung. Die Rotation von Zugangsdaten gehört nach der Beweissicherung und zusammen mit der Bereinigung des Hosts zum Vorgehen; sie ersetzt diese Maßnahmen nicht.

Wer handeln muss

Betreiber von Adobe Commerce oder Magento Open Source sollten jeden Shop, jede regionale Bereitstellung, jede Staging-Umgebung, jede Notfallwiederherstellungskopie und jede von Partnern verwaltete Instanz inventarisieren. Ein Unternehmen kennt möglicherweise seinen Hauptshop, übersieht aber eine ruhende Markenseite, ein internes Bestellportal oder eine Cloud-Bereitstellung, die von einer Agentur gepflegt wird. Das Inventar sollte den exakten Softwarezweig, öffentliche Hostnamen, die GraphQL-Erreichbarkeit, den Patch-Status, den Verantwortlichen und den Zeitpunkt der letzten verifizierten Prüfung enthalten.

Managed-Service-Provider und E-Commerce-Agenturen sollten Kunden informieren, gemeinsam genutzte betriebliche Abhängigkeiten ermitteln und nachweisen, welche Umgebungen gepatcht wurden. Die Aussage, eine Plattform sei auf dem aktuellen Stand, ist schwächer als ein Bereitstellungsprotokoll mit Hotfix, betroffener Instanz und Prüfzeitpunkt. Kunden sollten diesen Nachweis sowie eine Bestätigung verlangen, dass Logs erhalten geblieben sind, wenn der Dienst vor dem Fix exponiert war.

Zahlungs-, Fulfillment-, Kundenservice- und Analyseteams müssen einbezogen werden, sobald Hinweise auf Codeausführung oder offengelegte Geheimnisse vorliegen. Ihre Systeme laufen möglicherweise nicht mit Magento, können aber dessen API-Zugangsdaten vertrauen oder Ereignisse aus dem Shop akzeptieren. Die Sicherheitsprüfung sollte daher auch nachgelagerte Tokens, Webhook-Signaturgeheimnisse, Dienstkonten und ungewöhnliche Aktivitäten in verbundenen Systemen abdecken.

Sicherheitsteams sollten das Problem zugleich als Schwachstellenmanagement und als Incident Response behandeln. Das Schwachstellenmanagement beantwortet, ob die Software jetzt geschützt ist. Die Incident Response beantwortet, ob die Organisation bereits betroffen war. Getrennte Arbeitsstränge verhindern einen häufigen Fehler: Ein erfolgreicher Patch wird mit einer erfolgreichen Untersuchung verwechselt.

Was aus den verfügbaren Belegen nicht folgt

CVE-2026-75650 ist ernst, aber die Fakten rechtfertigen nicht jede denkbare Behauptung. Öffentliche Berichte bestätigen aktive Ausnutzung und einen kritischen, nicht authentifizierten Pfad zur Codeausführung. Daraus folgt nicht, dass jeder Magento-Shop kompromittiert wurde, dass bei jedem Opfer Zahlungsdaten von Kunden gestohlen wurden oder dass eine bestimmte Gruppe für alle beobachteten Aktivitäten verantwortlich ist. Betreiber sollten solche Aussagen ohne Belege aus der eigenen Umgebung nicht veröffentlichen.

Ebenso beweist eine verdächtige IP-Adresse im Log nicht, dass die Anfrage erfolgreich war. Das Fehlen eines bekannten Indikators beweist umgekehrt nicht, dass ein Angriff fehlgeschlagen ist. Angreifer können Infrastruktur und Payloads verändern. Die Erkennung sollte Anfragebelege, Auswirkungen in der Anwendung, Datei- und Prozessänderungen, Authentifizierungsaufzeichnungen und den Bereitstellungszeitpunkt zusammenführen. Bleibt Unsicherheit bestehen, sichern Sie den Host und eskalieren Sie zur forensischen Prüfung, statt verdächtige Dateien sofort zu löschen.

Die gleiche Zurückhaltung gilt für Gegenmaßnahmen. Eine CDN-Regel, eine WAF-Signatur, ein deaktivierter Endpunkt oder eine Netzwerkbeschränkung kann das Risiko senken. Jede dieser Kontrollen kann jedoch falsch konfiguriert oder über eine alternative Route umgangen werden. Eine kompensierende Maßnahme braucht einen Verantwortlichen, ein Ablaufdatum und einen Verifikationstest. Sie darf nicht zum dauerhaften Vorwand werden, einen nicht unterstützten und ungepatchten Shop weiterzubetreiben.

Eine praktikable Reaktionsfolge

Für einen weiterhin exponierten Shop lässt sich die Reihenfolge während eines Vorfalls klar zuweisen: Instanz und Verantwortlichen bestimmen, den Zugriff einschränken, falls der Hotfix nicht sofort installiert werden kann, Logs und ein sauberes Backup sichern, den Adobe-Hotfix für CVE-2026-75650 einspielen, die Bereitstellung anhand des laufenden Artefakts verifizieren und die öffentliche Erreichbarkeit erneut prüfen. Beginnen Sie nicht damit, Beweise zu löschen oder aus einem ungeprüften Backup neu aufzubauen.

Für einen Shop, der nach dem 4. September gepatcht wurde, sollte die Zeit vor dem Patch als Untersuchungsfenster gelten. Vergleichen Sie Edge-Anfragen mit Anwendungslogs, prüfen Sie Änderungen an Templates und CMS, untersuchen Sie Benachrichtigungen zu fehlgeschlagenen Zahlungen, suchen Sie nach unerwarteten Dateien und geplanten Aufgaben, analysieren Sie ausgehende Verbindungen und kontrollieren Sie die Authentifizierung an Administrations- und Integrationssystemen. Gibt es ein glaubwürdiges Zeichen für Codeausführung, isolieren Sie den Host oder verlagern Sie den Shop in eine bekannte, saubere Umgebung, während die Reaktion weiterläuft.

Bei bestätigter oder wahrscheinlicher Kompromittierung sollte das betroffene System erhalten bleiben. Rotieren Sie Zugangsdaten bei den ausstellenden Systemen, bauen Sie bei Bedarf aus vertrauenswürdigen Artefakten neu auf, prüfen Sie verbundene Dienste, informieren Sie Kunden oder Behörden, falls dies nach geltendem Recht erforderlich ist, und dokumentieren Sie die Belege für die abschließende Risikobewertung. Der Wiederherstellungsplan sollte eine Überwachung nach der Rückkehr in den Betrieb enthalten. Patchen und Neuaufbau garantieren nicht, dass jedes abhängige Konto bereits gesichert wurde.

Die wichtige Lehre für die E-Commerce-Sicherheit

Die unmittelbare Lehre lautet, den Adobe-Hotfix einzuspielen. Die weitergehende Lehre betrifft den Unterschied zwischen einem sauberen Patch-Signal und einer sauberen Umgebung. Ein verwundbarer Shop kann zum Problem für Identitäten und Zahlungssysteme werden, wenn die Anwendung Zugriff auf Geheimnisse, Kundenabläufe und automatisierte Integrationen hat. Die Sicherheitsgrenze verläuft nicht nur entlang des Commerce-Pakets. Sie umfasst auch Server, Bereitstellungspipeline, Erweiterungen, Endpunkte, Zugangsdaten und die angeschlossenen Dienste.

CVE-2026-75650 zeigt außerdem, warum ein Notfall-Fix einen Beweisplan braucht. Beginnt die Ausnutzung, bevor ein Herstellerpatch existiert, muss die Organisation zwei Dinge parallel tun: die verbleibende Angriffsfläche verkleinern und feststellen, was während des Expositionsfensters passiert ist. Dieses Vorgehen liefert ein ruhigeres und besser begründbares Ergebnis als sowohl panikartige Abschaltungen als auch die unbelegte Zusicherung, eine gepatchte Version bedeute das Ende des Vorfalls.

Für betroffene Betreiber ist die Entscheidung daher eindeutig. Spielen Sie den unterstützten Adobe-Hotfix vorrangig ein, bestätigen Sie, dass der Fix in der Live-Bereitstellung vorhanden ist, und untersuchen Sie jede Instanz, die vor dem Patch exponiert war. Sobald verdächtige Aktivitäten auftreten, sollte angenommen werden, dass Geheimnisse gelesen worden sein könnten, bis die zuständigen ausstellenden Systeme Rotation und Widerruf bestätigen. Der Shop kann zum Normalbetrieb zurückkehren, wenn die Software repariert, die Umgebung untersucht, verbundene Zugangsdaten kontrolliert sind und die Belege diese Schlussfolgerung tragen.

Quellen

Die Einordnung basiert auf dem Sicherheitsbulletin APSB26-146 von Adobe, den Adobe-Experience-League-Release-Notes zum Hotfix VULN-39341, dem Advisory des Australian Cyber Security Centre, dem Advisory der Cyber Security Agency of Singapore, der Recherche von Sansec zu StyleSmuggler sowie dem CVE-Eintrag des National Institute of Standards and Technology.