Adobe CommerceとMagentoのCVE-2026-48356とは、ゲストカートからのファイルアップロードとKEV追加

Adobe CommerceとMagento Open Sourceに、買い物かごの商品オプションを通じて、認証なしでサーバーへ任意のファイルを置けてしまう脆弱性があります。CVE-2026-48356です。Adobeは2026年7月14日のセキュリティ情報APSB26-73で修正を出し、CISAは10月27日に、実際の悪用を確認した脆弱性のカタログ(KEV)へ追加しました。

この脆弱性は、オランダのEC専門セキュリティ企業Sansecが2026年3月に「PolyShell」の名前で公表したものです。修正が各系列に届くまで約4か月かかり、その間に大規模な攻撃が続きました。この記事は、ECサイトを開発や運用する担当者と受託開発会社に向けて、CVEレコード、NVD、AdobeのナレッジベースとCISAのKEV、Sansecの解析から、影響版と修正の当て方、更新までの暫定策、侵害の点検手順を整理します。攻撃を再現する手順やペイロードは扱いません。点検のコマンドは、自社が管理する環境か、管理者から明示的に許可を得た環境に限って実行してください。他者が運用する店舗への試行は、不正アクセス禁止法などの関連法令に触れます。事実は執筆時点(2026年11月7日)で確認できた範囲に限ります。

CVE-2026-48356はカートの商品オプションに起因するファイルアップロードの脆弱性#

Magentoの商品には、購入者が名入れの画像などを添付できる「ファイル」型のカスタムオプションを設定できます。Sansecの解析によれば、REST APIでカートに商品を追加するとき、要求の中にfile_infoという項目を入れると、Base64で符号化したファイルの中身、MIMEタイプ、ファイル名がそのまま受け取られ、サーバーに書き込まれます。

Sansecは原因を3つの検査の欠落と説明しています。指定したオプションIDがその商品に本当にあるかの検査、オプションがファイル型かどうかの検査、拡張子の制限です。唯一の検査は画像のヘッダーを確かめる処理で、先頭だけを画像の形式にした、画像とPHPを兼ねるファイル(ポリグロット)で通過できます。PolyShellという名前はこの手口に由来します。

特に危ないのは、ログインしていない買い物客が使うゲストカートの経路です。

ゲストカートのIDは、誰でもAPIで新しく作れます。Sansecによれば、GraphQLのミューテーションは別の処理を通るため、この脆弱性の対象ではありません。

ファイルアップロードの脆弱性の一般的な仕組みと、拡張子や保存先の検査の作り方は、次の記事で解説しています。

あわせて読みたい

ファイルアップロード機能の脆弱性と対策。Webシェルを置かせないための検証と保存の設計

AdobeとSansecで説明の前提が異なる点#

CVEレコードの説明文は、この脆弱性が「現在のユーザーの権限で任意のコード実行につながり、被害者のアカウントやセッションの制御を奪われうる」としたうえで、悪用には被害者が細工されたURLを開くなどのユーザー操作が必要だとしています。CVSSのUI:R(ユーザー操作が必要)とS:C(影響範囲が変わる)は、この説明に対応します。

一方Sansecは、ファイルの書き込みそのものは認証もユーザー操作もなしに成立すると説明しています。書き込まれたファイルがPHPとして実行されるか、ブラウザで読み込まれて格納型XSSになるかは、Webサーバーの設定によって決まります。Adobeの評価は後者のように被害者のブラウザを介する場合を前提にしていると読めますが、実際の攻撃ではPHPのWebシェルを置く使い方が報告されています。CVSSの値だけで優先度を下げないほうが安全です。

Sansecが実行の危険がある構成として挙げているのは次のとおりです。

どの構成でも、ファイル自体はディスクに残ります。Sansecは、アップロード先をWebから拒否してもアップロードそのものは防げないと注意しています。

公表からKEV追加までの経緯#

