MagentoのPolyShell、米CISAが悪用を確認 修正後も侵入の跡を点検

7月の修正を当てたMagentoの店でも、それより前に入られていたなら、攻撃者はまだ中にいるかもしれません。米CISAは2026年10月27日（米国時間）、Adobe CommerceとMagento Open Sourceの脆弱性CVE-2026-48356を、悪用が確認された脆弱性の一覧（KEV）に加えました。オランダのセキュリティ会社Sansecが「PolyShell」と名付けた、ファイルのアップロードの脆弱性です。

もっとも、悪用は今に始まった話ではありません。Sansecは3月19日に最初の攻撃を見つけ、同社の年表には、4月14日の時点で「全店舗の82%」に不正なファイルが送り込まれたとあります。Adobeが今の版向けの修正APSB26-73を出したのは7月14日。正式な修正が無いまま、4か月近くが過ぎていました。

カートのAPIから、画像を装ったPHPを置ける

PolyShellは、商品に付ける「カスタムオプション」の仕組みにあります。Magentoでは、注文のときに買い手がファイルを添えられるオプションを作れます。REST APIはそのファイルを受け取り、サーバーのpub/media/custom_options/quote/に書き込みます。

ところが、ここで3つの確認が抜けていました。送られたオプションがその商品のものか、ファイル型のオプションか、拡張子が.phpや.pharでないか。どれも見ていなかった、とSansecは書いています。調べていたのは、中身が画像に見えるかどうかだけです。そこで攻撃者は、GIFやPNGとして正しく、同時にPHPのコードも含むファイルを送り込みました。

入口は、ログインしていない客のカートのAPI（/V1/guest-carts/…/items）で、認証は要りません。GraphQLは別の処理を通るため対象外です。置いたファイルが実際に動くかは、Webサーバーの設定しだい。ホスティング会社の独自の設定で、アップロードの置き場所のPHPが動いてしまう店が多かったといいます。

Adobeの評価は、深刻度が「Critical」、CVSSの基本値が9.6です。影響は「権限の昇格」としていますが、CISAは、利用者の権限でコードを実行されるおそれがあると説明しています。

対象の版と、7月の修正版

APSB26-73は、CVE-2026-48356を含む14件の脆弱性をまとめて直した更新です。対象と修正版は次のとおりです。

修正版があるのは、Adobe Commerceが2.4.4の系列から、Magento Open Sourceが2.4.6の系列からです。それより古い版には、修正版がありません。なお、表はAPSB26-73の14件全体の対象で、Sansecは、5月12日に出た2.4.9でPolyShellは直ったとしています。

Adobeのページには、今も「悪用は把握していない」とあります。最終の更新は8月11日のままです。一方のCISAは、悪用の証拠をもとにKEVに加えました。

しかも、7月の修正だけで済むわけではありません。9月には「StyleSmuggler」（CVE-2026-75650）、10月には「BlockStrap」（CVE-2026-103849）と、外から乗っ取れる脆弱性の修正が続いています。10月の分はMagentoに外から乗っ取れる脆弱性「BlockStrap」 修正は手で当てるで取り上げました。

修正しても、入った攻撃者は出ていかない

Sansecが10月24日に出した報告は、修正のあとの話です。ある攻撃者の一団は、店のページに短いスクリプトを差し込み、訪れた人のブラウザーに次の指示を取りに行かせていました。2025年7月からの15か月で953店に仕込み、指示の置き場所のドメインは5回替えています。10月7日からの新しいドメインdeepveindrilling.comは83店で見つかり、うち60店は、前のドメインのころからの被害店でした。

中には、修正の済んだ店もありました。Magento 2.4.7-p10で、本体の修正に抜けが無い店です。10月23日、スキャンで何も見つからなかった1時間後に、不正なスクリプトが書き込まれました。この店では9月16日に見覚えのない管理者のアカウントが、9月24日にGSocketというバックドアが見つかっていたといいます。

つまり、修正は入口をふさぐだけで、すでに中にいる攻撃者は追い出しません。スクリプトの置き場所はデータベースのcms_block（静的なブロック）で、テーマのファイルではありませんでした。スクリプトを消しても、データベースに書き込める状態は残る、とSansecは注意しています。

来店者の側にも、跡は残ります。ブラウザーのlocalStorageに保存された中身は、置き場所のドメインを止めたあとも、ページを開くたびに動きます。スクリプトは自動のブラウザーやスキャナーには何も返さないため、外から店を見て回るだけでは気づきにくいでしょう。過去には、ログインした客に、暗号資産のウォレットのLedgerに似せた偽のページを出していました。

影響を受けるのは、MagentoやAdobe CommerceでECサイトを動かす会社

• 7月の修正より前の版で動いているAdobe Commerce・Magento Open Sourceの店は、すぐに修正が要ります。KEVでの期限は11月10日です。
• 7月より前から公開していた店は、修正を当てたあとでも、侵入の跡の点検が要ります。3月から7月までの約4か月、正式な修正がありませんでした。
• 制作会社や保守会社にサイトを任せている会社も同じです。自社では版を把握していないことが多く、先方に聞くことになります。
• Shopifyなど、Magentoを使わないカートやECのサービスで店を出している会社は、この脆弱性の対象ではありません。

保守の委託先と一緒に進める点検の手順

1. 版を確認します。bin/magento --versionやcomposer.lockで系列とパッチの水準を見て、7月の「2026-jul」の版か、それより新しいかを見ます。9月と10月の修正が当たっているかも、同じ機会に聞いておきます。
2. アップロードの置き場所を調べます。pub/media/custom_options/とpub/media/customer_address/に、.htaccess以外のファイルが無いかを見ます。.phpや.phtml、.pharがあれば、入られた疑いが強い状態です。
3. バックドアを探します。accesson.phpという名前のファイルを、公開の領域の全体で探します。1つの店の10か所に同じファイルが置かれた例を、Sansecは挙げています。
4. データベースを見ます。cms_blockとcms_pageの中身に、fpCode・se_referrer・localStorage.getItemを含むものが無いかを検索し、admin_userに見覚えのないアカウントが無いかも確認します。
5. 見つかったら、取り除いたうえで、データベース・管理画面・APIの連携のパスワードを替えます。カードの情報が抜かれたおそれがあれば、決済代行会社やカード会社へ早めに連絡します。

4の検索は、Sansecの例では次の形です。テーブルに接頭辞を付けている店は、名前を合わせます。update_timeを見れば、攻撃者が最後に書き込んだ日時も分かります。

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

保守を委託しているなら、版の番号だけでなく、点検をいつ、誰が、どこまでしたかを文書で受け取っておきたいところです。カード情報が漏れたときの国内の決まりと連絡の先は、AIエージェントが通販サイト数百社を攻撃 カード情報60万件超、情シスの点検にまとめています。