Adobe Commerce / Magentoの脆弱性は、修正の公開から105日後にCISAの悪用確認リストへ載った。月の名前が付いたパッチ名を版の表示で読む ── ECサイトの基盤の更新を確かめる13項目（2026年10月時点）

目次

1. 01 何が書いてあるか — Adobe Commerce / Magentoが10月27日に悪用確認リストへ載った。修正は7月14日に出ていた
   1. カタログの行を読む
   2. 日付の間隔を数える
   3. 「悪用はつかんでいない」と「悪用の証拠がある」
2. 02 なぜ・背景 — 「直った版が出た日」と「急ぐべき日」は別の日になる
   1. 修正の公開日は、安全になった日ではない
   2. 間隔の理由は、日付からは分からない
   3. 運用を任せていると、誰も数えない
   4. 期限の欄は、日本の会社には義務ではない
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 月の名前の付いたパッチ名の読み方
   2. CVSSの「Critical」
4. 04 型別 — 対象の版、確かめられないこと、確かめる手順
   1. 🅰 適用範囲 — 製品ごとの影響を受ける版
   2. 🅱 この情報が測っていないこと
   3. 🅲 手順1 — ECサイトの基盤が何かを、運用者に聞く
   4. 🅲 手順2 — 版の表示を読んで、パッチ名と突き合わせる
   5. 🅲 手順3 — アップロードを受け付ける欄を数える
   6. 🅲 手順4 — 運用を委託している場合の聞き方
   7. 🅲 手順5 — 間隔を、自分の更新の決まりにする
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — すぐに更新できないときの考え方
   1. CISAの必要な対応の欄は、3つの選択肢を書いている
   2. 更新の知らせを待つ側の工夫
7. 07 当サイトで確かめたこと — ECの基盤は動かしていない
8. 08 このテーマは、ここまで — 悪用確認リストを追った記事の流れ
   1. これまでの記事
   2. 今回の記事の位置
9. 09 この記事のまとめ

01 何が書いてあるか — Adobe Commerce / Magentoが10月27日に悪用確認リストへ載った。修正は7月14日に出ていた

CISA（米国のサイバーセキュリティの政府機関）の「悪用が確認された脆弱性」の一覧に、2026年10月27日、Adobe Commerce / Magentoの脆弱性CVE-2026-48356が加わった。Adobe CommerceとMagento Open Sourceは、ECサイト（ネットショップ）を動かす基盤のソフトである。会社のECサイトがこの基盤で動いていると、サイトの訪問者に見える画面の裏側で、この脆弱性の影響を受けうる。

この件で目を引くのは、日付である。Adobeが修正を出したのは2026年7月14日で、悪用の確認を受けた一覧への追加は10月27日だった。この記事は、脆弱性の中身の解説ではなく、「直った版が出た日」と「急ぐべき日」の間隔を日付から読む方法と、月の名前が付いたパッチ名の読み方に絞る。一覧の期限の欄の読み替えは、既存の解説記事に任せて、リンクで済ませる。

カタログの行を読む

CISAのカタログでCVE-2026-48356の行を開き、NVDの記録と、Adobeの告知のページを開いた。3つの記述を、同じ表にまとめる。

NVDの説明文の要旨は、危険な種類のファイルを、制限なしにアップロードできる問題があり、現在の利用者の権限で任意のコードが実行される場合がある、というものである。悪用には利用者の操作が要り、影響の範囲が変わる、とも書かれている。CISAの行の必要な対応の欄は、ベンダーの指示に沿った緩和策、BOD 26-04の手引き、緩和策がなければ製品の使用をやめること、そして、資産ごとにインターネットへの公開の有無を評価することを書いている。影響の書き方は、Adobeの告知が権限の昇格、NVDの説明文が任意のコードが実行される場合があること、と違っていて、同じ脆弱性を2つの文書が別の言い方で書いている。

日付の間隔を数える

7月14日から10月27日までを数える。7月の残りが17日、8月が31日、9月が30日、10月27日までが27日で、合計105日になる。一覧への追加から期限の欄（11月10日）までは14日、7月14日から期限の欄までは119日になる。Adobeの告知の最終更新（8月11日）から一覧への追加までは77日である。

「悪用はつかんでいない」と「悪用の証拠がある」

Adobeの告知（8月11日の更新）は、この更新で直した問題について、悪用の事例はつかんでいない、と書く。一方、CISAの一覧は、10月27日の時点で、悪用の信頼できる証拠があるから載せた。2つは矛盾しない。書かれた日が違う。告知は8月11日までの状況を書き、一覧は10月27日の状況を書いている。Adobeの告知が書き換えられたかどうかは、筆者が開いた時点では分からない。