CISAがKEVへ追加したのは10月ですが、悪用は3月から続いています。

CVEレコードには、CISAの補足情報(ADP)としてSSVCの評価が付いており、悪用(Exploitation)はactive、自動化のしやすさ(Automatable)はno、技術的な影響(Technical Impact)はtotalです。

Sansecの3月30日の報告では、攻撃者はPHPのWebシェルを置いた後、accesson.phpという名前のバックドアを複数のディレクトリにばらまき、CMSのコンテンツにJavaScriptの読み込み処理を埋め込んでいました。10月24日の報告では、同じ運営者とみられる攻撃で、2025年7月以降に953店舗が被害を受けたとしています。埋め込み先はデータベースのcms_blockテーブルで、訪問者のブラウザのlocalStorageに処理を残すため、外部のドメインを止めても訪問者の側で処理が再実行されると説明しています。

なお、2.4.9の扱いは資料によって異なります。Sansecは5月の2.4.9に修正が入ったとしていますが、AdobeのCVEレコードとナレッジベースは2.4.9を影響ありとし、2.4.9-2026-julを修正版としています。判断はAdobeの記載に合わせ、2.4.9にも7月の個別パッチを当てます。

影響を受ける版と修正版#

CVEレコードの影響範囲は次のとおりです。修正版の表記はCVEレコードのもので、各系列の版に7月の個別パッチを当てた状態を指します。

AdobeのナレッジベースはAdobe Commerce on cloud infrastructure、オンプレミスのAdobe Commerce、Magento Open Sourceを対象に挙げています。クラウド版は最新のcloud-patchesの更新で修正されており、その状態で個別パッチを重ねて当てるとインストールに失敗することがあるとしています。

APSB26-73の個別パッチを当てる手順#

APSB26-73の修正は、従来の-p版のような新しいリリースではなく、各系列の版に当てる個別パッチ(Isolated patch)として配布されています。Adobeのナレッジベースは、今月のセキュリティパッチがComposerのパッケージとして提供されない理由を別に説明しています。composer.lockの版番号だけでは、修正済みかどうかを判断できません。

個別パッチは、Adobeがサポートしている系列にだけ提供されます。古い系列の店舗は、サポート期間をAdobeのリリース資料で確かめ、上位系列への移行を計画します。

更新までの暫定策はアップロード先の拒否とWAF#

パッチを当てるまで時間がかかる店舗は、ファイルの実行を止める設定と、アップロードの要求そのものを止める設定を組み合わせます。

1つ目は、アップロード先をWebから拒否する設定です。Sansecはnginxについて、PHPを処理するlocationより前に次の設定を置くよう勧めています。Magentoはドキュメントルートをpub/にする構成が多く、その場合はURLが/media/custom_options/になるため、下の例では両方に合うよう正規表現を少し広げています。

location ~* ^/(pub/)?media/custom_options/ {
    deny all;
    return 403;
}

Apacheでは、pub/media/custom_options/.htaccessに次の内容があるかを確かめます。AccessFileNameを既定から変えている場合は、その名前のファイルにします。このディレクトリでAllowOverride Noneになっている構成では.htaccessが読まれないため、同じ拒否をサーバー設定側に書きます。

<IfModule mod_php.c>
    php_flag engine 0
</IfModule>
Deny from all

あわせて、pub/media/の下全体でPHPが実行されない設定になっているかも確かめます。設定を入れたら、/media/custom_options/の下のパスへcurlで要求し、403が返ることを確認します。PHPの処理が先に当たる設定の誤りを見つけるため、末尾が.phpのパスでも403になるかを確かめます。

