MagentoとAdobe Commerceの0day StyleSmuggler(CVE-2026-75650)

ECサイトの脆弱性で運用担当が最初に見るのは、たいてい「最新のセキュリティパッチを当てているか」という一点です。今回の件では、その確認が答えになりません。最初に侵害が確認された店舗は2.4.6-p15で、2026年7月と8月のパッチを適用済みでした。それでも侵入されています。

オランダのEC専門セキュリティ企業Sansecが2026年9月5日に公表したStyleSmugglerは、Magento Open SourceとAdobe Commerceの未認証リモートコード実行の0dayです。Adobeは9月7日にAPSB26-146を公開し、CVE-2026-75650として緊急のホットフィックスを出しました。CVSSは10.0、優先度はAdobeの最高位である1です。Adobeは公開文で、この脆弱性が実際に悪用されていることを把握していると明記しています。

この記事は、EC事業者と受託開発の運用担当に向けて、Adobeの公式アドバイザリ、Adobe Commerceのナレッジベース、Sansecの解析、CVEレコード、NVD、CISAのKEVカタログという一次情報から、影響範囲の確かめ方、脆弱性の機構、ホットフィックスの適用、侵害調査の順序を整理します。攻撃を再現する手順やペイロードそのものは扱いません。調査コマンドの実行や設定変更は自社が管理する環境に限って行い、他者が運用する店舗への試行は不正アクセス禁止法などの関連法令に触れます。記述は執筆時点(2026年9月8日)に確認できた範囲に限ります。

一次資料で確認できた事実#

まず、参照できる値を並べます。Adobeのアドバイザリと、AdobeがCNAとして登録したCVEレコードが情報源です。

CVSSが10.0になっている理由は、ベクタを見ると分かります。ネットワーク経由(AV:N)で、攻撃条件が低く(AC:L)、権限も利用者の操作も要らず(PR:N/UI:N)、機密性と完全性と可用性のすべてに高い影響があり(C:H/I:H/A:H)、そのうえスコープが変化しています(S:C)。スコープ変化は、脆弱なコンポーネントの権限境界を越えて影響が及ぶという判定です。CVEレコードの説明文も「Scope is changed.」で締めくくられています。EC基盤の脆弱性で10.0が付くことはまれで、この値自体が今回の扱いを決める材料になります。

NVDの状態も確認しておきます。NVDのエントリは2026年9月7日21時17分UTCに作られたばかりで、vulnStatusはReceivedです。CVSSはAdobeのPSIRT(psirt@adobe.com)がPrimaryとして提供した値がそのまま載っており、NVDによる独自分析やCPEの照合条件はまだ付いていません。脆弱性スキャナがCPEマッチに依存している場合、NVDの分析が終わるまで検出できないことがあります。バージョンの判定は自分の手で行う前提に立ちます。

Adobeの謝辞欄についても、誤って読まないように書いておきます。APSB26-146のAcknowledgements欄に並んでいるのはCVE-2026-76200、CVE-2026-76201、CVE-2026-77108、CVE-2026-77109、CVE-2026-76202であり、CVE-2026-75650に対する謝辞は載っていません。CVEレコードのsourceも {"discovery": "EXTERNAL"} とあるだけで、報告者名は記録されていません。発見と命名がSansecであるという情報の出所はSansec自身の公表です。

Adobe Security Bulletin APSB26-146は、Bulletin IDがAPSB26-146、Date Publishedが2026年9月7日、Priorityが1です。Summaryは「Adobe has released a security update for Adobe Commerce and Magento Open Source. This update resolves a critical vulnerability that could result in arbitrary code execution.」で、続けて「Adobe is aware of CVE-2026-75650 being exploited in the wild.」と記載しています。Vulnerability Detailsの表は、Vulnerability CategoryがImproper Neutralization of Special Elements Used in a Template Engine(CWE-1336)、Vulnerability ImpactがArbitrary code execution、SeverityがCritical、Authentication required to exploitがNo、CVSS base scoreが10.0、CVSS vectorがCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hです。SolutionのUpdated Versionは「Hotfix for CVE-2026-75650」で、Priority Ratingは1、Installation InstructionsとしてナレッジベースのRelease Notesへのリンクが置かれています。