02 なぜ・背景 — 「直った版が出た日」と「急ぐべき日」は別の日になる

修正の公開日は、安全になった日ではない

修正版が出た日は、「直せるようになった日」である。自分のサイトに当てた日が、そのサイトにとって「安全になった日」にあたる。ECサイトの基盤の更新は、決済や在庫やテーマ（見た目）に影響しうるため、すぐに当てられないことがある。その結果、修正が公開されてから、自分のサイトに当たるまで、数か月かかる場合が出る。今回の105日は、その間隔の長さを示す日数の1つである。

間隔の理由は、日付からは分からない

7月に出た修正が、10月に悪用の確認を受けた。この間に何があったか、つまり、なぜ10月だったのか、誰が悪用したのかは、CISAの行にも、NVDにも、Adobeの告知にも書かれていない。理由は書かれていないので、この記事も理由を書かない。読めるのは、日付の間隔だけである。間隔から言えることは1つだけで、「修正を7月に当てていたサイトには、10月27日の追加で新しい作業は増えない」ということである。当てていなかったサイトは、10月27日から先を急ぐ。

運用を任せていると、誰も数えない

ECの基盤の更新は、制作会社やECの運用会社に任せていることが多い。任せている側の担当者は、パッチ名を見ても、それが自分のサイトの何に当たるかが分かりにくい。任された側は、「更新の知らせは担当者に送ったはず」と考えがちである。これは筆者の読みで、誰かの落ち度を指す話ではない。7月の修正が当たっているかを、誰が数える担当なのかが決まっていなければ、数えられないまま秋を迎える。

期限の欄は、日本の会社には義務ではない

一覧の期限の欄の日付は、米国の連邦の行政機関に向けた決まりである。CISAの説明のページは、連邦の行政機関には、決められた期間内に直す義務があると書き、ほかの組織には義務はないが、優先して直すよう強く勧める、と書く。読み替え方は、CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）に書いた。

03 用語 — 出てくる言葉を、先にそろえる

月の名前の付いたパッチ名の読み方

Adobeの告知に出てくる修正版の名前を、読み方の例として並べる。2.4.9-2026-julは、「2.4.9」の系列に、「2026年7月」の更新を当てた版、と読める（筆者の読み）。告知の日付が7月14日なので、月の名前が公開の月に対応していると考えるのが自然である。ただし、月の名前の付け方の決まりを、Adobeの公式の説明で確かめることは、この記事ではできなかった。

CVSSの「Critical」

CVSSは、脆弱性の深刻さを0から10の点数で表す仕組みである。9.0以上は「Critical」（重大）と呼ばれる。今回は、Adobeの告知が9.6、NVDの記録が9.3で、点数が違う。NVDの記録の9.3は、NVDとAdobe（CVEを登録する側）の両方の値である。違いの理由は、どちらの文書にも書かれていない。点数が高いことと、悪用が確認されたことは別の話で、今回は2つが重なっている。

04 型別 — 対象の版、確かめられないこと、確かめる手順

🅰 適用範囲 — 製品ごとの影響を受ける版

Adobeの告知（APSB26-73）に書かれた、影響を受ける版を表にした。

この表は、告知の全体の対象である。CVE-2026-48356が、このうちどの製品に当たるかは、NVDの記録に書かれた範囲（Adobe Commerceの2.4.4から2.4.9、B2Bの1.3.3から1.5.3、Magento Open Sourceの2.4.6から2.4.9、Eventsの1.6.0以上1.21.0未満）から読む。告知の本文の中で、このCVEの行をひとつずつ確かめることは、この記事ではしていない。

🅱 この情報が測っていないこと

3つの公式情報が書いていないことも多い。どのサイトが実際に悪用されたか、いつから悪用されていたか、誰が悪用したかは、どこにも書かれていない。7月から10月までの間に何が起きたかも書かれていない。また、自分のサイトの版が何かは、公式の情報からは分からない。EC基盤の版は、外から見えないことが多く、運用者に聞くしかない。この記事は、攻撃の方法や手順を書かない。守る側が確かめられるのは、版、パッチ名、アップロードを受け付ける欄、運用の委託先の答えの4つである。

🅲 手順1 — ECサイトの基盤が何かを、運用者に聞く

最初の作業は、会社のECサイトが、Adobe CommerceかMagento Open Sourceかを聞くことである。外から見える画面だけでは、基盤は分からないことが多い。聞く相手は、制作会社の窓口、ECの運用会社、サーバーの運用者である。「Adobe CommerceかMagento Open Sourceか、別の基盤か」の3択で聞くと、返事が短く返る。別の基盤なら、今回の件は台帳に「対象外」と書いて終わる。

