Adobe、悪用確認済みのMagento脆弱性を緊急修正、更新済みストアでも侵害

Magento Open SourceまたはAdobe Commerceを運用する事業者は、緊急ホットフィックスの適用に加え、侵害の痕跡を調査し、暗号化キーや関連する認証情報を更新する必要がある。Adobeは2026年9月7日、すでに悪用が確認されていた脆弱性「CVE-2026-75650」に対する修正を公開した。Sansecが「StyleSmuggler」と呼ぶこの脆弱性では、それまでに提供されていたセキュリティ更新を適用済みのストアでも侵害が確認されている。

■認証不要で任意のコードを実行

Adobeは9月7日、Adobe Commerce、Adobe Commerce B2B、Magento Open Sourceを対象とする定例外のセキュリティ情報「APSB26-146」を公開した。CVE-2026-75650は、テンプレートエンジンにおける特殊要素の不適切な無害化に分類される脆弱性で、認証や利用者の操作を必要とせず、任意のコードを実行される可能性がある。CVSS v3.1の基本値は最高の10.0、Adobeの適用優先度は最も高い「1」である。

影響を受ける製品は、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月版とそれ以前が対象となる。適用すべきファイルは導入バージョンによって異なるため、Adobeが公開した対応表に基づいて選ぶ必要がある。

脆弱性を発見したオランダのeコマースセキュリティ企業Sansecによると、攻撃はMagentoのテンプレート処理に不正なPHPコードを持ち込み、後続の処理で実行させる2段階の構造を取る。第1段階では、細工した入力によって、var/report/配下の障害報告ファイルやvar/log/system.logなど、Magentoがアクセスできるファイルへコードを書き込ませる。

第2段階では、Magentoの「Payment Transaction Failed Reminder」メールに関連するテンプレート処理を起動し、先に書き込ませたコードをサーバー上で実行する。メールを利用者が開いたり、リンクをクリックしたりする必要はない。外部から届くリクエストだけでなく、その後にアプリケーション内部で行われるテンプレート処理まで監視できなければ、従来型のWebアプリケーションファイアウォールでは攻撃全体を捉えにくい。

SansecやDisrexの解析では、Magentoが入力の型を確認する前に、攻撃者が影響を与えられるクラスを生成していたことが問題の中心とされている。Adobeの公式ホットフィックス「VULN-39341」は、関連する処理で型やクラスを事前に検証し、不正な入力が実行につながる経路を修正する。

■更新済みストアでも侵害を確認

Sansecは9月4日に最初の悪用を検知し、翌5日に調査結果を公表した。この時点ではAdobeによるCVEの割り当てや公式パッチはなく、Sansecは攻撃が進行中であることを早期公表の理由に挙げた。一方、攻撃をそのまま再現できる詳細なリクエストチェーンは開示しなかった。

最初に確認された被害ストアはMagento Open Source 2.4.6-p15を使用し、Adobeが7月と8月に提供した更新を適用していた。Sansecによると、Magentoのパッチ確認コマンドでも未適用パッチは報告されていなかった。既存の更新を迅速に適用するだけでは、修正がまだ存在しない期間の攻撃を防げなかったことになる。

Sansecはその後、Magento Open Source 2.4.7、2.4.8、2.4.9のクリーンな環境で、認証を必要としない攻撃経路を再現した。Adobeは9月7日にAPSB26-146を公開し、ホットフィックスVULN-39341の提供を開始した。

■Webルート外に設置されたバックドア

Sansecとインシデント対応企業Disrexが確認した攻撃では、侵害後にRustで作られたLinux向けバックドアが設置された。確認されたバイナリーは約1.9MBで、x86-64版とarm64版が存在する。

バックドアはWebコンテンツを置くドキュメントルートではなく、サイトを実行するユーザーのホームディレクトリー内にある「~/.local/share/.gvfsd/gvfsd-user」などへ配置されていた。Disrexが調査した事例では、ドキュメントルートだけを対象とするスキャナーがこのファイルを検出できなかった。

