--- title: "Magentoの脆弱性CVE-2026-48356とは：PolyShellの対象版・確認コマンド・パッチ適用手順" url: "https://www.issoh.co.jp/tech/details/19023/" published: 2026-10-28 updated: 2026-10-28 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 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のアドバイザリ](https://sansec.io/research/magento-polyshell)によると、入口はログイン不要のゲストカートの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の記録](https://nvd.nist.gov/vuln/detail/cve-2026-48356)では、CVE-2026-48356は「危険な種類のファイルの無制限アップロード」（CWE-434）で、CVSS v3.1は9.3（Critical）です。Adobeの評価は、ネットワーク経由・権限不要ですが、利用者の操作（UI:R）を前提にしています。CVSSの各項目の読み方は[脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務](https://www.issoh.co.jp/tech/details/13546/)で整理しています。 一方でSansecは、ログインも利用者の操作もなしにファイルを置けると説明しています。NVDの参照先にはSansecのPolyShellの記事が入っています。前提がずれていても優先度は下げません。CISAが「実際に悪用されている」と判定したことがKEV登録の理由です。 ### 2026年3月の公表から10月27日のKEV追加までに起きたこと 時系列で並べると、本番向けの修正が出るまでに約4か月の空白がありました。 | 日付 | 出来事 | 出典 | | ----------- | ------------------- | ------ | | 2026年3月16日 | Sansecが悪用を初めて観測 | Sansec | | 2026年3月17日 | SansecがPolyShellを公表 | Sansec | | 2026年3月30日 | 1時間で471店舗の侵害を観測 | Sansec | | 2026年5月12日 | 修正を含む2.4.9が公開 | Sansec | | 2026年7月14日 | APSB26-73で旧系列へ修正 | Adobe | | 2026年7月14日 | NVDにCVEが公開 | NVD | | 2026年10月27日 | CISAがKEVへ追加 | CISA | 3月30日の報告は[Sansecの大規模攻撃の記事](https://sansec.io/research/polyshell-mass-attack-wave)にあり、置かれたWebシェルが複数のディレクトリへ`accesson.php`を配り、最後にCMSページやブロックへ難読化したJavaScriptを差し込む流れが自動化されていたと書かれています。[CISAのKEVカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)への追加で、米国連邦機関には11月10日までの対応が課されました。 ## 自社のMagentoとAdobe Commerceが対象かを版とパッチの有無で確かめる手順 判定は「製品と系列」「その系列の中の版」「7月の個別パッチが当たっているか」の順に進めます。Composerの版番号だけでは、個別パッチの有無が分からない点に注意してください。 ### NVDとAdobeが示す製品ごとの対象版と個別パッチの提供範囲 NVDの記録に載っている対象は、次の4製品です。Adobe Commerceを契約していない自社構築のサイトは、ほぼMagento Open Sourceに当たります。 | 製品 | 対象になる版 | 修正 | | ----------------------- | ------------ | -------- | | Adobe Commerce | 2.4.4〜2.4.9系 | 7月の個別パッチ | | Magento Open Source | 2.4.6〜2.4.9系 | 7月の個別パッチ | | Adobe Commerce B2B | 1.3.3〜1.5.3系 | 7月の個別パッチ | | I/O Events for Commerce | 1.20.0以前 | 1.21.0 | 系列ごとの上限は、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のセキュリティパッチのリリースノート](https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/security-patches/2-4-8-patches)では、2.4.8-p5がAPSB26-49として公開された版です。p5への更新はMariaDB 11.8やOpenSearch 3への対応も含むため、検証環境で先に動かします。 ### Quality Patches Toolで7月の個別パッチが当たっているかを確かめる 個別パッチは版番号を変えないので、`bin/magento --version`の結果は当てた後も同じです。[AdobeのAPSB26-73のナレッジ記事](https://experienceleague.adobe.com/ja/docs/experience-cloud-kcs/kbarticles/ka-37421)は、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の使い方](https://experienceleague.adobe.com/ja/docs/commerce-operations/tools/quality-patches-tool/usage)にまとまっています。 ## APSB26-73の個別パッチを系列ごとに当てる手順とWebサーバー側の暫定対策 当てる前に検証環境での確認とバックアップを済ませます。本番を止められないなら、先にWebサーバーの暫定対策を入れます。 ### 製品と系列ごとのZIPの選び方と前提になるセキュリティ版の一覧 AdobeのKBでは、7月の修正は個別パッチ（ZIP）だけで配られ、Composerのパッケージは出ないと明記しています。ZIPには複数の製品向けのファイルが入っているため、入れている製品に合うものだけを使います。 | 系列 | 前提になる版 | 入手の条件 | | ----- | --------- | ------------- | | 2.4.9 | 2.4.9 | 誰でも入手可 | | 2.4.8 | 2.4.8-p5 | 誰でも入手可 | | 2.4.7 | 2.4.7-p10 | 誰でも入手可 | | 2.4.6 | 2.4.6-p15 | 誰でも入手可 | | 2.4.5 | 2.4.5-p17 | Commerceの鍵が必要 | | 2.4.4 | 2.4.4-p18 | Commerceの鍵が必要 | 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が提供するコンポーザーパッチの適用方法](https://experienceleague.adobe.com/ja/docs/support-resources/adobe-support-tools-guide/adobe-commerce-support/how-to-apply-a-composer-patch-provided-by-magento)のとおり、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/.patch # 問題なければ本適用し、キャッシュを消す patch -p1 < /tmp/apsb26-73/.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 に置く php_flag engine 0 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不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で扱ったレート制限と認可の設計が参考になります。 ## 侵害の痕跡をアップロード先・裏口・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店舗漏えい、店舗が今やる点検](https://www.issoh.co.jp/tech/details/19013/)が参考になります。個人データの漏えいのおそれがある場合の届出の期限は、[個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)で確認してください。 ## パッチの出ない旧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か月以内に立つなら、暫定対策と痕跡の点検を続けながら更新を進めます。拡張機能の対応が追いつかず見込みが立たないなら、計画の前提にするのはプラットフォームの移行です。カード情報を自社のサーバーで扱わない構成への切り替えも、被害を小さくする手段になります。考え方は[決済トークンとは？トークナイゼーションの仕組みと暗号化との違い](https://www.issoh.co.jp/tech/details/15726/)で整理しています。 ### カスタムオプションのファイル型を使わない店舗が今すぐ減らせる入口 名入れや入稿データのように購入者からファイルを受け取る機能を使っていないなら、商品のカスタマイズ項目に「ファイル」型が残っていないかを確かめ、不要なものは消します。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の対象版確認と修正手順](https://www.issoh.co.jp/tech/details/11295/)で解説しました。プラットフォームを選び直す場合の進め方は[ECサイト構築とは？5つの構築方法の費用相場と判断軸](https://www.issoh.co.jp/column/details/15234/)が入口になります。公開中のECサイトに同種の穴が残っていないかを外から点検したい場合は、一創の[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)でご相談いただけます。 ## 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系で、独自の改修が多く更新の見積もりが大きくなる場合は、移行と更新の費用を並べて比べます。預けた先で侵害が起きる場合もあるため（例：[ショップサーブ情報漏えいの最終報](https://www.issoh.co.jp/tech/details/16098/)）、移行先では事業者側の対応実績も確かめます。 ## 関連記事 - [脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説](https://www.issoh.co.jp/tech/details/13546/)：CVSSの各項目とKEVの位置づけの基礎です。 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効](https://www.issoh.co.jp/tech/details/18346/)：ゲスト向けAPIの呼び出しを絞る設計に役立ちます。 - [EC-CUBE 4系のMFAバイパス脆弱性CVE-2026-30777とは｜影響版の確認と修正ファイルの適用手順](https://www.issoh.co.jp/tech/details/11295/)：別のECパッケージでの対象版確認と修正の流れです。 - [futureshop不正アクセス：4サーバー停止と1店舗漏えい、店舗が今やる点検](https://www.issoh.co.jp/tech/details/19013/)：ECサイトの侵害後に店舗がやる点検の例です。 - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：漏えいのおそれがあるときの届出期限を確かめられます。 --- 出典: [Magentoの脆弱性CVE-2026-48356とは：PolyShellの対象版・確認コマンド・パッチ適用手順]()（株式会社一創）