CVEレコードCVE-2026-75650は、assignerShortNameがadobe、stateがPUBLISHED、dateReservedが2026-08-18T01:29:54Z、datePublishedが2026-09-07T20:17:16Z、datePublicが2026-09-07T17:00:00Zです。説明文は「Adobe Commerce is affected by an Improper Neutralization of Special Elements Used in a Template Engine vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed.」です。metricsにはcvssV3_1のbaseScore 10、baseSeverity CRITICALが記録され、problemTypesはCWE-1336のみ、referencesはAPSB26-146の1件です。affectedの各製品には修正済みの版として「Hotfix for CVE-2026-7565」という文字列が登録されており、末尾の桁が欠けた表記になっています。バージョン判定を機械的に行う場合、この欄はそのまま使えません。

攻撃開始からホットフィックス公開までの3日間#

Sansecが公開している時系列は、対応の緊急度を決めるうえで意味を持ちます。パッチが存在しない期間が3日あったからです。

この表から読み取れることが3つあります。1つ目は、悪用がパッチ公開の3日前から始まっていた点です。9月4日22時20分より後にインターネットへ公開していた店舗は、パッチを当てても「当てる前に入られていないか」を別途調べる必要があります。2つ目は、実装が短い期間に3回変わっている点です。プロセス名は [kworker/u:8:0] から fc-cache へ、さらに chronyd へと移っており、単一の文字列で探す検知は追随できません。3つ目は、別系統の攻撃者が同じ入口から入ってきている点です。9月7日の時点で、インプラントを置く攻撃者とPHPウェブシェルを置く攻撃者の2系統が観測されています。1つを見つけて終わりにする調査では取りこぼします。

Sansecの記事は2026年9月5日公開、最終更新は2026年9月7日20時45分UTCです。冒頭で「Sansec discovered StyleSmuggler, a Magento and Adobe Commerce zero-day that gives unauthenticated attackers remote code execution. Attacks started September 4th. Adobe published an emergency hotfix on September 7th for CVE-2026-75650, rated CVSS 10.0. Every version from 2.4.4 up to and including 2.4.9 is affected.」と述べ、調査が継続中であること、攻撃者が短期間に手口を変えているため記事を随時更新することを明記しています。Timelineの表には、2026-09-04 22:20の最初の悪用確認から2026-09-07 20:20のAdobeによるAPSB26-146公開までの各項目が記載されています。「Adobe shipped its hotfix on September 7, three days after the first confirmed exploitation.」とも書いています。

自社のバージョンが影響範囲に入るかの読み方#

Adobeが公開している影響範囲の表記は、慣れていないと解釈に迷います。並んでいるのは 2.4.9-2026-aug and earlier のような文字列で、従来の -p15 のような表記とは形が違うためです。

-2026-aug は、2026年8月11日公開のAPSB26-92で配布された更新の適用状態を指します。APSB26-92のSolution欄に載っているUpdated Versionが、まさに 2.4.9-2026-aug から 2.4.4-2026-aug までの文字列です。Adobeは2026年に入って月次の単独セキュリティ修正(isolated security patch file)という配布形態を採っており、その適用月がバージョン文字列に現れます。つまり and earlier が付いている以上、最新の月次修正まで当てていても影響を受けるという意味になります。

Magento Open Sourceの行に2.4.4と2.4.5が載っていない点は、影響がないという意味ではありません。Adobe Commerceの2.4.4系と2.4.5系は延長サポートの対象で、Magento Open Sourceのコードベースには延長サポートのセキュリティパッチが提供されないという扱いの違いによるものです。Sansecは「Every version from 2.4.4 up to and including 2.4.9 is affected.」と書いており、実務上は2.4.4系以降のすべてを対象として扱うのが妥当です。

自社の版を確認する手段も挙げておきます。管理画面のフッタに表示されるバージョン、CLIの bin/magento --version、composerの composer show magento/product-community-edition あるいは magento/product-enterprise-edition のいずれかです。単独セキュリティ修正の適用状態は、Quality Patches Toolの vendor/bin/magento-patches -n status で一覧できます。ここで大事なのは、リポジトリの composer.json ではなく本番で実際に動いている環境を見ることです。ステージングと本番で適用状態が違う構成では、両方を確認します。

