Adobeは2026年9月7日、ECサイト構築プラットフォーム「Adobe Commerce」および「Magento Open Source」の重大な脆弱性CVE-2026-75650を修正するホットフィックス（緊急修正プログラム）を公開した。脆弱性の深刻度を示すCVSS基本値は最大値の10.0で、認証を経ない攻撃者が任意のコードを実行できる。Adobeは告知の中で、この脆弱性が「Adobe Commerceの事業者を標的として実際に悪用されている」と明言している。この脆弱性は、セキュリティ企業Sansecが9月5日に「StyleSmuggler」という名称で公表した。悪用の開始は9月4日と報告されており、修正が出るまでの約3日間、対策のない状態（ゼロデイ状態）が続いていた。
テンプレートエンジンの「styles」を経由してPHPコードが持ち込まれる
Adobeのセキュリティ情報（APSB26-146）は、この脆弱性を「テンプレートエンジンで使用される特殊要素の不適切な無効化」と分類している。CVSSベクトルは`AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`で、ネットワーク経由・低い攻撃条件・権限不要・利用者の操作不要という、攻撃者にとって条件の揃った組み合わせだ。優先度はAdobeの区分で最も高い「1」に設定されている。
Sansecの解析によると、攻撃者はテンプレートシステムの`styles`プロパティにPHPコードを含む細工したデータを注入する。注入された内容はいったんディスク上に書き出され、トランザクションメールのテンプレートがレンダリングされる際に実行される。実行の引き金として悪用されていたのは、決済失敗を知らせる「Payment Transaction Failed Reminder」通知だったとされる。
対象となるのはAdobe Commerce 2.4.4〜2.4.9、Adobe Commerce B2B 1.3.3〜1.5.3、Magento Open Source 2.4.6〜2.4.9で、いずれも2026年8月に提供された版を含む。つまり最新の月次更新を適用していた環境も影響を受ける。
NTPサーバーを装うバックドアと、485バイトのWebシェル
侵害後に何が置かれていたかについても報告がある。
先行して観測された攻撃では、設置されたバックドアが指令サーバー（C2）との通信をNTPサーバー宛の通信に見せかけていた。時刻同期の通信は日常的に発生するため、ネットワーク側の監視をすり抜けやすい。一方で、被害環境には前述の「Payment Transaction Failed Reminder」メールが不自然に生成されるという痕跡が残っていたと報じられている。
その後、別の攻撃グループが異なる道具立てで参入したことも確認されている。こちらは485バイトという極小のPHP Webシェル（侵入後に外部から遠隔操作するための小さなプログラム）を設置し、サーバーの構成情報を収集して書き込み可能なディレクトリを探索したうえで、`oast.site`のサブドメイン宛にデータを送出していた。この基盤はもともと脆弱性検証ツール「Interactsh」で使われるもので、正規のテスト用インフラが攻撃の受け皿として転用されている。
被害規模について、Sansecは「複数の攻撃キャンペーンにわたって複数の被害ストアを確認した」としており、確定した総数は公表されていない。
適用したあとに、認証情報を全部入れ替える必要がある
このインシデントで運用担当者が最も注意すべきなのは、ホットフィックスの適用が対応の入口にすぎない点だ。
Adobeが公開した対応手順は、パッチ適用のあとにメンテナンスモードへ切り替え、cronの実行を停止したうえで、暗号化キーのローテーションを行うところから始まる。続いて管理者パスワードの全変更、REST／SOAP／GraphQLの統合トークンの再生成、OAuth認証情報、決済ゲートウェイのAPI認証情報、データベース認証情報、SSHおよびデプロイキー、連携する拡張機能のAPIキーまで、順に入れ替えることが求められている。そのうえでキャッシュをフラッシュし、cronを再開し、メンテナンスモードを解除する。クラウド版では再デプロイまで含まれる。
これは「念のため」の推奨ではなく、任意コード実行が成立していた場合に攻撃者が持ち出せた情報の範囲がそれだけ広いということを意味する。米Tenableは、修正前の3日間に稼働していたストアについては、パッチ適用に加えてインシデント対応が必要になると指摘している。パッチだけでは、すでに成立した侵害は解消されない。
なお本稿執筆時点で公開されている情報では、この脆弱性は米CISA（サイバーセキュリティ・インフラセキュリティ庁）が悪用確認済みの脆弱性をまとめたKEVカタログには、9月8日時点で未収載とされている。KEVに載っていないことは、悪用が起きていないことを意味しない。
ECサイトは「止められない」からこそ切り分けが要る
ECサイトは売上に直結するため、メンテナンスモードへの切り替えや認証情報の一斉更新は現場にとって重い判断になる。しかし今回の脆弱性は、注文処理に付随する通知メールという、止めることのできない日常動作を実行の契機にしていた。すでにコードを仕込まれた環境では、稼働を続けている限りそれが実行される機会も続く構造になる。
自社のストアが対象バージョンで動いていた場合、まず確認すべきは9月4日以降に不自然な「決済失敗」通知が発生していないか、書き込み可能ディレクトリに見慣れないPHPファイルが増えていないか、時刻同期を装った外部通信が出ていないかといった点になる。ECサイトを外部に委託している場合は、パッチの適用状況だけでなく、認証情報のローテーションと侵害調査まで実施したかを委託先に確認する必要がある。
サーバー上に置かれたWebシェルやバックドアは、ファイルとしてもプロセスとしても痕跡を残す。侵入そのものを完全に防ぎきれない前提に立つなら、サーバー側の挙動を継続的に記録・検知し、侵害の有無を後から追跡できる状態にしておくことが、この種のゼロデイに対する現実的な備えになる。
同じ手口に、自社は備えられていますか？