🅲 手順2 — 版の表示を読んで、パッチ名と突き合わせる

基盤が対象なら、運用者に、今の版の表示を見せてもらう。表示の場所と出し方は、筆者が開いたAdobeのページ（リリース済みの版の一覧、リリースノートの概要）には書かれていなかったので、確かめられていない。画面かコマンドの出力を、運用者に写してもらう。写したら、次の順で比べる。

1. 系列（2.4.9、2.4.8、2.4.7など）が、上の表のどれに当たるかを見る。
2. 末尾が「-p」と数字なら、その数字が表の「以前」に収まるかを見る。2.4.8-p5なら、影響を受ける版の最後の番号である。
3. 末尾が「-2026-jul」なら、7月の修正版と読める（筆者の読み）。その後に、さらに新しい更新が出ていないかは、Adobeの案内で確かめる。

系列によっては、末尾に何も付かない（例: 2.4.9）。2.4.9は、告知の影響を受ける版の一覧に出ているので、末尾に「-2026-jul」が付いていなければ、修正は入っていないと読む。「-p」が付いた名前は、告知の書き方では、「以前」と一緒に出てくる。自分の版が「-p」付きで、その番号が表の「以前」に収まるなら、7月の修正版に上げる予定が必要になる。

🅲 手順3 — アップロードを受け付ける欄を数える

この脆弱性の種類は、アップロードの欄が、危険な種類のファイルを受け付けてしまう、というものである。守る側が確かめられるのは、自社のECサイトに、アップロードを受け付ける欄がいくつあって、それぞれが何を許すかである。欄の例は次のとおり。

• 商品の画像を登録する欄（管理画面）
• 商品の説明に添付するファイルの欄
• お客様がファイルを添付できる欄（見積もりの依頼、返品の理由など）
• 管理画面の、一括の取り込みの欄

欄ごとに、画面の説明文に書かれた「受け付ける種類」を書き写す。説明文がなければ、運用者に聞く。画像だけの欄が、画像以外の種類も受け付けていないかを見る。試す場合は、本番ではなく、自社の試験用の環境だけで、中身が無害な1行の文字だけのファイル（拡張子は.txt）を入れて、断られるかを見る。断られれば、その欄は種類を絞っている。受け付けてしまったら、運用者に伝えて、設定を直してもらう。

🅲 手順4 — 運用を委託している場合の聞き方

運用を任せている場合は、次の5つを、書面で聞く。口頭の返事は、あとで残らない。

1. うちのECサイトの基盤と、今の版は何か。
2. 2026年7月14日のAdobeの告知（APSB26-73）の修正を当てたか。当てたなら、いつか。
3. 当てていないなら、理由は何か、いつ当てる予定か。
4. 7月の修正を当てた後に、サイトの動作の確認（決済、在庫、テーマ）をしたか。
5. 今後、Adobeが更新を出したとき、何日以内に当てる決まりがあるか。

3番目の理由は、遅れを責めるためではなく、当てられない事情の中身を知るために聞く。決済の確認に時間がかかる、テーマが新しい版で崩れる、といった理由なら、更新の手順そのものを見直す材料になる。

🅲 手順5 — 間隔を、自分の更新の決まりにする

今回の105日を、自社の決まりにするなら、筆者の案は次のとおりである。「提供元が修正を出した日から、14日以内に当てる」（筆者の案で、公式の基準ではない）。14日は、一覧の追加日から期限の欄までの日数に合わせた。社内の事情で14日が無理なら、30日でもよいが、その場合は、延ばした理由を台帳に書く。決まりがないと、105日のような間隔が、誰の責任でもなく生まれる。

05 明日、担当サイトで確認できることチェックリスト

