MagentoとAdobe Commerceで10点満点中10点の脆弱性：実際に何が起きたのか

まず結論から。2026年9月4日、攻撃者はMagento Open SourceとAdobe Commerceに存在する未修正の脆弱性の悪用を開始しました。この脆弱性はCVE-2026-75650として登録され、深刻度スコアは10.0、つまり考えうる最高値です。この脆弱性を使うと、ログインも権限も一切なしにストアのサーバー上でコマンドを実行でき、Adobeが修正を公開したのは9月7日の夜でした。つまり、ストアがまったく無防備なまま晒されていた期間が丸三日あったことになります。だからこそ、パッチを入れるだけでは不十分なのです。ストアがこのプラットフォームで動いているなら、修正が存在する前にすでに侵害されていた可能性があると想定するのが安全であり、正しい対応は侵入の兆候を探し、暗号鍵とすべての認証情報をローテーションすることです。アップデートを入れていつもどおりの一日に戻ることではありません。

具体的に誰が影響を受けるのか

対象範囲は異例の広さです。発見時点で入手可能だった最新リリースまで含まれているからです。

  • Magento Open SourceおよびAdobe Commerce：バージョン2.4.4から2.4.9まで。2026年8月までのすべてのパッチアップデートを含みます。
  • Adobe Commerce B2B：バージョン1.3.3から1.5.3まで。2026年8月のアップデートまでが対象です。
  • 2.4.4より古いすべてのバージョン：すでにサポート対象外で、公式のホットフィックスが適用されないため最も危険なカテゴリです。

端的に言えば、9月1日時点で完全に最新のMagentoを運用していたなら、あなたは無防備な状態でした。これは私たちが普段警告している、よくある怠慢のシナリオではありません。誰にも先回りする手段のなかった、正真正銘のゼロデイ（zero-day）です。

パスワードなしで攻撃が成立する仕組み

攻撃は二段階で進み、Magentoのメールテンプレート生成機能を悪用します。第一段階では、攻撃者が細工したリクエストを決済レスポンス用のパスに送り、そのリクエストの内容全体がサーバー上のエラーレポートファイルに書き込まれます。第二段階では、GraphQLエンドポイントへのリクエストがその汚染されたファイルを参照し、決済失敗リマインダーメールが準備される過程でファイルの内容が実行されます。

経営者が注目すべきなのは技術的な詳細ではなく、それが示している事実です。決済ゲートウェイのレスポンス、ストアフロント向けのクエリエンドポイント、自動送信メールといった、まったく無害に見える公開パスが組み合わさり、サーバーへの完全な侵入経路になったのです。深刻な脆弱性が、大きく開け放たれた一枚の扉であることはめったにありません。はるかに多いのは、一つひとつはまったく問題なさそうに見える小さな扉の連なりです。

侵入後に攻撃者が仕掛けたもの

ここに、愉快犯と組織的な作戦の違いが表れます。確認されたペイロードは派手なランサムウェアの脅迫文ではなく、静かに居座るための永続化ツールでした。

  • Rustで書かれたバックドア。オペレーティングシステムのカーネルプロセスの一つに偽装しており、プロセス一覧をざっと眺める人の目には留まりません。
  • 偽装されたコマンド＆コントロール通信。時刻同期用のポートを経由するため、ネットワークログ上では日常的な時刻合わせのように見えます。
  • PHPのWebシェル。商品画像のキャッシュフォルダ内に書き込まれていました。一時ファイルであふれているため、普段は誰も確認しない場所です。
  • 追加のリモートアクセスツール。無関係なツールを使う二人目の攻撃者によるもので、この脆弱性が同時に複数のグループに悪用されていたことを意味します。

知名度のあるオンラインストアにこうしたペイロードを仕込む目的は、サイトを停止させることではなく、長期間居座って注文データや決済データを通過するそばから読み取ることです。感染したストアはまったく普段どおりに動き続けます。そこが不気味な点なのです。

アップデートを入れるだけでは不十分な理由

