Magentoの脆弱性CVE-2026-48356とは：PolyShellの対象版・確認コマンド・パッチ適用手順

ECサイト構築基盤のMagento Open SourceとAdobe Commerceで、ログインなしにファイルを置かれる脆弱性CVE-2026-48356が、2026年10月27日に米国CISAの「悪用が確認された脆弱性（KEV）」カタログへ追加されました。2026年3月にセキュリティ企業のSansecが「PolyShell」と名付けて公表し、すでに大規模な攻撃に使われているものです。Adobeは2026年7月14日の定期更新APSB26-73で修正を出していますが、配布は個別パッチだけで、Composerで版を上げても入りません。本記事では、Magentoの脆弱性への対応として、対象になる版の確かめ方、系列ごとのパッチの当て方、Webサーバー側の暫定対策、侵害の痕跡の探し方を実装者の目線で整理します。記載内容は2026年10月28日時点の公開情報にもとづきます。

まとめ：7月の個別パッチを当て、custom_optionsの実行を止めて痕跡を確かめる

対象はAdobe Commerceの2.4.4〜2.4.9系と、Magento Open Sourceの2.4.6〜2.4.9系です。修正は2026年7月14日に出た個別パッチで、当てる前に各系列の最新のセキュリティ版（2.4.8系なら2.4.8-p5）へそろえる必要があります。CISAが米国連邦機関に課した対応期限は2026年11月10日です。

パッチを当てるまでの間は、アップロード先のpub/media/custom_options/への外部からのアクセスをWebサーバーで止めます。これは置かれたファイルを動かさないための設定で、置かれること自体は防げません。

3月から攻撃が続いているため、パッチを当てて終わりにはしません。アップロード先の不審なファイル、accesson.phpという名前の裏口、CMSブロックに差し込まれたスクリプトの3つを必ず確かめてください。Magento Open Sourceの2.4.5以前にはパッチが出ないため、2.4.6以降への移行が前提になります。

CVE-2026-48356（PolyShell）の仕組みと3月〜10月のKEV登録経緯

PolyShellは、買い物かごに商品を入れる処理が、送られたファイルを確かめずに保存してしまう問題です。

ゲストカートのREST APIからファイルを置かれる仕組みと画像検査の抜け穴

Sansecのアドバイザリによると、入口はログイン不要のゲストカートのREST APIです。商品に「ファイル」型のカスタムオプション（名入れ用の画像を受け付ける項目など）を付けてカートに追加する処理で、送られたファイルがpub/media/custom_options/quote/に保存されます。

この処理には、オプションIDの検証、オプションの種類の確認、拡張子の制限という3つの確認が欠けていました。残っていたのは「画像として読めるか」の確認だけです。攻撃者は、画像のヘッダーを持ちながらPHPのコードも含む「ポリグロット」のファイルを送り、この確認を通します。PolyShellという名前も、このファイルが画像とPHPの両方の性質を持つことに由来するものです。対象の呼び出しはPOST /V1/guest-carts/:cartId/itemsとPUT /V1/guest-carts/:cartId/items/:itemIdの2つで、GraphQLの更新処理は別の経路を通るため対象外とされています。

置かれたファイルがPHPとして動くかは、Webサーバーの設定で決まります。Sansecは、標準外のnginx設定ですべての.phpを実行に回している構成や、2.3.5より前のApache構成で任意のコード実行に至るとしています。実行されない構成でも、ファイルが置かれる状態は変わりません。

NVDのCVSS v3.1が9.3でSansecの説明と前提が一部違う点

NVDの記録では、CVE-2026-48356は「危険な種類のファイルの無制限アップロード」（CWE-434）で、CVSS v3.1は9.3（Critical）です。Adobeの評価は、ネットワーク経由・権限不要ですが、利用者の操作（UI:R）を前提にしています。CVSSの各項目の読み方は脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務で整理しています。

一方でSansecは、ログインも利用者の操作もなしにファイルを置けると説明しています。NVDの参照先にはSansecのPolyShellの記事が入っています。前提がずれていても優先度は下げません。CISAが「実際に悪用されている」と判定したことがKEV登録の理由です。

