Adobe CommerceとMagentoの悪用をCISAが確認｜パッチの適用漏れを点検

CISAは2026年10月27日、Adobe CommerceとMagentoに影響するCVE-2026-48356を既知の悪用脆弱性カタログ（KEV）へ追加しました。7月に公開済みの修正について、実際の悪用を踏まえて対応の優先度を上げる続報です。未対応のECサイトは、製品の版だけでなくIsolated patchの適用状態を確認してください。

対象はAdobe Commerce／Magento Open Sourceの運用担当者と、更新を受託する開発チームです。本稿は10月28日に公式資料を確認したニュース解説です。更新は侵入口を修正する作業であり、すでに置かれた不正ファイルや不明な管理者アカウントの除去まで自動で完了するものではありません。侵害の兆候があれば、更新と並行して証拠保全と調査を進めます。

何が新しく確定したのか

今回の新事実は、CISAが当該CVEを悪用確認済みとして登録したことです。公式JSONのcatalogVersionは2026.10.27、dateReleasedは2026年10月27日19:00:02 UTC、当該レコードのdateAddedは10月27日です。ランサムウェア利用状況はUnknownであり、特定の攻撃集団、被害件数、侵害された店舗名を示す登録ではありません。

AdobeのAPSB26-73は7月14日公表、取得したページの最終更新表示は8月11日でした。同ページには悪用を認識していないという説明が残っていますが、後日のKEV追加と確認時点が異なります。本稿では現在の優先度をCISAの10月27日登録に基づいて判断し、古い説明を現在も悪用未確認という意味では使いません。

KEVの米国連邦機関向け対応期限は11月10日です。一般のEC運営者にとって、そこまで放置してよい期限ではありません。CISAはベンダーの指示に従う対策を求めています。公開中の未修正サイトは、通常の機能改善より先に修正計画と適用確認を進めるべきです。

出典：CISA：公式KEVカタログJSON、Adobe：APSB26-73。

認証不要と利用者操作不要を混同しない

Adobeは当該CVEを、危険な種類のファイルを制限なくアップロードできる問題（CWE-434）に分類しています。影響は権限昇格、深刻度はCritical、CVSS 3.1は9.6です。認証は不要とされていますが、ベクトルはUI:Rで利用者の操作を要する評価です。「認証不要だから操作なしで必ずサーバーを乗っ取れる」とは説明できません。

CISAの登録は、任意コード実行や利用者のアカウント・セッションへの影響につながり得ると説明しています。一方、今回確認した資料だけで攻撃に使う画面、具体的なアップロード先、拡張子、利用者に要求される操作を確定できません。推測の攻撃経路を追加せず、公開された条件と修正対象から対応します。

版番号と月次パッチをセットで調べる

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.9、2.4.8-p5以前、2.4.7-p10以前、2.4.6-p15以前です。これは勧告に含まれる複数CVEの対象表なので、各問題の条件を一括して同じものとは扱いません。

修正欄には各系列の2026-jul更新が掲載されています。重要なのは、7月分が通常のComposerパッケージだけで配布される更新ではない点です。Adobeの手順はIsolated patchファイルを提供し、インストールしたコンポーネントと版に対応するものを選ぶよう求めています。composer.jsonに新しい番号を書いたことだけでは、実ファイルへの反映確認になりません。

本サイトの提案として、調査表にはサイト名、環境、CE／EEの区別、B2Bなどの追加構成、composer.lock、配備成果物、月次パッチ適用記録を並べます。本番だけでなく待機系、ジョブ用ノード、古い公開検証サイトも対象です。管理画面の表示を見た一人の記憶ではなく、実際に配備されたコードとの対応を残します。

Isolated patchは対象版と順番を合わせる

Adobeの7月更新手順は、系列に対応する指定の-p版へ先に更新してからIsolated patchを適用するよう説明しています。たとえば2.4.6-p14以前に、2.4.6-p15用ファイルをそのまま当てる手順ではありません。現在の系列と必要な前提版を確認し、依存関係や拡張機能への影響を検証環境で確かめます。

ZIPにはCE、EE、B2B、PageBuilderなど複数のファイルが含まれる場合があります。公式例では2.4.6-p15のCEは対応するCEファイルを、EEはCEの後にEEを適用します。B2Bがある場合はその後に実際のB2B版に対応するファイルを選びます。全部のファイルを無差別に適用する方法ではありません。

月次セキュリティパッチは非累積で、順番に適用する必要があるとAdobeは説明しています。10月のファイルを置いたから7月分もすべて含まれる、と想定しないでください。過去分の適用漏れ、途中の失敗、構成に合わないファイルの混入を確認し、不明な点は公式手順とサポートへ戻します。