受託開発で複数の店舗を預かっている場合は、次の順序で棚卸しすると漏れが出にくくなります。

Adobe Commerceのセキュリティパッチのリリースノート(最終更新2026年8月19日)は、単独セキュリティパッチファイルについて「Isolated security patch files are non-cumulative, standalone patch files that include fixes for one or more security vulnerabilities only, without any additional feature updates or non-security changes. These patches are released independently to enable faster remediation and are incorporated into the next full security patch.」と定義しています。さらに適用の前提として「To apply an isolated security patch file, customers must be on the latest security-only patch release (the latest -p version) for their supported release line, as isolated security patch files are tested exclusively against that version.」と記載しています。従来からのセキュリティパッチリリースは -pN の表記で、Nは1から始まる連番です。延長サポートのセキュリティパッチはAdobe Commerceの顧客のみが対象で、Magento Open Sourceのコードベースには提供されないとも明記されています。

テンプレートのstylesプロパティと決済失敗メールで成立する二段構成#

Adobeが割り当てた分類はCWE-1336、テンプレートエンジンで解釈される特殊要素の無害化不備です。MITREの定義では、外部から影響を受ける入力をテンプレートエンジンに渡す際に、テンプレート式やコード指示として解釈されうる特殊要素を無害化していない状態を指します。サーバサイドテンプレートインジェクション(SSTI)と呼ばれる系統の弱点です。

Sansecの説明によれば、StyleSmugglerはMagentoのテンプレート機構に悪意あるコードを注入し、styles プロパティを使うことで既存の防御をすり抜けます。動作は2段階です。1段目で、失敗レポートの生成といった経路を通してPHPコードを保存側に送り込みます。2段目で、Magentoが決済失敗の通知メールをレンダリングするときに、そのコードが実行されます。

この二段構成が、防御と調査の両面で効いてきます。