2026年3月の公表から10月27日のKEV追加までに起きたこと

時系列で並べると、本番向けの修正が出るまでに約4か月の空白がありました。

3月30日の報告はSansecの大規模攻撃の記事にあり、置かれたWebシェルが複数のディレクトリへaccesson.phpを配り、最後にCMSページやブロックへ難読化したJavaScriptを差し込む流れが自動化されていたと書かれています。CISAのKEVカタログへの追加で、米国連邦機関には11月10日までの対応が課されました。

自社のMagentoとAdobe Commerceが対象かを版とパッチの有無で確かめる手順

判定は「製品と系列」「その系列の中の版」「7月の個別パッチが当たっているか」の順に進めます。Composerの版番号だけでは、個別パッチの有無が分からない点に注意してください。

NVDとAdobeが示す製品ごとの対象版と個別パッチの提供範囲

NVDの記録に載っている対象は、次の4製品です。Adobe Commerceを契約していない自社構築のサイトは、ほぼMagento Open Sourceに当たります。

系列ごとの上限は、Adobe Commerceが2.4.9・2.4.8-p5・2.4.7-p10・2.4.6-p15・2.4.5-p17・2.4.4-p18で、これ以前の版がすべて対象です。Magento Open Sourceは2.4.6-p15までの4系列が並びます。Sansecは「5月の2.4.9に修正が入った」と更新していますが、NVDの記録では2.4.9も対象に含まれています。2.4.9を使っている場合も、7月の個別パッチを当てる前提で進めてください。

bin/magentoとcomposer showで系列とセキュリティ版を調べる

まず、インストール先で版を読み取ります。composer.jsonの記載は範囲の指定なので、ロックファイルが解決した実際の版を見ます。

# Magento のルートディレクトリで実行する
bin/magento --version

# Open Source の場合（実際に入っている版）
composer show magento/product-community-edition | grep -E "^versions"

# Adobe Commerce の場合
composer show magento/product-enterprise-edition | grep -E "^versions"

# B2B を入れている場合
composer show magento/extension-b2b | grep -E "^versions"

結果が2.4.8-p3のように系列の最新より古い場合は、先にその系列の最新のセキュリティ版（2.4.8系なら2.4.8-p5）へ上げないと7月のパッチを当てられません。2.4.8のセキュリティパッチのリリースノートでは、2.4.8-p5がAPSB26-49として公開された版です。p5への更新はMariaDB 11.8やOpenSearch 3への対応も含むため、検証環境で先に動かします。

Quality Patches Toolで7月の個別パッチが当たっているかを確かめる

個別パッチは版番号を変えないので、bin/magento --versionの結果は当てた後も同じです。AdobeのAPSB26-73のナレッジ記事は、Adobe Commerce on CloudではQuality Patches Toolのstatusで確かめる手順を示しています。

# Quality Patches Tool を入れていない場合は追加する
composer require magento/quality-patches

# 当たっているパッチの一覧（KB は例として 27015 で絞り込んでいる）
vendor/bin/magento-patches -n status | grep "27015\|Status"

出力の行にAppliedと出れば適用済みです。オンプレミスで手作業で当てた場合は一覧に出ないことがあるため、いつどのファイルを当てたかを変更管理に残します。ツールの入れ方はQuality Patches Toolの使い方にまとまっています。

APSB26-73の個別パッチを系列ごとに当てる手順とWebサーバー側の暫定対策

当てる前に検証環境での確認とバックアップを済ませます。本番を止められないなら、先にWebサーバーの暫定対策を入れます。

製品と系列ごとのZIPの選び方と前提になるセキュリティ版の一覧

AdobeのKBでは、7月の修正は個別パッチ（ZIP）だけで配られ、Composerのパッケージは出ないと明記しています。ZIPには複数の製品向けのファイルが入っているため、入れている製品に合うものだけを使います。