2つ目は、WAFでゲストカートへの要求を止める設定です。Sansecは、攻撃を止められるのはAPIの呼び出し自体を遮断する方法だけだとしています。/V1/guest-carts/の下のitemsへのPOSTとPUTで、本文にfile_infoを含むものを拒否するルールが目安です。実際のURLは/rest/V1/や、ストアコードを挟んだ/rest/default/V1/の形になるため、両方に合うようにします。Sansecは、ゲストカートが最も危ない経路である一方で、脆弱な経路はそれだけではないとも書いています。ルールはゲストカートに限らず、本文にfile_infoを含むカートAPIへの要求を広く対象にします。ファイル型のカスタムオプションを使っていない店舗では、正規の注文への影響は出にくいと考えられます。Sansecによれば、Akamaiは3月27日にWAFの保護を追加しています。利用中のWAFやCDNが対応ルールを出しているかは、各事業者の告知で確認します。

WAFの置き方と、ルールを本番で有効にする前の確かめ方は、次の記事で整理しています。

あわせて読みたい

WAFの役割と限界、正しい使い方。シグネチャと振る舞い、回避される前提、根本対策との補完

侵害がなかったかを点検する手順#

パッチを当てても、それより前に置かれたファイルやデータベースの書き換えは残ります。CISAのKEVのこの項目ではforensicTriageがNoになっていますが、3月から攻撃が続いていたため、修正済みの店舗も一度は点検します。Sansecは、コアのパッチをすべて当てていた店舗にもスクリプトが埋め込まれた例を報告しており、別の入口が使われた可能性もあります。

点検に使うコマンドの例です。Sansecの記載に合わせ、Magentoの設置先のディレクトリで実行します。いずれも自社が管理するサーバーか、許可を得たサーバーで、読み取りだけを行います。

# custom_optionsとcustomer_addressの下の、.htaccess以外のファイル
find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'

# バックドアのファイル名(設置先の全体)
find . -name 'accesson.php' -type f

SELECT block_id, identifier, update_time FROM cms_block
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';

SELECT page_id, identifier, update_time FROM cms_page
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';

痕跡が見つかった場合は、ログとファイルを保全したうえで、埋め込まれたスクリプトとファイルを取り除きます。スクリプトを消しただけでは入口が開いたままなので、Sansecは続けて、攻撃者が使った脆弱性やバックドアを突き止めるよう求めています。また、スクリプトを消しても攻撃者がデータベースへ書き込める状態は残るとして、データベース、管理者、API連携のパスワードの変更を勧めています。決済画面に手が入っていた可能性があれば、決済代行会社やカード会社への連絡も必要になります。

侵害を疑ったときの最初の動き方は、次の記事にまとめています。

あわせて読みたい

インシデント発生時の初動対応。最初の1時間で何をするか

同じ時期のMagentoの脆弱性との関係#

Sansecの10月の報告では、この脆弱性と並んで、セッションの扱いに起因するSessionReaper(CVE-2025-54236)も侵入の入口に挙げられており、両方の修正を当てるよう勧めています。2026年9月に公表された別の0day、StyleSmuggler(CVE-2026-75650)は、テンプレートの処理に起因する別の脆弱性で、修正も別です。どれか1つを当てただけでは足りないため、Commerce Version Toolで対応済みのCVEを一覧で確かめます。

StyleSmugglerの仕組みと対応は、次の記事で解説しています。

あわせて読みたい

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

チェックリスト#

まとめ#

CVE-2026-48356は、カートの商品オプションのファイル処理で、拡張子を制限せずにファイルを保存してしまう脆弱性です。Sansecによれば、認証のいらないゲストカートのAPIから悪用でき、3月の公表直後から大規模な攻撃が続きました。Adobeは7月14日のAPSB26-73で各系列に修正を出し、CISAは10月27日にKEVへ追加しています。

対策の中心は、各系列の最新の-p版にそろえたうえでの個別パッチの適用と、後続の月次パッチの順番どおりの適用です。更新までの間は、アップロード先のWebからの拒否とWAFでの遮断を組み合わせます。修正済みの店舗も、custom_optionsの下のファイルとCMSブロックを一度は点検します。

脆弱性の対応順をKEVやEPSSで決める考え方は、次の記事で整理しています。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方