パッチは当てていました。7月も8月も、security:patch-statusもクリーンでした。それでも、その店はStyleSmugglerの最初の被害者になりました。修正のないまま悪用が続くこの脆弱性が突いたのは、多くのEC事業者が防御の目安にしてきた指標そのものです。
セキュリティ企業Sansecは2026年9月5日、Magento Open SourceとAdobe Commerceに未修正の脆弱性「StyleSmuggler」があり、悪用が続いていると公表した。認証なしにリモートでコードを実行できる。2.4.9を含む現行の全バージョンが影響を受け、Sansecはクリーンな2.4.7、2.4.8、2.4.9で攻撃連鎖を再現した。最初の被害店舗は2.4.6-p15で、2026年7月と8月のパッチを適用済みだった。
悪用の初確認は9月4日22時20分UTCである。攻撃は2段階で、Magentoのテンプレート機能にコードを混入させ、支払い失敗の通知メールの描画時に実行させる。成功するとRust製のバックドアが常駐する。Adobeは速報もCVE番号も出していない。
From: 
StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack
【編集部解説】
今回の事案でもっとも重いのは、最初に被害が確認された店舗が、パッチという軸では「きちんとやっていた店」だったという事実です。
その店舗はMagento Open Source 2.4.6-p15。Adobeが2026年7月と8月に出したセキュリティパッチをいずれも適用済みで、security:patch-status の結果もクリーンでした。2.4.6系でAdobeが提供していた最新の水準です。
未修正のゼロデイなのだから当然だ、という見方はあります。ゼロデイが存在する以上、パッチ適用状況だけでは安全を保証できない。それ自体は今回はじめて生じた性質ではありません。StyleSmugglerが示したのは、その限界の具体的な形です。パッチを当てる意味が薄れたわけではありません。最新の水準を保ったうえで、別の観測を足す必要がある、ということです。
innovaTopiaは2025年10月、同じSansecが公表した「SessionReaper」（CVE-2025-54236）を取り上げ、パッチ公開から6週間の時点で約62%の店舗が未適用のままだと報じました。あのときの論点は「当てていない店が破られる」でした。今回はその裏返しです。
Sansecの公表を並べると、Magentoを狙う攻撃の速度も見えてきます。2026年3月のPolyShellでは、1時間のうちに471店舗が攻撃の波を受けました。今回は、悪用の初確認から50分後に、Disrex Groupが後に対応することになる店舗が侵害されています。この2件は、侵害の立ち上がりが時間単位になり得ることを示しています。日単位の猶予が常にあるとは考えないほうがよさそうです。
メールが届いていないことは、無事の証明になりません
攻撃は2段階で動きます。まずMagento自身が通常の運用で書き出すファイル、たとえば失敗レポートやログにコードを混ぜ、次に「Payment Transaction Failed Reminder」という標準の通知メールを発生させて、その描画の最中にコードを走らせます。
ここが厄介なところで、誰かがメールを開く必要はありません。Magentoが内部で描画した時点で終わっています。さらにSansecは、メールの配送が失敗した場合でも攻撃は成立すると書いています。「不審なメールは届いていない」は、この件では手がかりになりません。
逆に、支払い失敗の通知が不自然にまとまって出ているなら、調べる理由になります。ただし正当な決済の否認でも同じ通知は出るため、これは単独の証拠ではなく、ほかの手がかりと束ねて読むものです。
目印は動いている
見落としやすい点があります。Sansecの記事は公開後も更新されていて、9月6日に持続化の指標が増えました。公開直後に挙がっていた目印は [kworker/u:8:0] を装った常駐プロセスでしたが、いまはもう1つの系統が並んでいます。フォントキャッシュの正規のコマンド名（fc-cache）を借りるもので、置き場所もcronの登録も別枠です。C2の一覧も3件増えました。
つまり一度チェックして終わりにできない性格の事案です。確かめるべきなのは報道の日付ではなく、自分が参照した侵害指標が、いつ時点のものかです。公開から1日ほどのあいだに、目印の記述そのものも整理されています。更新前の一覧だけで確認を済ませた店舗は、いま出ている指標で見直す必要があります。この記事に挙げた目印も、お読みになる時点では古くなっている可能性があります。原典を確認してください。
見分け方には2つの筋があります。ひとつは、カーネルスレッドを装うものへの対処です。通常のkworkerはroot所有で表示され、ユーザー空間のメモリ（RSS）は0です。サイトのユーザー権限で動き、RSSを持ちながら角カッコ付きの名前を名乗っているプロセスは、強い異常の手がかりになります。もうひとつは、正規のユーティリティの名前をそのまま借りるものです。こちらは角カッコが付かないため、プロセス名だけでは見分けられません。実行されているファイルの場所と、cronの登録内容まで合わせて見る必要があります。
なおSansecは、このバックドアが実際に使われた形跡は現時点で確認されていないとしています。そのうえで、Shield利用者向けの説明のなかで、不審なプロセスが見つかった場合はMagentoの認証情報を入れ替えるよう推奨しています。
静かなホストは、安全なホストではありません
ここは今回もっとも実務に効く論点だと考えています。
Sansecは侵害指標としてC2のアドレスを列挙しています。99.84.67.186:443 のTLS上のWebSocketに加え、NTPを模したUDP通信を使うホストが並びます。いずれも、境界の監視で追える形です。
一方、Disrex Groupが対応した店舗では違う絵が出ました。200MBを超えるパケットキャプチャを2件取ったにもかかわらず、当時Sansecが挙げていた2つの既知ホストへの通信は、1パケットも含まれていませんでした。ある店舗では、実装は外部へのソケットをまったく開かず、代わりに 127.0.0.1:6379 へ28本の接続を張って、店自身のRedisからMagentoのセッションを読み書きしていました。
少なくともこの店舗では、当時照合できた既知のC2への通信は確認されませんでした。境界側で既知のC2だけを見ていても、この実装は捉えられません。「既知のC2への通信がない」ことは、無事の証明にならないということです。プロセスとファイル、そしてcronを直接見る必要があります。
同じことは走査の範囲にも言えます。実装が置かれるのはサイトのドキュメントルートではなく、ユーザーのホームディレクトリ配下です。公開ディレクトリだけを対象にしたスキャンは、その横を素通りします。
ベンダーの修正を待つ間に、防御を配った人たちがいます
Adobeからの速報、CVE番号、回避策は、9月7日の時点でまだ出ていません。セキュリティ速報の一覧は8月11日のAPSB26-92が最後です。Adobe全体では次の定例が9月8日にあたりますが、Adobe Commerceの修正がそこに含まれるかは未確定で、Sansec自身も「まだ分からない」と書いています。
その空白を埋めたのが、複数の当事者による同日中の動きでした。
Sansecは技術分析を完了させる前に、「いま現に店舗が侵害されているから」として公表に踏み切りました。Shieldのルールは9月5日7時15分UTCに稼働しています。同じ日にDisrex Group、Adobe Commerce開発者のProxiBlue、そしてGraycoreが、それぞれ非公式の緩和策を公開しました。
注目したいのは、DisrexとProxiBlueが互いに連絡を取らないまま、同じ3つのメソッドに、同じくコマンドライン以外での実行を拒む判定を入れていたことです。独立した2者が同じ緩和案へ収束したという事実は、その案の技術的な妥当性を支えます。ベンダーの修正がない状況で、分散した実務者がここまで速く動けたことは、率直に評価されてよいと思います。
同時に、公開した本人たちが自分の成果の性格を丁寧に切り分けている点も、記録に値します。Disrexはリポジトリに、これはインシデント対応の最中にAIの支援を受けて数時間で書いたもので、レビューは通していないと明記しました。どの部分が実際の侵害の観測に基づき、どの部分が未検証かも書き分けています。Graycoreも「完璧ではないだろうが、現時点での自分の最善の見立てだ」と添えています。
急いで作ったものを、急いで作ったと書いたうえで配る。生成AIが緊急対応の速度を押し上げる場面が増えていくなかで、この作法は参照される価値があります。
DisrexとGraycoreは、公開した措置が恒久的な修正ではなく緩和であることを明記しています。ProxiBlueも同じガードを公開していますが、位置づけを同じ言葉では書いていません。Disrexのサーバー側ルールについては、同社自身が、URLのクエリ文字列を見るだけなのでPOSTやJSONの本体で同じ値を送られると通過してしまうと説明しています。入口をひとつ塞ぐものであり、脆弱性そのものは残ります。
Sansecが示した手順のうち、1つめと2つめは同社の製品であるShieldとeComscanです。Shieldを利用していない店舗には、Adobeの正式な修正が出るまでGraphQLを一時的に無効化する案を示しています。ただし、この判断は構成によって変わります。ヘッドレスやPWAはGraphQLへの依存が強く、Hyväも一部の機能でMagentoのGraphQL APIを使うため、公式のドキュメントは複数のGraphQLモジュールを有効にしておくよう求めています。無効化する前に、自分の店が実際に何へ依存しているかを確かめる必要があります。
検知の範囲についても、絵はまだ描かれている途中です。Sansecの確認手順は var/report/ を対象にしていますが、Disrexが扱った2店舗はいずれも var/log/system.log を経由して汚染されていました。両方を見るのが現時点の答えです。Sansec自身、ガジェットチェーンとドロッパー、実装の詳細な分析は続報で出すと予告しています。
日本のEC事業者にとって
2026年9月7日の時点で、確認できた公開情報の範囲では、日本国内の被害事例は見つかっていません。SansecとDisrexの観測はいずれも各社の顧客と対応の範囲に依存しており、国内の被害の有無を推し量れるデータは、まだありません。
一方で、Magentoは国境を選びません。そして制度の側は、すでにこの方向へ動いています。クレジット取引セキュリティ対策協議会のクレジットカード・セキュリティガイドラインは、2025年4月から、カード情報を保持しない加盟店にも自社システムとWebサイトの脆弱性対策を求めています。構築・運用を外部に委託していても、加盟店が担う役割は残るという整理です。「ベンダーに任せている」で完結しない設計になっている、ということです。
Adobeは2026年7月14日から、正式なCVEを伴うセキュリティ速報の公開機会を、第2・第4火曜の月2回に増やしました。Adobe Commerceが毎月2回更新されるという意味ではありませんが、修正を届ける機会そのものを増やす方向に舵を切っていたのは確かです。9月8日はその次の第2火曜にあたります。
順序を間違えない
最後に、実務でもっとも間違えやすい点を。侵害が疑われるホストでは、確認と証拠の保全が先です。
Disrexが今回の対応で示した順序は、侵害の確認と証拠の保全、持続化と実行中のプロセスの封じ込め、影響範囲の調査と認証情報の入れ替え、そのうえで入口の緩和、というものでした。持続化の登録が1つとは限らない点にも注意が要ります。入口を塞ぐだけでは、すでに動いているバックドアやcronによる持続化は消えません。一方で、入口の緩和には次の侵入を防ぐ意味があります。「緩和したから駆除できた」と考えないことと、証拠を壊す前に状況を確認すること。この2つが要点です。
パッチ水準という一枚の指標に運用を預けてきたやり方は、この事案を境に、プロセス、ファイル、cron、ログ、そしてメールの送出量といった複数の面を束ねて読む運用へ移っていくのだと思います。手間は増えます。けれども、増えた手間の分だけ、自分の店について答えられることが増えます。StyleSmugglerが開いたのは、たぶんそういう扉です。
【関連記事】
Adobe Commerce・Magento標的の脅威、SessionReaper攻撃が急拡大
2025年10月の記事。同じSansecが公表したSessionReaperを扱い、パッチ公開から6週間で約62%が未適用だったと報じた。
Adobe、ColdFusionなど計12件の脆弱性を修正—CVSS 10.0が7件と「月2回配信」への転換
2026年7月の記事。Adobeがセキュリティ速報の公開機会を月2回へ増やした経緯と、その背景にあるAIによる脆弱性発見の加速を扱う。
RIZAP「APORITO」に不正スクリプト｜カード情報流出の可能性
2026年8月の記事。国内ECサイトでのカード情報流出を扱い、加盟店に求められる脆弱性対策の制度的な位置づけまで整理している。
【編集部後記】
Disrexが公開した侵害指標の一覧には、訂正の跡が残っています。当初そこには攻撃元として2つのアドレスが載っていましたが、実際は自社のサーバーが動作確認のために自分自身へアクセスしたものでした。攻撃の痕跡を拾うのと同じ検索が、自分のテストまで拾ってしまったと説明が添えてあります。
人手も時間も足りない現場で、防御側は自分の足跡と攻撃者の足跡を選り分けています。公開したあとに誤りを見つけて直し、その経緯まで残す。この地味な作業のほうが、たぶん多くの店を守ります。
【用語解説】
ゼロデイ
修正が提供されていない状態の脆弱性。パッチが存在しないため、適用状況では防げない。
security:patch-status
Magentoのコマンド。適用済みのセキュリティパッチと未適用のものを一覧する。最初の被害店舗ではこれがクリーンだった。
2.4.6-p15
Magentoのバージョン表記。末尾の「-p」に続く数字がセキュリティパッチの適用段階を示す。数字が大きいほど新しい。
GraphQL
画面側とサーバー側でデータをやり取りする仕組み。Magentoでは在庫や価格、カートの操作に使われる。
侵害指標
侵害の痕跡となる手がかり。IPアドレス、ドメイン、ファイルのハッシュ値、プロセス名などが含まれる。調査の進展に応じて増減する。
C2
Command and Control の略。侵入後のプログラムに指示を送る、攻撃者側のサーバーを指す。
kworker
Linuxのカーネルが内部処理のために動かすスレッド。プロセス一覧では角カッコ付きの名前で表示され、root所有となる。
RSS
プロセスがユーザー空間で実際に使っている物理メモリの量。通常のkworkerではこれが0になる。
cron
決まった時刻や間隔でプログラムを自動実行するLinuxの仕組み。攻撃者が居座り続けるためにも使われる。
Redis
メモリ上でデータを扱う高速なデータストア。Magentoではセッションやキャッシュの保存先として広く使われている。
SessionReaper
2025年9月にSansecが公表したMagentoの脆弱性（CVE-2025-54236）。認証なしのリモートコード実行を許した。
PolyShell
2026年3月にSansecが公表したMagentoの脆弱性。REST API経由で実行可能なファイルを置ける問題だった。
APSB26-92
Adobeのセキュリティ速報に付く番号。APSBに続く数字は年と通し番号を表し、これは2026年8月11日公開のものにあたる。
クレジットカード・セキュリティガイドライン
クレジット取引セキュリティ対策協議会が策定する指針。日本クレジット協会が事務局を務め、EC加盟店に求められる措置を定めている。
【参考リンク】
Sansec（外部）
StyleSmugglerを発見し命名したオランダのセキュリティ企業。eコマースに特化し、世界の店舗を狙う攻撃を継続的に監視している。
Sansec｜StyleSmuggler advisory（外部）
Sansecによる本件の一次情報。影響を受けるバージョン、店舗の確認手順、侵害指標、時系列を掲載し、判明ごとに更新が続いている。
Disrex｜stylesmuggler-mitigation（外部）
Disrexが公開した緊急の緩和策。ウェブサーバーの規則、CLIガード、侵害の走査手順を、実際の対応で得た知見とともにまとめている。
Disrex｜IOC.md（外部）
Disrexがまとめた侵害指標。攻撃元、ハッシュ、投下先を新しい順に並べ、自社サーバーを誤って載せた際の訂正の経緯も残している。
Disrex｜CLEANUP.md（外部）
Disrexが公開した駆除の手順。持続化の除去、プロセスの停止、汚染ファイルの削除を、必ず守るべき実行の順序とともに示している。
Graycore｜magento2-style-smuggler-patch（外部）
Graycoreが公開したMagento 2向けの緩和モジュール。攻撃連鎖上の3点を硬化させるもので、恒久的な修正ではないと明記されている。
ProxiBlue｜DI scanner guard（外部）
ProxiBlueが公開したガード。Disrexとは独立に、同じ3つのメソッドへ同じ判定を入れたもので、両者の収束が確認できる。
Adobe｜Adobe Commerce セキュリティ速報（外部）
Adobe Commerceのセキュリティ速報の一覧。執筆時点で最新は2026年8月11日のAPSB26-92であり、本件の速報はまだない。
Hyvä Docs｜Getting Started（外部）
Hyväテーマの導入手順。有効にしておくMagentoのGraphQLモジュールが列挙されており、GraphQL無効化の判断材料になる。
Sansec｜PolyShell advisory（外部）
SansecによるPolyShellの速報。2026年3月に確認された別のMagento脆弱性で、修正のないまま悪用が広がった事例である。
Sansec｜Mass PolyShell attack wave hits 471 stores in one hour（外部）
本文で触れた471店舗の出典。1時間のうちに攻撃の波が広がった経緯を、Sansec自身が記録している。
【参考記事】
Hackers Actively Exploiting Magento and Adobe Commerce 0-Day RCE Vulnerability（外部）
Disrexの観測を引き、実装のサイズやcronの間隔、Redisへの28本の接続といった数値を交えて攻撃の全体像を伝えている。
Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores（外部）
Nexcessなど事業者の対応や、Graycoreが硬化させた3点を具体的に報じている。非公式の緩和策を横断して整理した記事である。
StyleSmuggler: Emergency Magento 2 Mitigation & Recovery（外部）
2店舗の対応にあたった技術者による記録。ドキュメントルート限定の走査をすり抜けた事例を、封じ込めと再構築の手順とともに書いている。
StyleSmuggler: Magento Zero-Day RCE Exploited in the Wild（外部）
Sansecが9月4日22時40分UTCにキャンペーンを発見し、数時間で連鎖を再現した経緯を、実証コードの公開状況とあわせて整理している。