2.4.5と2.4.4のZIPは、Composerの公開鍵と秘密鍵での認証が必要で、Adobe Commerceの契約者向けです。KBの説明では、Open Sourceの利用者が入手できるのは2.4.6以降のパッチだけです。当てる順番も決まっていて、Adobe Commerceの2.4.6-p15なら246p15-2026-07-001-CEのあとに246p15-2026-07-001-EEを当て、B2Bを使っていればB2B用を続けます。パッチは累積ではないため、飛ばさずに順に当てます。

patch -p1でオンプレミスに当てる手順とCloudのm2-hotfixes

オンプレミスでは、Adobeが提供するコンポーザーパッチの適用方法のとおり、Magentoのルートでpatchコマンドを使います。先に--dry-runで当たるかだけを確かめると、途中で失敗して半端な状態になるのを防げます。

# 例：Open Source 2.4.8-p5 の場合（ZIP は KA-37421 の一覧から取得する）
unzip 2-4-8-p5-jul-2026.zip -d /tmp/apsb26-73
ls /tmp/apsb26-73

# 当たるかだけを確かめる（失敗したら -p2 で試す）
patch -p1 --dry-run < /tmp/apsb26-73/<CE 用のファイル名>.patch

# 問題なければ本適用し、キャッシュを消す
patch -p1 < /tmp/apsb26-73/<CE 用のファイル名>.patch
bin/magento cache:flush

Adobe Commerce on Cloudでは、プロジェクトのルートにm2-hotfixesディレクトリを作ってパッチを置き、コミットしてプッシュするとデプロイ時に当たります。KBは、最新のcloud-patchesですでに直っている環境に重ねて当てるとインストールに失敗する、とも注意しています。Cloudの場合は先にQuality Patches Toolで状態を確かめてから置いてください。

アップロード先の実行を止めるnginxとApacheの暫定設定の条件

パッチを当てるまでの暫定対策として、Sansecはアップロード先のpub/media/custom_optionsへのアクセスを一律に断る設定を示しています。nginxでは、\.php$を扱うlocationより前に置くことが条件です。

# nginx：\.php$ の location より前に置く
location ~* ^/pub/media/custom_options/ {
    deny all;
    return 403;
}

# Apache：pub/media/custom_options/.htaccess に置く
<IfModule mod_php.c>
    php_flag engine 0
</IfModule>
Deny from all

# 設定後に外から 403 が返るかを確かめる
curl -s -o /dev/null -w "%{http_code}\n" https://shop.example.jp/pub/media/custom_options/

Apache 2.4で旧来のDeny from allが効かない構成なら、Require all deniedに置き換えます。AccessFileNameで.htaccess以外の名前を使っている場合は、ファイル名も合わせてください。この設定は、置かれたファイルを外から開かせないためのものです。Sansecも、アップロード自体は止まらないと明記しています。ゲスト向けのREST APIへの呼び出しを絞る考え方は、API不正アクセス対策の実装手順で扱ったレート制限と認可の設計が参考になります。

侵害の痕跡をアップロード先・裏口・CMSブロックの順に洗い出す手順

7月より前に公開していたサイトは、パッチの適用とは別に痕跡を確かめます。調べる順番は、アップロード先のcustom_options、裏口のaccesson.php、CMSブロックです。

findでアップロード先の不審なファイルとaccesson.phpを探す

カスタムオプションのファイルを売り場で使っていない店舗では、アップロード先にファイルがあること自体が不審です。Sansecは、.php・.phtml・.pharが見つかれば侵害の強い兆候だとしています。

# アップロード先のファイルを更新日時つきで一覧する
find pub/media/custom_options/ -type f ! -name '.htaccess' -printf '%TY-%Tm-%Td %p\n' | sort

# 実行できる拡張子だけを探す
find pub/media/custom_options/ -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)

# 裏口 accesson.php をドキュメントルート全体から探す
find /var/www -name 'accesson.php' -type f

# ゲストカートへの書き込み要求をアクセスログから拾う
grep -E '"(POST|PUT) /rest/([A-Za-z0-9_]+/)?V1/guest-carts/' /var/log/nginx/access.log*