以下は、ECサイトの基盤の更新が7月の修正まで届いているかを確かめ、更新の間隔を自社の決まりにする13項目である。1〜3番目は公式情報の読み取り、4〜6番目はECサイトの基盤と版の確認、7〜9番目はアップロードの欄の確認、10〜12番目は委託先への確認、13番目は更新の決まりの記録である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• CISAの悪用確認リストのカタログを開き、「Adobe」で絞って、CVE-2026-48356の行の追加日（10月27日）と期限の欄（11月10日）をメモ帳に書き写す
• Adobeの告知（APSB26-73）を開き、告知の日（7月14日）と最終更新（8月11日）をメモ帳に書き写して、追加日までの日数を数える
• 告知の影響を受ける版の表から、自社の基盤（Adobe Commerce、Magento Open Source）の行を選び、系列ごとの修正版の名前を書き写す
• 会社のECサイトの基盤が、Adobe Commerce、Magento Open Source、別の基盤のどれかを、運用者に1通のメッセージで聞く
• 返事が「別の基盤」なら、台帳に「CVE-2026-48356は対象外・確認日」を1行書く。返事が対象なら、基盤の名前を台帳の1行目に書く
• 対象の基盤について、運用者に版の表示を見せてもらい、系列とパッチ名をそのまま書き写す
• 写したパッチ名が、「-2026-jul」で終わるか、「-p」と数字で終わるかを、台帳の「修正の状態」の列に書き分ける
• ECサイトで、アップロードを受け付ける欄を、商品の画像、添付、お客様の添付、一括の取り込みの4つから探し、画面で見つかった数を書く
• 見つかった欄ごとに、画面の説明文に書かれた「受け付ける種類」を書き写し、説明文がない欄は運用者に聞く項目に入れる
• 自社の試験用の環境がある場合だけ、その環境で、画像だけの欄に、中身が1行の文字だけの.txtのファイルを入れて、断られるかを1欄ずつ見る
• 運用を委託している場合は、「7月14日の修正を当てたか、いつか」を、委託先へ書面で聞く
• 「当てていない」と返事が来たときのために、理由、当てる予定日、当てた後の動作確認の3つを聞く質問文を、下書きに保存する
• 提供元の修正を何日以内に当てるかを、自社の決まりとして1行で決め、台帳の見出しに書く

06 代替・他の選択肢 — すぐに更新できないときの考え方

CISAの必要な対応の欄は、3つの選択肢を書いている

CISAの行は、必要な対応として、ベンダーの指示に沿った緩和策、BOD 26-04の手引きに従うこと、緩和策がなければ製品の使用をやめること、を書いている。この3つを、会社のECサイトに当てはめて並べる。（筆者の整理）

2番目の緩和策は、筆者が読んだAdobeの告知の範囲では、具体的な内容が見当たらなかった。あるとすれば、提供元の案内に書かれているはずである。出どころが分からない緩和策は使わないのが原則である。3番目は重い判断なので、更新が無理だと分かった時点で、早めに社内で話す。

更新の知らせを待つ側の工夫

提供元の告知を、週に1回開く日を決めると、ニュースが先に届く状態から抜けられる。告知の日付と、自社の更新の日付を、台帳に並べて書く。日付の差が、そのまま「放置した日数」になる。差が30日を超えたら、理由を書く、という決まりを置くだけで、105日のような間隔が起きにくくなる（筆者の案）。

07 当サイトで確かめたこと — ECの基盤は動かしていない

2026年10月30日に、当サイトのサーバーで、Magentoのパッケージが入っているかを数えた。結果は0件だった。当サイトを外から見て、Magentoの標準の住所の1つを開くと、404（見つからない）が返った。この2つの確認が示すのは、当サイトを動かすサーバーの上では、Magentoを動かしていないことまでである。当サイトは別のCMSで動いている。

この記事で書いた「間隔を数えて、自社の決まりにする」考え方は、当サイトが自分のPHPで確かめた記録とつながる。PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法に書いた。

08 このテーマは、ここまで — 悪用確認リストを追った記事の流れ

これまでの記事

当サイトでは、2026年10月に入って、悪用確認リストに載った製品を何度か取り上げた。時系列で並べる。

• PHPの重大な脆弱性が出た週は、PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録で書いた。
• 修正が入ったかを値で確かめる方法は、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録に書いた。
• 期限の欄の読み替えは、CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）に書いた。
• WordPressの更新の期限の決め方は、WordPress 7.1.4は10月28日に出て、公式は直ちに更新するよう勧めた ── 担当サイトの版を一覧にして更新の期限を決める13項目（2026年10月時点）に書いた。
• サイトの前に置く部品の台帳は、SiteGuard Server Editionの脆弱性は、開発元が悪用を確認している。更新の前に診断情報を保存する ── サイトの前に置いた部品の台帳を作って確認する13項目（2026年10月時点）に書いた。

今回の記事の位置

これまでの記事は、PHPやWordPressのように、修正が出た日にすぐ確かめる話が中心だった。今回は、修正が出てから悪用の確認までに、3か月半あいた例を扱った。担当サイトの一覧の作り方は、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）にある。この一覧に、「基盤の名前」「パッチ名」「修正を当てた日」の3列を足すと、今回の確認が1分で終わる。 🔧 WEBサイト総合分析・レポートツール — 公開ページの状態をまとめて確認するは、公開ページの状態を見る入口になる。ECの基盤の版そのものは、このツールでは分からない。