永続化にはcronが使われ、/var/spool/cron/crontabs/配下のファイルへエントリーを直接書き込む例が確認された。通常のcrontabコマンドを経由しないため、標準的な変更記録だけでは設定を追えない場合がある。あるストアでは同じエントリーが多数記録され、削除後に再作成される挙動も報告された。

攻撃者はプロセス名も変化させていた。初期にはLinuxのカーネルワーカーに似せた「[kworker/u:8:0]」、その後はフォントキャッシュ用の正規ツールと同名の「fc-cache」、さらに時刻同期デーモンと同名の「chronyd」が使われた。プロセス名だけで判断せず、実行ファイルのパスや親プロセスも確認する必要がある。

Sansecの調査では、新しい亜種がNTPで使われるUDPの123番ポートへ48バイトのパケットを送る挙動も確認された。通常の時刻同期通信に似た宛先名やポートが使われるため、正規に設定したNTPサーバー以外への通信がないかを照合することが重要になる。

Disrexが調査した別の事例では、バックドアによる外部接続が確認されない一方、ローカルホスト上のRedisへ多数の接続が作られていた。Redisに保存された顧客セッションや管理用トークンなどを読み取られた可能性があるため、外向き通信が見つからないことだけでは侵害を否定できない。

■パッチ適用と侵害対応は別の作業

Adobeは、影響を受ける環境にVULN-39341を適用するよう求めている。ホットフィックスは、該当バージョンに適合するものをAdobeの公式対応表から選択し、Adobe Commerceの導入形態に応じた手順で適用する必要がある。Adobe Commerceのクラウド環境では、cloud-patchesによって修正済みの場合もあるため、重複適用を避けながら状態を確認する。

ホットフィックスは新たな悪用経路を閉じるもので、すでに設置されたバックドアを削除するものではない。9月4日の悪用開始からパッチ適用までインターネットへ公開されていた環境では、既知の侵害指標だけでなく、Webルート外のファイル、実行中のプロセス、cron、ログ、Redisへの不審な接続、通常と異なるNTP通信を含めて調査する必要がある。

確認対象には、不自然な場所から動作する「[kworker/u:8:0]」「fc-cache」「chronyd」、ホームディレクトリー内の「.gvfsd」関連ファイル、「.gvfsd」を参照するcron設定、var/report/またはvar/log/system.log内の「x_trace_」を含む記録などがある。ただし、攻撃者が使用するファイル名や通信方法は変化しているため、既知の侵害指標が見つからないことだけで安全とは判断できない。

Adobeはホットフィックスの適用とともに、暗号化キーと、そのキーで保護されていた認証情報の更新を求めている。対象には管理者パスワード、REST、SOAP、GraphQLの連携トークン、OAuthクライアントシークレット、決済ゲートウェイのAPI認証情報、データベース認証情報、SSHキー、デプロイキー、配送・税計算・拡張機能などの外部サービス用APIキーが含まれる。

暗号化キーを変更するだけでは、攻撃者がすでに読み取った認証情報は無効にならない。各認証情報を発行元で再発行または変更し、古い情報を失効させる必要がある。

■利用者への影響は個別の調査が必要

サーバー上で任意のコードを実行できる状態になると、攻撃者はチェックアウト画面への不正なスクリプトの挿入、顧客情報やセッション情報へのアクセス、別のバックドアの設置などを試みる可能性がある。一方、9月4日以降に侵害された個々のストアで、カード情報や顧客データが実際に持ち出されたかどうかは、公開情報だけでは判断できない。

ストア運営者は、侵害の有無とアクセスされた情報の範囲を個別に調査し、適用される法令、契約、決済カード業界の要件に従って対応する必要がある。利用者側では、利用したオンラインストアからセキュリティに関する連絡がないかを確認するとともに、カード利用通知を有効にし、身に覚えのない取引がないか明細を継続して確認することが基本的な対策となる。

元記事: Adobe Patches Magento Zero-Day That Hacked Stores With All Patches Applied