Sansecの報告では、accesson.phpはpub/assets/images/やvendor/assets/images/など、本来は無いディレクトリに置かれていました。アクセスログは通常の買い物でもゲストカートへの書き込みが出るので、件数ではなく、同じ送信元からの短時間の連続や、ファイル型のオプションを持たない商品への要求を見ます。

cms_blockとcms_pageに差し込まれたスクリプトをSQLで探す

攻撃の最後の段階では、CMSページと静的ブロックにJavaScriptが差し込まれ、来訪者のブラウザで外部から追加のコードを読み込みます。決済画面に届けば、カード情報の盗み取り（Webスキミング）につながる仕組みです。Sansecが挙げた読み込み先のドメインで、データベースを直接検索します。

-- テーブルに接頭辞を付けている場合は名前を合わせる
SELECT block_id, identifier, update_time
  FROM cms_block
 WHERE content LIKE '%lanhd6549tdhse%'
    OR content LIKE '%jslibrary%'
    OR content LIKE '%canevaslab%'
    OR content LIKE '%localStorage%';

SELECT page_id, identifier, update_time
  FROM cms_page
 WHERE content LIKE '%lanhd6549tdhse%'
    OR content LIKE '%jslibrary%'
    OR content LIKE '%canevaslab%'
    OR content LIKE '%localStorage%';

ドメインは攻撃者が入れ替えるため、ここで0件でも安心はできません。update_timeが運用担当の作業日と合わない行を、中身まで開いて確かめます。管理画面の「コンテンツ」から見える範囲だけでなく、データベースの値を見るのが確実です。

侵害の痕跡が見つかったときのカード会社への連絡と報告義務の判断

Webシェルや差し込まれたスクリプトが見つかった場合、ファイルを消す前にサーバーの状態とログを保全します。消してしまうと、いつから何件の入力が盗まれた可能性があるかを説明できなくなります。決済画面にスクリプトが届いていた疑いがあれば、決済代行会社とカード会社への連絡が先です。

店舗側の点検の進め方はfutureshop不正アクセス：4サーバー停止と1店舗漏えい、店舗が今やる点検が参考になります。個人データの漏えいのおそれがある場合の届出の期限は、個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務で確認してください。

パッチの出ない旧Open Sourceを使い続けるかの判断と移行先の考え方

今回いちばん困るのは、Magento Open Sourceの2.4.5以前や、2.4系に上げていない古いサイトを運用しているケースです。条件ごとに結論を分けます。

Open Source 2.4.5以前と2.3系は暫定対策で延命せず移行を決める

Adobeの7月の個別パッチは、Open Sourceでは2.4.6以降にしか出ていません。2.4.5以前と2.3系のサイトは、今回の脆弱性を正式に直す手段がない状態です。nginxやApacheの暫定対策はファイルの実行を止めるだけで、アップロードは続きます。この状態で決済を扱い続けるのは採用しません。

判断の目安は2つです。2.4.6-p15以降へ上げられる見込みが3か月以内に立つなら、暫定対策と痕跡の点検を続けながら更新を進めます。拡張機能の対応が追いつかず見込みが立たないなら、計画の前提にするのはプラットフォームの移行です。カード情報を自社のサーバーで扱わない構成への切り替えも、被害を小さくする手段になります。考え方は決済トークンとは？トークナイゼーションの仕組みと暗号化との違いで整理しています。

カスタムオプションのファイル型を使わない店舗が今すぐ減らせる入口

名入れや入稿データのように購入者からファイルを受け取る機能を使っていないなら、商品のカスタマイズ項目に「ファイル」型が残っていないかを確かめ、不要なものは消します。PolyShellの経路自体はオプションIDを確かめずに動くため、これだけで塞がるわけではありません。それでも、アップロード先にファイルが1つでもあれば不審と判断できる状態になり、痕跡の点検が簡単になります。

逆に、ファイルの受け付けが売上に直結している店舗は、パッチを当てるまでWAFでゲストカートへの書き込み要求を検査する構成を検討します。どちらの店舗でも、Adobeの定期のセキュリティ更新を受けてすぐ当てる作業を、予算と体制に組み込めているかが、次の脆弱性への備えになります。

Magentoの移行・改修を外部へ相談する前に整理しておく4つの情報

