Magento／Adobe Commerce のゼロデイ脆弱性 StyleSmuggler：実環境での悪用を観測

Hackers Actively Exploiting Magento and Adobe Commerce 0-Day RCE Vulnerability

2026/09/06 CyberSecurityNews — Magento Open Source／Adobe Commerce のゼロデイ脆弱性 StyleSmuggler が、オランダの EC セキュリティ企業 Sansec により公表された。2026年9月5日に公表されたこの脆弱性は、オンライン・ストアを完全に掌握するために積極的に悪用されており、現時点では公式パッチが提供されていない。実環境での攻撃は 9月4日に始まったと Sansec は指摘している。この脆弱性を悪用する未認証の攻撃者は、脆弱な環境で任意のコードを実行でき、現時点でストアが侵害されていることから、完全な技術分析が完了する前に調査結果を早期公開したと同社は述べている。

StyleSmuggler は、最新バージョンの 2.4.9 を含む、すべての Magento／Adobe Commerce に影響を及ぼし、悪用に認証は一切必要ない。Sansec は、Magento Open Source 2.4.7／2.4.8／2.4.9 のクリーン・インストール環境で認証を必要としない攻撃チェーン全体を再現し、この脆弱性が特定の古いビルドだけに存在する問題ではないことを確認した。

さらに懸念されるのは、最初に確認された被害者が 2026年7月／8月のすべてのセキュリティ・パッチを適用した 2.4.6-p15 を実行していたことである。つまり、セキュリティ・パッチを完全に適用したストアも、パッチ適用が不十分なストアと同様に侵害されていた。

9月6日の時点において Adobe は、セキュリティ・アドバイザリの公開／CVE 識別子の割り当て／公式の修正プログラム／回避策の提供を行っていない。最新の Commerce セキュリティ情報も 8月11日付のままであり、今回の脆弱性に関する公式な対応は確認されていない。

このエクスプロイトは、単一の明確なインジェクション・ポイントを悪用するものではなく、Magento 自身のテンプレート・レンダリング／メール・システムを利用して 2 段階で進行する。

Magento／Adobe Commerce のゼロデイ RCE

第 1 ステージでは、攻撃者が GraphQL リクエスト内の “styles” プロパティを操作して既存の入力に対するサニタイズ処理を回避し、Magento が通常動作の中で書き込む決済失敗レポートなどのファイルの中に、悪意の PHP コードを埋め込む。

侵害された 2 つのストアへ対応した、Magento ホスティング企業 Disrex Group の独立分析では、注入されたテキスト内の細工されたディレクティブにより Magento 自身のクラスチェーンが実行され、本来は Command-Line Dependency-Injection Compiler を介してのみ実行されるべきコードが動作したという。最終的に判明したのは、攻撃者による悪意のコードが埋め込まれたログファイルがインクルードされることである。

第 2 ステージでは、StyleSmuggler が意図的に Magento の標準の “Payment Transaction Failed Reminder” メールを送信させ、Magento がそのメッセージを内部でレンダリングする瞬間に、埋め込まれた悪意のコードが実行される。つまり、この攻撃を成功させるために誰かがメールを開くことも、メール自体を受信することも不要である。コード実行が開始されると、PHP ドロッパーは 6 種類の PHP 関数を順番に試し、プロセスを生成できる関数を発見すると、永続的なインプラントのダウンロードと起動を行う。

Disrex によると、このマルウェアは約 1.9 MB の小型で静的リンクされた Rust バイナリであり、x86-64／ARM64 の両アーキテクチャ向けにコンパイルされている。また、”[kworker/u:8:0]” という Linux カーネル・スレッドを装い、crontab のスプール・ファイルへ直接書き込まれた cron エントリーにより 5 分ごとに再起動されるが、通常のシステムログは残さない。

このマルウェアは、単純な検査を積極的に回避するため、感染の検出が見た目以上に難しい。正規の Linux カーネル・ワーカー・スレッドは root が所有し、常駐メモリを消費しないため、Web サイトのユーザー・アカウントで “[kworker]” という角括弧付きのプロセスが動作し、実際にメモリを使用している場合は、侵害を示す危険な兆候と捉えるべきだ。

さらに Disrex が発見したのは、メモリ上で実行されているバイナリとディスク上のファイルが異なる場合があることだ。したがって防御側に求められるのは、ファイル／実行中のプロセスの両方からハッシュを取得して確認することである。

侵害されたストアの 1 つでは、インプラントはインターネットへ向けた外部接続を一切行わず、サイト自身の Redis インスタンスへ 28 件の同時接続を確立して、稼働中の Magento セッション・データを読み取っている。この仕組みは、ネットワークベースの監視からほぼ見えない状態で動作していた。

Sansec の検出ガイダンスでは、Magento の “var/report” ディレクトリからマーカー文字列を検索する方法が示されているが、Disrex が対応した 2 つの侵害ストアでは、”var/log/system.log” を介して悪意のコードが埋め込まれていた。管理者は、”var/report”／”var/log/system.log” の両方を確認する必要がある。

Adobe の次回セキュリティ・リリースは 9月8日に予定されているが、この脆弱性が修正の対象になるとは公表されていないため、ストア運営者は暫定的な対策に頼らざるを得ない状態にある。Headless／Progressive Web App のストア・フロントに依存していないストアに対して Sansec が推奨するのは、GraphQL の一時的な完全無効化である。通常の Classic／Hyva テーマでは、GraphQL を必要としないためである。

その一方で、Disrex／セキュリティ研究者 ProxiBlue／ベンダー Graycore は、それぞれ特定の Magento クラス／メール・テンプレート関数を保護する非公式のコード・パッチを独自に公開している。3 者はいずれも、これらは根本的な修正ではなくハードニング対策であると強調しており、特に Disrex は、同社のルールでブロックできるのは現時点で観測されている攻撃トラフィックのパターンだけで、根本的な脆弱性を修正するものではないと警告している。

なお、エクスプロイト・チェーンとは別のレベルで機能する保護策として、PHP の “proc_open” 関数の無効化／一時ディレクトリの “noexec” オプションによるマウントなども、ドロッパーによるペイロードの起動を阻止する上で有効であることが確認されている。

Magento および Adobe Commerce を対象とするゼロデイの攻撃例が報告されました。本件はテンプレート処理やメール生成の仕組みを悪用したリモートコード実行の問題であり、公式サイトによる修正対応が未完了な段階から攻撃に利用されています。未認証のまま侵入される危険があり、決済情報の窃取や不正なプログラムの常駐といった甚大な被害が生じます。これに対する安全確保の手順は、GraphQL の停止／”var/report” および “var/log/system.log” 内の不審なログの検査／実行中プロセスの監視／PHP 関数の制御／一時領域への実行権限制限となります。被害を防ぎ運用を安全に保つための速やかな作業が求められます。