出典：Adobe：APSB26-73のIsolated patch適用手順。

Cloudでは二重適用を避ける

Adobe Commerce on Cloud infrastructureでは、Cloud Patchesによる修正取り込みも確認します。公式リリースノートはmagento/magento-cloud-patches 1.1.15でAPSB26-73の修正を含めたと記載しています。パッケージの更新と、本番への配備時に修正が適用されたことは別の確認事項です。

Adobeは、Cloud Patchesで修正済みの環境へIsolated patchを重ねるとインストール失敗が起こり得ると注意しています。失敗したときに強制適用する前に、既存の修正、対象モジュール、ビルドログを照合します。新しいCloud Patchesには別の修正もあるため、1.1.15へ固定する推奨ではなく、現在の公式更新方針に従ってください。

出典：Adobe：Cloud Patchesのリリースノート。

Commerce Version Toolで適用結果を残す

Commerce Version Tool（CVT）は月次パッチの検出を補助する公式ツールです。CEパッチ適用後にvendor/bin/patch-statusとして導入され、PHP 8.1以降とシステムのpatchコマンドを必要とします。修正を適用・取り消すツールではなく、composer.lockとパッチ差分のdry-runに基づいて状態を報告します。

対象プロジェクトのルートで、次の公式コマンドを使います。別の環境を調べるなら--rootで対象を明示します。これは読者の環境で実行する確認例であり、本サイトがCommerce実機で実測した結果ではありません。

php vendor/bin/patch-status
php vendor/bin/patch-status --root=/path/to/commerce --format=json

出力のapplied_patchesだけでなく、missing_patches、unknown_patches、vulnerability_status、registry_source、warningsを確認します。PROTECTEDは対応パッチを検出した状態で、サイト全体が侵害されていない証明ではありません。UNKNOWNは安全という意味ではなく、資料や差分から判定できなかった状態です。

古いキャッシュを使った場合は警告と取得元を残します。新しいリモート情報が必要なときは--no-cacheを使えますが、通信不能ならエラーになります。出力JSONは構成情報を含むため、公開チケットへ丸ごと貼らず、保守担当者に必要な範囲で共有してください。

出典：Adobe：CVTの仕組み、パッチ状態レポートの生成と読み方。

空の結果やエラーを修正済みにしない

base_versionがunknownなら、実行場所、--root、composer.lockの存在と内容を確認します。ベース版を検出できなければパッチ検出は行われません。有効な版なのに適用・不足・不明の一覧がすべて空なら、レジストリーがその版をカバーしていない可能性があります。終了コードだけで完了扱いにしないことが重要です。

認証が必要な差分の取得失敗は、Composer資格情報と権利を確認します。ハッシュ不一致やhunk失敗を、チェックを無効化して通す運用にはしません。警告、対象版、コンポーネント、失敗した差分を保存し、公式サポートが再現できる材料にします。

出典：Adobe：CVTのトラブルシューティング。

更新作業と侵害調査を並行する

本サイトの運用提案は、更新前のコードとログを保全し、検証環境で修正と注文処理を確認してから切り替える流れです。コード、メディア、DBを整合した時点で復元できるようにします。Commerce内蔵バックアップ機能は非推奨とされているため、コマンドがあることだけを理由に新たな復旧基盤として採用しません。

Adobeの通常アップグレード手順は、保守モードと非同期処理への配慮を求めています。Cloudとオンプレミス、Git由来の導入は手順が異なります。キューやcronを動かしたまま更新してデータを壊さないよう、導入形態に合う公式手順を使い、決済、在庫、メール、管理操作の正常系も検証します。

侵害を疑う場合、AdobeはSecurity Scanによる点検、メディア領域に残る実行可能コードの確認、不明な管理者の削除、管理者パスワードの変更を案内しています。削除前には調査に必要なコピーを安全な場所へ保存します。アップロード時刻、管理者変更、配備履歴を突き合わせますが、見慣れないファイル一つで当該CVEの悪用と断定しません。

完了条件は、修正対象と配備物が対応し、必要な月次パッチの状態を説明でき、業務の確認を終えたことです。侵害の兆候があれば、公開再開の判断は別に残します。今回のKEV追加を、古いパッチの案内を読み返すだけで終わらせず、実コードの修正と侵害の有無という二つの確認へつなげてください。

出典：Adobe：バックアップ機能の注意、通常アップグレードの手順、侵害を疑う場合の対応計画。