Magentoのサイトは拡張機能や独自の改修が多く、見積もりの前に次の4点をそろえておくと話が早く進みます。

1. bin/magento --versionの結果と、Open SourceかAdobe Commerceか
2. 入れている拡張機能の一覧（composer showのmagento以外のベンダー分）
3. 決済の方式（カード情報が自社サーバーを通るか、決済代行会社の画面へ移るか）
4. 今回の痕跡の点検の結果と、点検した日付

他のECパッケージでも、修正ファイルの当て方と対象版の確かめ方の流れは似ています。EC-CUBEでの例はEC-CUBE 4系のMFAバイパス脆弱性CVE-2026-30777の対象版確認と修正手順で解説しました。プラットフォームを選び直す場合の進め方はECサイト構築とは？5つの構築方法の費用相場と判断軸が入口になります。公開中のECサイトに同種の穴が残っていないかを外から点検したい場合は、一創の脆弱性診断・セキュリティ診断でご相談いただけます。

Magentoの脆弱性CVE-2026-48356対応でよく受ける質問と回答

CVE-2026-48356（PolyShell）について、対応の現場で出やすい疑問をまとめました。

Magentoの最新版2.4.9を入れていれば対応は不要ですか？

不要とは言い切れません。AdobeのKBには2.4.9向けの個別パッチ（2-4-9-jul-2026.zip）が用意されており、APSB26-73はPolyShell以外の脆弱性の修正も含みます。2.4.9でも7月の個別パッチを当て、当てた日付を記録してください。

composer updateで版を上げれば7月の修正も入りますか？

入りません。composer updateで上がるのは各系列の最新のセキュリティ版（2.4.8系なら2.4.8-p5）までです。7月の修正はZIPの個別パッチでしか配られないため、その版にそろえたあとでpatchコマンドかCloudのm2-hotfixesで当てる2段階になります。

パッチを当てたあともnginxやApacheの暫定設定は残すべきですか？

残すことを勧めます。カスタムオプションのファイルを外から直接開く必要は通常の運用ではなく、この設定で困る機能はほとんどありません。将来似た問題が出た場合にも、置かれたファイルを動かさない防御として働きます。受け取った画像を管理画面で確認する運用がある場合だけ、その表示に影響が出ないかを検証環境で確かめてください。

痕跡の点検で何も出なければ侵害されていないと判断できますか？

断定はできません。Sansecが公開している痕跡は、実際に観測したファイル名やドメインの一部で、攻撃者は名前や読み込み先を入れ替えます。点検で確かめられるのは「公開された痕跡が無かった」ことまでです。2026年3月から7月まで修正のない状態で公開していたサイトは、ファイルの改ざん検知や、決済画面で読み込まれる外部スクリプトの監視を続けて判断の材料を増やします。管理画面のパスワードとAPIの鍵の入れ替えも、この機会に済ませておくと安全です。

Shopifyなどへの移行と2.4系の更新はどちらが早く片付きますか？

2.4.6以降を使っていて拡張機能が更新に追随しているなら、2.4系の中で上げるほうが早く片付きます。商品・会員・注文のデータを移し替える工程が無く、確かめる範囲が拡張機能と独自の改修に限られるためです。2.4.5以前や2.3系で、独自の改修が多く更新の見積もりが大きくなる場合は、移行と更新の費用を並べて比べます。預けた先で侵害が起きる場合もあるため（例：ショップサーブ情報漏えいの最終報）、移行先では事業者側の対応実績も確かめます。

関連記事

• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：CVSSの各項目とKEVの位置づけの基礎です。
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：ゲスト向けAPIの呼び出しを絞る設計に役立ちます。
• EC-CUBE 4系のMFAバイパス脆弱性CVE-2026-30777とは｜影響版の確認と修正ファイルの適用手順：別のECパッケージでの対象版確認と修正の流れです。
• futureshop不正アクセス：4サーバー停止と1店舗漏えい、店舗が今やる点検：ECサイトの侵害後に店舗がやる点検の例です。
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えいのおそれがあるときの届出期限を確かめられます。