まず防御の面です。攻撃の入口と実行の瞬間が分かれているため、入口のリクエストを1本止めれば済むという構造ではありません。Sansecも「The attack surface behind this bug is large」と書き、自社製品で遮断できるとしたうえでAdobeのパッチ適用を重ねて勧めています。IoCとして挙がっているリクエストの形も、POST /graphql のクエリ文字列に styles[ を含むもの、/paypal/transparent/response/ へのPOST、/customer/section/load/ へのGETと複数にわたります。

次に調査の面です。実行の引き金がメールのレンダリングであるため、痕跡がメール送信のタイミングに現れます。Sansecは、StyleSmugglerが意図的にMagento標準の「Payment Transaction Failed Reminder」メールを発生させると説明しています。そのうえで、誰かがメールを開く必要はなく、Magentoがレンダリングする時点でコードが動くこと、メール配信自体が失敗しても攻撃は成立しうることを明記しています。決済失敗の通知が普段より不自然に増えていれば調査の理由になりますが、正当な決済拒否でも同じ通知は出るため、これだけで断定はできません。

Adobe Commerceでこの通知の設定を確認する場所は、管理画面のStores > Settings > Configurationから左パネルのSalesを開き、Checkoutを選んで「Payment Failed Emails」セクションを見る流れです。Payment Failed Email Receiverと「Send Payment Failed Email Copy To」の宛先が誰になっているかを把握しておくと、送信の急増に気づける体制になります。

テンプレートエンジンへの注入という弱点そのものの成り立ちは、次の記事で整理しています。

CWE-1336はImproper Neutralization of Special Elements Used in a Template Engineで、Abstractionはbase、Vulnerability MappingはALLOWEDです。Descriptionは「The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine.」です。CVE-2026-75650のproblemTypesに記録されているのはこのCWEのみです。

Adobe Commerceの「Payment failure notification」のドキュメント(最終更新2026年6月15日)は、決済手段が取引を完了できなかった場合に店舗の連絡先または指定した管理者へ通知が送られると説明しています。設定場所はAdminサイドバーのStores > Settings > Configurationで、左パネルのSalesを展開してCheckoutを選び、Payment Failed Emailsセクションを開きます。設定項目はPayment Failed Email Sender、Payment Failed Email Receiver、Payment Failed Template、Send Payment Failed Email Copy To、Payment Failed Copy Method(BccまたはSeparate Email)です。

セッション保存先の変更が回避策にならない理由#

パッチ公開前に出回った緩和策の候補に、セッションの保存先をファイルからRedisやデータベースへ移す案がありました。Sansecはこれを明確に否定しています。「Moving sessions to Redis or the database does not stop the attack.」という一文です。

根拠として挙げられている観測が具体的です。ある店舗で、セッション保存先を狙った試行が失敗し、その8秒後に、Magentoのカスタムオプション経由でアップロードされたファイルを使う別の試行が成功しました。両方とも同じ攻撃者からのものです。注入したPHPコードをどこに置くかという部分に代替経路があり、片方を塞いでも別の置き場所へ切り替えられる、という構図になります。

この点は、ファイルアップロード機能を持つEC基盤の設計上の弱点とも重なります。商品のカスタムオプションで顧客がファイルを添付できる構成は珍しくありませんが、その保存先がアプリケーションから読み書きできる場所にあると、無関係な脆弱性の踏み台として使われます。アップロードされたファイルの扱いをどう設計するかは、次の記事で整理しています。

回避策として意味があるのは、Adobeが出したホットフィックスの適用です。それまでの時間を稼ぐ手段として前段のWAFやアプリケーションゲートウェイで遮断する案はありますが、入口の形が複数あるため、遮断ルールだけで安全と判断するのは筋が通りません。

VULN-39341ホットフィックスの適用手順#

Adobeが配布したのはフルリリースではなく、composerパッチ形式のホットフィックスです。適用の流れはAdobe Commerceのナレッジベースに書かれています。

確認コマンドは次の形です。パイプとエスケープの扱いに注意します。

# Quality Patches Toolを導入済みの環境で適用状態を確認する
vendor/bin/magento-patches -n status | grep "39341\|Status"

# 稼働中のバージョンを確認する
bin/magento --version
composer show magento/product-community-edition

Adobe Commerceのナレッジベース記事「Urgent Action Required: Critical Security Update Available for Adobe Commerce (APSB26-146)」(最終更新2026年9月7日)は、冒頭で「This is an urgent update related to CVE-2026-75650. Adobe is aware that CVE-2026-75650 has been exploited in the wild targeting Adobe Commerce merchants.」と述べています。Resolutionの節は「To help resolve the vulnerability for the affected products and versions, you must apply the VULN-39341 patch (depending on your version) and rotate your encryption keys.」と、パッチ適用と暗号鍵ローテーションの両方を求めています。Hotfix linkとしてVULN-39341-composer-patches.zipの配布URLが示され、適用確認の手順として vendor/bin/magento-patches -n status | grep "39341\|Status" を実行しStatusがAppliedであることを見るよう案内しています。互換性の注記として、テスト済みは列挙された2026-aug系の版のみである旨が記載されています。

侵害の痕跡を探す順序#

パッチを当てても、すでに置かれたものは消えません。Sansecも「Patching closes the hole but does not clean a store that was already hit.」と書いています。調査は、動いているプロセス、永続化、ファイル、ログの順に見ます。以下はSansecが公開したIoCに基づくもので、実行は自社が管理するサーバに限ります。

Sansecが記載している調査コマンドは次のとおりです。

# 永続化の確認(cronエントリ)
crontab -l | grep -i gvfsd

# ドロップ先として報告されているパスの確認
ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* \
  /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache \
  /tmp/.chrony-*/chronyd 2>/dev/null

# 偽装されたプロセス名の確認
ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'

# システムログに残る痕跡
grep -r 'crontab command not allowed' /var/log/

# 失敗レポートに残る痕跡
grep -ril 'x_trace_' var/report/

# メディアディレクトリ配下のPHPファイル
find pub/media -name '*.php'

Sansecが報告しているインプラントは小さなRustのプログラムで、C2に接続してコマンドを待ちます。公表時点で「we have no indication that the backdoor has been weaponized」、つまり実際に何かを実行させられた形跡はないとしています。同時に、公表時点ではSansec以外のセキュリティ企業がこのバックドアを認識していないとも書いています。市販のアンチウイルスで検出されないことを、いない証拠として扱えません。

亜種ごとの特徴を表に整理します。すべてSansecの記述に基づきます。

通信の偽装は、この事案でとくに注意して読む部分です。fc-cache亜種は60秒ごとに ntp.timesync.to を解決し、UDPの123番ポートへ48バイトのパケットを送ります。形はNTPのサーバ応答に似ていますが、本当にNTPなのは先頭4バイトだけで、残りにはエージェントIDやホスト名やユーザー名やOSのバージョン、メモリとディスクの使用量、稼働時間、root権限で動いているかどうか、インプラントのバージョンがMessagePack形式で分割して詰められています。名前がNTPらしいホストへのUDP123という形のため、多くの外向き通信フィルタを素通りします。

chronyd亜種の命名は、探す側の想定を逆手に取っています。UDP123の通信を調べる担当者は、正規の時刻同期デーモンである chronyd を除外したくなります。その除外がそのまま隠れ蓑になります。Sansecは正規のNTPクライアントとの見分け方を2点挙げています。1つは、60秒ごとに48バイトのデータグラムを約10ミリ秒間隔で9個送る点で、正規のクライアントは1個しか送りません。もう1つは、すべてのデータグラムがNTPv4のserverモードで印されている点で、クライアントがserverモードを送る理由はありません。

永続化の探し方にも注意点があります。chronyd亜種のcronエントリは、crontab -e を経由せずcronのスプールファイルへ直接書き込まれていました。そのため、syslogに REPLACE の行が残りません。crontab -l の出力だけでなく、スプールファイルそのものを確認します。加えて、cronエントリを持たずに自力で再起動する個体も報告されているため、cronが空であることは正常の証拠になりません。

もう1点、調査する側が知っておくと役に立つ挙動があります。インプラントは /proc/self/status の TracerPid を読み、デバッガに追跡されている場合はインストールだけ行ってビーコンを送りません。動的解析で通信が観測されないことを、無害の根拠にはできません。

SansecのIndicators of compromiseの節は、マルウェア配布ホストとして 247.cdnflare.xyz と 209.141.43.95、C2として 99.84.67.186:443(WebSocket over TLS)、windwsecurity.run:443、ntp.timesysnc.net:123、time.microsft.run:123、pool.microsft.studio:123、ntp.timesync.to:123(fc-cacheビルド)、185.157.160.251:123(2026-09-07時点で ntp.timesync.to と ntp.timesysnc.net のAレコード)、フォールバックとして ntp.synctime.to:123 と ntp.syncstime.to:123 を挙げています。攻撃元IPとして 88.216.72.181、182.182.152.48、76.31.99.207、209.73.130.148、77.239.124.107 を、インプラント運用者のリクエストのUser-Agentとして python-requests 2.15.0 を記載しています。リクエストの形としては POST /graphql(Store:ヘッダにPHPを入れた偵察)、POST /paypal/transparent/response/、GET /customer/section/load/?sections=customer&force_new_section_timestamp=true、POST /graphql?styles[....]= が挙げられています。fc-cacheビルドは公開IPの取得のためHTTPで api4.ipify.org、ipv4.icanhazip.com、ipv4.ident.me、ipinfo.io にアクセスし、AppleWebKit/537.36 で途切れた実在しないUser-Agentを使うと記載しています。

アクセスログとメール送信記録で探す観点#

サーバ上の痕跡と並行して、ログ側からも当たります。Sansecが公開しているリクエストの形は、そのまま検索の手がかりになります。

見る対象は4つです。1つ目は、POST /graphql のうちクエリ文字列に styles[ を含むものです。GraphQLのエンドポイントにクエリ文字列でパラメータを渡す形自体が通常の利用と違うため、量が多くなければ目視で確認できます。2つ目は、/paypal/transparent/response/ へのPOSTで、クエリ文字列にPHPの開始タグらしき文字列が入っているものです。3つ目は、GET /customer/section/load/?sections=customer&force_new_section_timestamp=true の形で、これは正常な利用でも発生するため、単体ではなく他の指標と組み合わせて見ます。4つ目は、リクエストヘッダの Store: に長い文字列が入っているものです。ここは偵察用のコードが置かれていた場所として報告されています。

検索する際の注意が2つあります。1つは、多くの構成でアクセスログにクエリ文字列やリクエストヘッダが記録されていない点です。記録していなければ探せません。今回の対応をきっかけに、記録項目を見直します。もう1つは、Sansecが挙げている攻撃元IPアドレスは特定の観測に基づくもので、これに一致しないことは無事の証拠にならない点です。IPアドレスでの絞り込みは、当たれば早いという性質のもので、外れても結論は出ません。

メール側の記録も見ます。決済失敗の通知が、特定の日時に集中して発生していないかを確認します。Sansecは、コードが動くのはMagentoがメールをレンダリングする時点であり、配信そのものが失敗しても攻撃は成立しうると書いています。つまり、送信キューやSMTPのログに配信エラーとして残っているだけの記録も、攻撃の痕跡として意味を持ちます。正当な決済拒否でも同じ通知は発生するため、この指標だけで判断はできませんが、他の痕跡と時刻を突き合わせる材料になります。

別の攻撃者が残すウェブシェルの探し方#

9月7日にSansecが解析したのは、インプラントとは別系統の485バイトのPHPドロッパーです。同じStyleSmugglerの入口から入ってきていますが、道具立てが異なります。

このドロッパーは、商品画像のキャッシュ配下にウェブシェルを書き込みます。パスの形は pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php です。設置されたウェブシェルは、決められた X-Cache-Token ヘッダが付いていないリクエストにはすべて404を返します。外形監視やクローラからは見えないという意味です。ヘッダが付いていれば、POSTの task パラメータに渡されたPHPコードを実行します。

先行して送られる偵察用のリクエストも記載されています。POST /graphql に無害なクエリを見せかけの本体として置き、コードは Store: リクエストヘッダに入れる形です。読み取っているのはカーネルとOSの文字列、PHPの実行ユーザー、カレントディレクトリ、そして pub/media が書き込み可能かどうかです。結果はDNSのホスト名ラベルに50文字ずつ分割して送り出され、攻撃者はコールバックのログから復元します。応答本文を見る必要がないため、外向きのHTTPを止めていても情報は出ていきます。

調査の実務としては、次の3点を押さえます。

1. find pub/media -name '*.php' で、メディアディレクトリ配下のPHPファイルを洗い出す。正規の運用でここにPHPが置かれることは通常ありません。
2. アクセスログで、X-Cache-Token ヘッダを含むリクエストや、pub/media 配下の .php への到達を探す。ログにリクエストヘッダを記録していない構成では見つけられないため、記録項目の見直しも合わせて行います。
3. Sansecは、ドロッパーをMagentoが記録したレコードの Store: リクエストヘッダから回収したと書いています。var/report/ 配下の失敗レポートは、注入の痕跡が残る場所として調査の対象になります。grep -ril 'x_trace_' var/report/ はその探索です。

インプラントのプロセスを止めただけでは終わらない理由が、ここにあります。入口が同じでも、置かれたものは攻撃者ごとに違います。

侵害が疑われる場合に踏む順序#

Adobeのナレッジベースは、資格情報のローテーションを詳細な手順として公開しています。適用の順序に意味があるため、そのまま踏襲します。パッチを当てる前に鍵を回しても、脆弱性が残っていれば同じことの繰り返しになります。

Adobeがナレッジベースで書いている注意が、この手順の核心です。暗号鍵は連携トークンや決済ゲートウェイの資格情報、システム権限の自動化トークンを暗号化するために使われています。鍵を回すだけでは、すでに攻撃者に読まれた資格情報は無効になりません。だからこそ、鍵の変更とは別に、それぞれの提供元で資格情報そのものを作り直す必要があります。Magentoの中だけで完結させないという点が、過去のCosmicSting(CVE-2024-34102)のときと同じ教訓です。

侵害が確定した場合の初動の組み立て方は、次の記事で整理しています。

Adobe Commerceの暗号鍵のドキュメント(最終更新2026年8月20日)は、Adobe CommerceとMagento Open Sourceがパスワードなどの機微データの保護に暗号鍵を使い、256ビット鍵のChaCha20-Poly1305で暗号化していると説明しています。管理画面からの鍵変更機能について「The encryption key change feature in the Admin settings is deprecated and was removed in 2.4.8. You must use the CLI command described on this page to change your encryption key after upgrading to 2.4.8.」と記載しています。CLIコマンドは bin/magento encryption:key:change です。手順としてメンテナンスモードの有効化、cronの停止、鍵の変更、キャッシュのフラッシュ、cronの再開、メンテナンスモードの解除が示されています。「Rotating the encryption key will immediately invalidate all customer and admin sessions (excluding integration users) and will require them to login again.」という注意と、事前に app/etc/env.php を書き込み可能にしておく必要がある旨も書かれています。

同じナレッジベース記事の「Rotate the credentials after applying the patch」の節は、「To fully remediate this issue, rotate not only your encryption key but all credentials that may have been encrypted or exposed using it, including server, API, and integration credentials.」と述べています。注記として「The encryption key is used to encrypt integration tokens, payment gateway credentials, and system-privileged automation tokens. Rotating the encryption key alone does not invalidate credentials that may already have been exposed. Rotate all associated credentials at their source (for example, at the payment gateway or third-party service), not only within Commerce.」と記載しています。手順は、ホットフィックスの適用、メンテナンスモードの有効化、cronの停止、暗号鍵のローテーション、管理者パスワードの変更、REST/SOAP/GraphQL連携トークンの無効化と再生成、OAuthクライアントシークレットの更新、決済ゲートウェイのAPI資格情報の更新、データベース資格情報の更新、SSHとデプロイ鍵およびcronとシステム権限のサービスアカウントの更新、配送や税計算などの連携先APIキーの更新、キャッシュのフラッシュ、cronの再開、メンテナンスモードの解除という順序で並んでいます。

KEV未掲載をどう扱うか#

対応の優先度を社内で説明するとき、CISAのKEVカタログを根拠に使う運用が広がっています。今回は、その根拠が執筆時点では使えません。

KEVカタログのJSONフィードを確認すると、執筆時点で取得できる最新版はcatalogVersion 2026.09.04、件数1695、公開日時2026-09-04T16:47:03Zです。CVE-2026-75650のエントリは含まれていません。Adobeの公開が9月7日20時20分UTCですから、カタログの更新がまだ追いついていない段階にあります。過去のMagentoの重大な脆弱性がKEVに載っている実績を見ると、収録される可能性は高いと考えられますが、執筆時点で確認できるのは未掲載という事実だけです。

参考までに、KEVに収録済みのMagento関連の脆弱性を挙げます。

日本国内の情報源も確認しました。JVNDBのMyJVN検索でMagentoを検索した結果は、執筆時点で該当エントリなしです。JPCERT/CCの2026年の注意喚起一覧、IPAのセキュリティ注意喚起一覧にも、Adobe CommerceまたはMagentoを対象とした本件の記載は見当たりません。国内の窓口からの発信を待つ運用にしていると、この種の情報は取りこぼします。

優先度の判断には、KEV掲載の有無ではなく次の3つを使います。1つ目は、Adobeが自らのアドバイザリで実際の悪用を把握していると書いていること。2つ目は、CVSSが10.0でスコープ変化を伴うこと。3つ目は、悪用が始まった9月4日から3日間、パッチが存在しなかったという事実です。この3つがそろっている状態で、KEVに載っていないことを緊急度を下げる材料に使うのは筋が通りません。KEVとEPSSを日常の優先度付けへ組み込む方法は、次の記事で整理しています。

CISAのKnown Exploited Vulnerabilities CatalogのJSONフィードは、執筆時点でcatalogVersion 2026.09.04、count 1695、dateReleased 2026-09-04T16:47:03.5197Zです。この版にCVE-2026-75650のエントリは含まれていません。Adobe CommerceおよびMagento Open Sourceを製品名に含むエントリは、CVE-2022-24086(dateAdded 2022-02-15)、CVE-2024-34102(dateAdded 2024-07-17)、CVE-2025-54236(dateAdded 2025-10-24)の3件です。いずれもknownRansomwareCampaignUseはUnknownです。

恒久対策として運用に残すもの#

今回の対応が終わったあとに残すべき設定と運用を整理します。単発のパッチ適用で終わらせないための項目です。

管理画面の露出を絞ります。Adobe Commerceの管理画面セキュリティのドキュメントは、推測しやすい admin や backend ではなく独自の管理URLを使うこと、URLに秘密鍵を付与する「Add Secret Key to URLs」を有効にすること、管理画面のログインには二要素認証が必須であること、CAPTCHAを追加できることを挙げています。加えて、ログイン試行回数の上限によるアカウントロック、セッション長の制限、パスワード有効期限の設定があります。今回の脆弱性は未認証で成立するため管理画面の防御では止まりませんが、侵入後の権限拡大や、盗んだ資格情報の再利用を難しくする効果は残ります。

前段の遮断を用意します。WAFやアプリケーションゲートウェイで、/graphql や決済コールバックのエンドポイントに対する異常なリクエストを記録して遮断できる状態を作ります。今回のように入口が複数ある脆弱性では、遮断だけを頼りにはできませんが、パッチが出るまでの時間を稼ぐ手段としては機能します。仮想パッチを提供する製品を使う場合も、ベンダーの適用状況を確認したうえで、公式パッチの適用は別に行います。

更新の運用を決めます。Adobeは2026年から月次の単独セキュリティ修正を配布しており、その適用には対象リリースラインの最新の -p 版であることが前提になります。月次の修正だけを追いかけていると、-p 版が古いまま適用できない状態に陥ります。四半期に一度は -p 版の適用状況を棚卸しし、緊急のホットフィックスがいつでも当てられる状態を保ちます。あわせて、Adobeのセキュリティ情報の配信を購読し、Sansecのような専門ベンダーの公表も情報源に加えます。今回は、Adobeの公表よりSansecの公表が2日早い状況でした。

ログを残します。今回の調査では、アクセスログのリクエストパス、クエリ文字列、一部のリクエストヘッダ、決済失敗メールの送信記録、cronのスプールファイル、var/report/ の失敗レポートが手がかりになりました。これらの保存期間が数日しかない構成では、3日前に始まった攻撃の痕跡を追えません。保存期間と記録項目を、事後調査に耐える水準に設定しておきます。

Adobe Commerceの「Configure Admin security」(最終更新2026年8月20日)は、推測しやすいAdminやBackendではなく独自の管理URLを使うことを勧め、管理画面のセキュリティ設定としてURLへの秘密鍵の付与、パスワードの大文字小文字の区別、最小パスワード長の設定、管理セッションの長さの制限、パスワード有効期限の制限、ログイン試行回数の上限によるアカウントロックを挙げています。「In addition to the security settings in this section, two-factor authentication (2FA) is required to verify users' identity with a one-time password that is generated by an app or device.」と、二要素認証が必須である旨とCAPTCHAを追加できる旨も記載しています。設定場所はStores > Settings > Configurationの左パネルAdvancedからAdminを選び、Securityセクションを開く流れです。「Add Secret Key to URLs」は既定で有効と書かれています。

今日の判断に落とすと#

最後に、判断の順序をまとめます。

該当するかどうかの判断は、パッチ適用状況ではなくバージョンラインで行います。Adobe Commerce 2.4.4系以降、Adobe Commerce B2B 1.3.3系以降、Magento Open Source 2.4.6系以降を運用しているなら、2026年8月の月次修正まで当てていても対象です。「最新のパッチを当てているから大丈夫」という判断が成り立たないところが、この事案の特徴です。

やることは、VULN-39341の適用と、暗号鍵を含む資格情報のローテーションの2つがセットです。Adobeのナレッジベースが両方を求めており、片方だけでは残る問題があります。パッチを当てても読まれた資格情報は生きたままで、鍵だけ回しても穴は開いたままです。

調べることは、9月4日以降にインターネットへ公開していた期間に対する侵害調査です。プロセス名、cronスプール、pub/media 配下のPHP、var/report/ の失敗レポート、UDP123番の外向き通信を順に見ます。インプラントを1つ見つけて終わりにせず、別系統の攻撃者が置いたウェブシェルも探します。市販のアンチウイルスが何も言わないことは、いない証拠にはなりません。

情報が動いている最中の事案です。SansecはStyleSmugglerのガジェットチェーンとドロッパーとインプラントの詳細を後日の更新で公開すると書いており、AdobeのアドバイザリとCISAのKEVカタログも更新されうる状態にあります。本記事の内容は執筆時点で確認できた一次情報に基づくもので、対応にあたっては各一次情報の最新版を必ず確認してください。