9月7日より前に攻撃者が侵入していたなら、その攻撃者はすでにあなたの暗号鍵と保存された認証情報のコピーを手にしているからです。パッチは攻撃者が入ってきた扉を閉じますが、中にいる者を追い出しはしません。Adobe自身のガイダンスもこの点を明確にしていました。修正を適用し、そのうえで暗号鍵、管理画面のパスワード、APIトークン、決済ゲートウェイの認証情報、データベースのパスワード、サーバーのアクセスキーをローテーションすること、と。

パッチは出血を止める。招かれざる客を家から追い出すのは、鍵のローテーションだ。

ストアオーナーのための実践的なアクションプラン

  • 第一に、修正が本当にインストールされていることを確認する。誰かが「入れた」と言ったことではなく、です。安心させるメッセージではなく、サーバー上のパッチログそのものから証拠を出すようチームに求めてください。
  • 第二に、侵入の痕跡を確認する。システムプロセスを模した名前の不審な実行中プロセス、メディアや画像フォルダ内のPHPファイル、通常とは異なるエラーレポートファイルです。
  • 第三に、送信メールのログを確認する。決済失敗リマインダーメールの急増は悪用の試みを直接示す指標であり、深いセキュリティの専門知識がなくても、運用責任者なら誰でも読み取れます。
  • 第四に、すべての鍵を例外なくローテーションする。何より決済ゲートウェイの認証情報です。これにはピーク時間帯のその場しのぎの判断ではなく、計画されたメンテナンス時間枠が必要です。
  • 第五に、バージョンが2.4.4より古い場合は、来ることのない公式パッチを待つのをやめましょう。実際の期日を決めたアップグレード計画を立て、それまでの間はストアをWebアプリケーションファイアウォールの背後に置いてください。
  • 第六に、実施した対応を記録する。顧客データの漏えいが判明した場合、いつ何をしたのかを示す時系列が必要になります。

サウジアラビアにおける規制面：顧客データは技術だけの問題ではない

顧客の氏名、住所、携帯電話番号、注文履歴を保持するオンラインストアは、個人データ保護法の適用を受ける個人データを取り扱っています。情報漏えいは、ストアとホスティング事業者の間だけの内部問題にはとどまりません。所管当局に対しても、データ主体本人に対しても義務が生じます。ですから、ストアオーナーが今日問うべきなのは「サーバーにパッチは当たったか」だけではなく、「顧客のデータに手が付けられていないことを示せるか」なのです。

ストアがSallaやZidのようなマネージドクラウドプラットフォームで運用されているなら、プラットフォームへのパッチ適用はあなたの責任ではないため、今回の脆弱性の対象外です。しかし同じ教訓は、あなたがストアに組み込んだあらゆる拡張機能やサードパーティ連携にも当てはまります。パッチ適用の責任は、サーバーの所有者についてまわるのです。

Origamiではこうしたインシデントにどう対処しているか

私たちがクライアントのシステムを構築する際の原則は、セキュリティインシデントは遠い可能性ではなく、先送りされた出来事だということです。実践としては三つのことを意味します。認証情報をコードベースの外、別の保管庫に置き、ローテーションを一週間がかりのプロジェクトではなく数分の作業にすること。運用ログをサーバー本体の外に保存し、攻撃者が自らの痕跡を消せないようにすること。そしてバックアップを単にスケジュールするだけでなく、実際に復元してテストしておくことです。

専任の技術チームを持たずにMagentoストアを運営しているなら、今日取るべき正しい行動はシンプルです。ホスティング事業者または技術パートナーに、三つの質問だけに答える書面のレポートを求めてください。修正が正確にいつインストールされたか、侵害スキャンで何が見つかったか、そして鍵はローテーションされたか。この三つの質問は、どんなプレゼンテーションよりも技術パートナーの備えを明らかにしてくれます。

出典

  • セキュリティアップデートAPSB26-146と緊急ホットフィックスに関するAdobe Commerceの公式発表：experienceleague.adobe.com
  • CVE-2026-75650と侵害の痕跡に関するSansecの技術分析：sansec.io/research/stylesmuggler-0day
  • CISAの既知の悪用された脆弱性カタログ：cisa.gov
  • 個人データ保護法（PDPL）— サウジアラビア・データ人工知能庁（SDAIA）：sdaia.gov.sa