MagentoとAdobe Commerceに未修正のゼロデイ脆弱性「StyleSmuggler」判明、すでに悪用が確認

要点

• オランダのSansecが、Magento Open SourceおよびAdobe Commerceにおける未修正のゼロデイ脆弱性「StyleSmuggler」を公表した。

• 事前のログインなしでサーバー上で不正なコードを実行され、Linuxカーネルプロセスに偽装したバックドアを設置される恐れがある。

• 2026年9月4日より実際の攻撃が確認されており、最新のセキュリティ更新プログラムを適用した環境でも被害が報告されている。

• 2026年9月6日時点でAdobe公式のパッチは未公開であり、一時的な緩和策としてGraphQLの無効化などが提示されている。

• オランダのEC向けセキュリティ企業Sansecは2026年9月5日、ECサイト構築プラットフォーム「Magento Open Source」および「Adobe Commerce」において、未修正の重大なゼロデイ脆弱性が悪用されているとするセキュリティアドバイザリを公開した。「StyleSmuggler」と命名されたこの脆弱性を悪用されると、攻撃者はログインを行わずにサーバー上で任意のコードを実行し、バックドア（不正アクセスの裏口）を設置することが可能になるという。Sansecによると、この欠陥を狙った実際の攻撃は9月4日から始まっており、現在進行形で被害が発生しているとして早期の注意喚起に踏み切ったとしている。

認証不要で侵入を許す「StyleSmuggler」と影響範囲

Sansecの報告によると、StyleSmugglerは攻撃者が事前の認証を経ずにサーバー上で悪意あるコードを実行できる深刻な脆弱性である。
影響範囲についてSansecは、最新バージョンである2.4.9を含む現行のすべてのバージョンが影響を受けると説明している。同社はMagento Open Sourceのクリーンなインストール環境（バージョン2.4.7、2.4.8、2.4.9）において、認証なしで一連の攻撃が完結するエクスプロイトチェーンを再現したという。
実際に確認された最初の被害環境はバージョン2.4.6-p15であり、Adobeが提供する2026年7月および8月のセキュリティ更新プログラム（Adobeの速報で2.4.6-2026-augと記載）が適用された最新の状態であったと報告されている。なお、現時点でAdobe Commerceおよびクラウド版（Adobe Commerce on Cloud）における再現テストの結果は公表されておらず、Adobe側も影響を受けるバージョンの確認を行っていない。また、侵害された店舗の具体的な総数についても明らかにされていない。

2段階の攻撃メカニズムと巧妙なバックドア

Sansecの分析によると、今回の攻撃は2つの段階を経て実行される。まず第1段階として、エラー発生時の障害レポートなどMagento自身が生成するファイル内に不正なPHPコードを混入させる。続いて第2段階でプラットフォーム側の標準機能を呼び出し、生成させたその不正ファイルをMagento自身に実行させるという手口である。
攻撃が成功すると、サーバー内には永続的なバックドアとなる不正プログラム（インプラント）が設置される。このインプラントはWeb公開ディレクトリではなく、サイト運用ユーザーのホームディレクトリ配下（~/.local/share/.gvfsd/gvfsd-user）に保存される。さらに、Linuxのカーネルスレッド名である[kworker/u:8:0]にプロセス名を偽装してバックグラウンドで動作するため、一見しただけではOSの正規処理に見えるよう隠蔽されている。
加えて、このプロセスを5分間隔で再起動させる定期実行タスク（cron）も設定される。この設定は通常のコマンドログに残らないよう、/var/spool/cron/crontabs/配下のスプールファイルに直接書き込まれる仕組みになっていた。ある被害環境では同一の実行行が1,728行も重複して書き込まれており、手動で削除しても1秒以内に即座に再登録されるなど、極めて強力な永続化処理が確認されている。

ホスティング事業者のインシデント対応で判明した実態

今回の脆弱性については、Magentoのホスティングおよび開発を手がけるDisrex Groupからも、第三者による独立したインシデント対応情報が公開されている。同社は9月5日に対応リポジトリを公開し、同日に侵害を受けた2つの店舗と、攻撃を受けたものの侵入を免れた1つの店舗に対応したことを明らかにした。
Disrex Groupが解析したインプラントは、x86-64およびarm64向けにビルドされた約1.9MBのRust製プログラムで、解析を妨げるためにシンボル情報が除去された静的リンクバイナリであった。
また、侵害された店舗の1つでは、インプラントが外部との通信を一切行わず、店舗内部のインメモリデータベースであるRedis（ポート6379）に対して28個の接続を維持していた事例が確認された。インプラントはRedisからMagentoのセッション情報を読み取っていたとみられている。なお、インプラントが稼働している最中に取得された200MBを超えるパケットキャプチャからは、外部のC2サーバー（指令サーバー）やダウンロード用ホストへのパケットは一切検出されなかったという。
被害を受けた店舗のうち「Store A」と呼ばれる店舗はSansecの防御製品（Sansec Shield）を導入していたが、Sansecによる防御ルールが配信される数時間前となる9月4日23時10分（UTC）に攻撃を受けていた。なお、Disrex Groupはこの対応リポジトリについて、進行中のインシデント対応の中でAIの支援を受け数時間でまとめられたものであり、未レビューのコマンドや本番環境で未検証のApache向けルールが含まれる旨の注意書きを付している。

公式パッチの状況と推奨される暫定策

2026年9月6日時点において、Adobe公式からは本脆弱性に関するセキュリティアドバイザリ、CVE識別子、公式パッチ、回避策のいずれも公開されていない。Adobe Commerceのセキュリティ速報一覧においても、8月11日の更新以降の情報は掲載されていない状態となっている。Sansecによると、Adobeの次回の定期セキュリティリリースは9月8日に予定されているが、そのリリースに本脆弱性の修正が含まれるかどうかは現時点では不明である。
公式な修正プログラムが提供されるまでの暫定的な防御策として、Sansecは同社の保護製品を利用していない店舗に対し、データ取得用クエリ言語であるGraphQL機能を一時的に無効化することを推奨している。
この点に関してDisrex Groupは、ヘッドレス構成やPWA（プログレッシブウェブアプリ）を採用しているストアフロントではGraphQLが必須となるものの、従来型のクラシックな構成やHyväテーマを採用している多くのストアフロントではGraphQLを無効化しても運用に支障がないと指摘している。
またSansecは、防御ルール適用前に攻撃を受けた顧客について、設置されたバックドアが実際に悪用された痕跡は確認されていないとしつつも、不審なプロセスが検出された場合にはMagentoの認証資格情報（クレデンシャル）を速やかに変更・再発行することを推奨している。