結論：これは「マーケツールの脆弱性」ではなく「顧客DBの脆弱性」だ
Adobeは2026年6月9日（米国時間）、マーケティングオートメーション基盤 Adobe Campaign Classic のセキュリティアップデート（APSB26-66）を公開した。修正された2件は いずれもCVSSスコア10.0（満点）。対象はバージョン7.4.3 build 9394以前、修正版は 7.4.3 build 9396。適用優先度は3段階で最上位の 「優先度1」 ＝ 目安72時間以内の適用 が求められる水準と報じられている。
本質的な問いはパッチの先にある。Campaign Classicが保持しているのは、氏名・メールアドレス・購買履歴・行動履歴を統合した顧客データベースそのもの だ。そしてこの種のマーケ基盤は、マーケ部門の予算で導入され、広告代理店が運用し、情シスの資産台帳に載っていない ことが珍しくない。CVSS満点の脆弱性が出ても「自社が使っているか」を誰も即答できないのが実態だ。
押さえるべき1点：「優先度1・72時間以内」に反応できるのは、そのシステムが誰かの管理下にある場合だけだ。問われているのはパッチ適用の速さ以前に、顧客データを握る基盤が組織の管理レーダーに映っているかである。
EMERGENCY RESPONSE
この脆弱性、貴社システムは影響を受けますか？
影響範囲の一次評価を無料で実施。致命的脆弱性は24時間以内にアラートし、パッチ適用・恒久対応まで伴走します。
APSB26-66の概要：CVSS満点が同一製品に2件並ぶ異例の月例
| 項目 | CVE-2026-48303 | CVE-2026-47938 |
|---|---|---|
| 種別 | 認可処理の不備 | サーバーサイドリクエストフォージェリ（SSRF） |
| CVSS | 10.0（Critical） | 10.0（Critical） |
| 影響 | 任意コード実行（ユーザー操作不要） | 権限昇格（ユーザー操作不要） |
| 対象 | Campaign Classic 7.4.3 build 9394以前 | 同左 |
| 修正版 | 7.4.3 build 9396 | 同左 |
| 適用優先度 | 優先度1（最上位） | 同左 |
執筆時点で悪用の公表はない。ただしCVSS満点が同一アドバイザリに2件並ぶのは極めて異例で、ZDIも6月のAdobe月例（11件・計123件）の最優先に挙げている。
レガシー資産管理の観点はAdobe月例とレガシー放置の代償で、今週の全社PC更新は6月第2週エンドポイント更新チェックリストで解説済みだ。本稿は「マーケ部門が握る顧客データ基盤」という管理構造の問題に絞る。
なぜマーケ基盤は「シャドーIT化した顧客DB」になるのか
マーケティング基盤が情シスの管理外に落ちるのは、導入と運用が情報システムの標準ルートを通らないからだ。
-
導入はマーケ部門の事業予算で行われ、情シスの調達・セキュリティ審査を経ていない
-
運用は広告代理店・制作会社など外部委託先が担い、バージョンの実態を社内の誰も知らない
-
導入時の担当者が異動・退職し、契約とシステムだけが残る
-
メール配信は止められない業務のため、「動いているから触らない」が正当化され続ける
怖いのは、データの機微性と管理レベルが逆転している点だ。基幹システムなら当然のパッチ管理・アクセス制御・監視が、それより機微な顧客データを持つマーケ基盤には適用されていない。万一漏えいすれば個人情報保護法上の報告・本人通知の対象になる（漏えい等報告の実務ガイド参照）。「委託先が管理していると思っていた」は通用しない。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
今日やる確認手順：パッチ適用とSaaS棚卸しを同時に始める
-
Campaign Classicの利用有無を確認する。マーケ部門・EC担当に加え、広告代理店など委託先にも「当社名義で運用している環境はあるか」を問い合わせる
-
バージョンを特定する。7.4.3 build 9394以前なら対象。build番号の回答を書面で得る
-
修正版（build 9396）の適用日を確定させる。優先度1の趣旨に沿い、72時間以内を目安に適用日と作業責任者を決める
-
露出を確認する。管理画面・APIがインターネットから到達可能か、アクセス元制限があるかを点検する
-
マーケ部門が運用するツールの棚卸しを始める。MA・CRM・フォームなど顧客データを持つツールの運用責任者・委託先・責任分界を台帳化する
チェックの勘所：手順1で「確認先が分からない」「委託先からの回答に1週間かかる」となった時点で、それ自体が今回の最大の発見である。脆弱性対応の所要時間は、技術力ではなく管理構造で決まる。
公開前に確認したい一次情報の読み方
本件で重要なのは、Adobeのアドバイザリ本文を「脆弱性の有無」だけで読まないことだ。確認すべきは、対象バージョン、修正版、適用優先度、悪用状況、回避策の有無である。特にCampaign Classicはマーケティング部門・外部委託先・情シスの責任分界が曖昧になりやすいため、製品名だけでなく運用主体まで照合する必要がある。
公開時点で悪用が明記されていない脆弱性でも、CVSS10.0かつユーザー操作不要の条件が揃う場合は「公表後に攻撃者が解析する前提」で扱う。記事を読む側にとっての実務上の問いは、脆弱性の技術詳細よりも、72時間以内に対象有無を判定できる台帳があるかである。
よくある質問（FAQ）
Q. 実際の悪用は確認されているのか？ A. 執筆時点（2026年6月12日）で悪用の公表はない。ただしCVSS10.0かつユーザー操作不要の脆弱性は修正公開後に攻撃が始まる典型パターンであり、優先度1の趣旨どおり即時適用すべきだ。
Q. 運用は広告代理店に委託している。パッチは誰が当てるべきか？ A. 契約上の保守範囲によるが、確認の起点は自社であるべきだ。顧客データの安全管理措置義務は委託元に残る。委託先に「対象バージョンか」「適用予定日」を書面で確認し、回答が曖昧なら責任分界を契約レベルで見直すべきだ。
Q. クラウド版のAdobe Campaignを使っている場合も対象か？ A. 本アドバイザリで対象と明示されているのはCampaign Classic 7.4.3 build 9394以前である。契約形態により適用責任の所在が変わるため、Adobeまたは販売代理店に自社環境の位置づけを確認してほしい。確認しない思い込みが最も危険だ。
社内で今日確認する実務チェック
この記事のテーマを自社に当てはめるときは、次の順で確認する。第一に、対象製品・対象バージョン・対象サービスが資産台帳に載っているか。第二に、インターネットや不要な社内セグメントから到達できないか。第三に、更新・緩和・監視の担当者と期限が明確か。第四に、委託先やクラウド運用先が関係する場合、回答を口頭ではなくチケットやメールで記録しているか。第五に、対応後にバージョン・設定・ログで完了を確認したかである。
脆弱性対応で最も危険なのは、「使っているか分からない」「担当が分からない」「ベンダーに任せているはず」という状態だ。今回の記事を読んだ時点で対象有無を即答できないなら、それ自体が改善テーマである。個別のパッチ適用だけでなく、資産台帳、脆弱性通知の受信経路、緊急対応の承認権限まで点検したい。
GXOへ相談する前に整理しておくと早い情報
相談前には、対象製品名、バージョン、設置場所、外部公開の有無、管理者、保守契約、更新可能な時間帯、過去の障害履歴を分かる範囲でまとめる。すべて揃っていなくてもよいが、「分からない項目」が多いほど、最初の支援はパッチ作業ではなく棚卸しと露出確認から始めるべきである。
30日で整える脆弱性対応ロードマップ
初日から3日目までは、対象有無の確認と暫定緩和に集中する。資産台帳、EDR/MDM、クラウド管理画面、保守ベンダーへの照会を使って、対象製品がどこにあるかを洗い出す。対象が見つかった場合は、外部公開の停止、アクセス制限、管理画面のIP制限、監視強化など、更新前にできる緩和策を先に入れる。
4日目から10日目までは、更新・設定変更・影響確認を進める。業務影響が大きい製品では、検証環境で更新手順を確認し、失敗時の切り戻し手順を用意する。更新後はバージョン表示だけでなく、実際に脆弱な経路が閉じているか、ログに不審なアクセスが残っていないかを確認する。
11日目から30日目までは、再発防止に使う。通知を誰が受けるか、KEVやJPCERT/CCなどの情報をどう優先度付けするか、休日・夜間の緊急判断を誰が承認するかを決める。今回のような高リスク通知に対して、次回は「対象有無を24時間以内に答えられる」状態を目標にする。
よくある失敗パターン
第一の失敗は、CVE番号やCVSSだけを見て、対象資産の有無を確認しないことだ。スコアが高くても自社に対象がなければ対応は不要であり、逆にスコアが中程度でもKEV登録や悪用確認があれば最優先になる。優先順位は、CVSS、悪用状況、外部公開、権限条件、業務影響を組み合わせて決める。
第二の失敗は、更新完了を「ベンダーに依頼した」で止めることだ。更新後のバージョン確認、到達制限、ログ確認、再起動状態、冗長系への反映まで確認しなければ完了とは言えない。特にアプライアンスや管理基盤では、片系だけ更新されてもう片系が古いまま残ることがある。
第三の失敗は、今回だけの緊急対応で終わることだ。脆弱性情報は毎月出る。対応のたびに担当者探しから始まる組織は、次回も同じ遅れを繰り返す。今回の対応記録を使い、対象確認テンプレート、判断フロー、連絡先一覧、夜間休日の承認ルールまで更新することが重要である。
成果物として残すべきもの
公開記事を読んで終わらせず、社内には少なくとも4つの成果物を残したい。対象有無確認表、対応判断メモ、更新・緩和作業の証跡、再発防止タスクである。これらが残っていれば、監査や事故後説明でも「いつ、誰が、何を根拠に判断したか」を示せる。
また、委託先が関係する場合は、委託先回答をそのまま保存するだけでなく、自社として受け入れた判断も記録する。セキュリティ運用では、作業を委託できても説明責任は委託できない。
判断表：読むだけで終わらせないための整理
| 確認項目 | 見るべきポイント | NGサイン |
|---|---|---|
| 対象範囲 | どの部門・システム・データ・端末が関係するか | 「たぶん関係ない」で止まる |
| 責任者 | 判断者・作業者・承認者が分かれているか | ベンダー任せ、部門任せになっている |
| 期限 | いつまでに何を終えるか | 次回定例、落ち着いたら、など曖昧 |
| 証跡 | 判断根拠と作業結果を残せるか | 口頭確認だけで記録がない |
| 次の一手 | 今回の対応を仕組みに変えるか | 単発対応で終わる |
この表を埋めると、記事の内容を「読んだ情報」から「社内で動かすタスク」に変えられる。特に重要なのはNGサインである。NGサインが1つでも出る場合、問題は個別ニュースではなく、社内の判断プロセスにある。
公開情報は日々更新されるため、記事本文の数値や期限をそのまま固定値として扱うのではなく、一次情報の最新版、社内の対象有無、実施記録をセットで確認する。これにより、速報記事を一過性の話題で終わらせず、監査・稟議・改善計画に使える材料へ変換できる。
いつGXOに相談すべきか
-
マーケ部門・委託先が運用するツールに顧客データがどれだけ入っているか、全社で把握できていない
-
Campaign Classicを含む外部公開システムの露出と脆弱性を第三者の目で点検したい
-
委託先管理を含めた顧客データの安全管理体制を再構築したい
GXOは、脆弱性診断による外部公開資産・マーケ基盤の露出評価、セキュリティ診断による部門導入ツールの棚卸しと管理体制設計、インシデント対応支援を提供している。顧客DBを握る基盤が「誰の管理下にもない」状態は、それ自体がインシデントの一歩手前だ。→ 相談はこちら
関連記事
編集部注：公開後の更新方針
本記事は速報性のある公開情報をもとに、GXOの商談領域であるシステム開発、AI導入、セキュリティ、レガシー刷新、データ基盤構築の観点へ翻訳したものである。公開後に一次情報の更新、ベンダー側の追記、制度要件の変更、悪用状況の変化が確認された場合は、本文・参考資料・CTAの導線を更新する。
読者が実務で使う場合は、記事の数値や期限を固定値として扱うのではなく、必ず一次情報と自社環境を突き合わせることが重要である。特に、契約条件、対象バージョン、制度要件、提供リージョン、価格、悪用状況は短期間で変わり得る。この記事の役割は、最新情報を自社の判断項目へ変換することであり、最終判断は一次情報と社内の対象有無確認にもとづいて行う。
参考資料
-
Adobe「Security update available for Adobe Campaign Classic | APSB26-66」
-
Zero Day Initiative「The June 2026 Security Update Review」（二次情報）
-
Security NEXT「Adobe Campaign Classicに深刻な脆弱性——CVSS値は最高値」（二次情報）
本記事は2026年6月12日時点の公開情報をもとに作成。CVE詳細・適用優先度はAdobeの一次アドバイザリに基づくが、一部数値は二次情報で照合した。悪用状況・修正版情報は更新される可能性があるため、Adobeの一次情報の最新版を必ず確認すること。
マーケ部門が運用する「顧客DBの塊」、情シスの台帳に載っていますか
外部公開されたマーケティング基盤・SaaSの棚卸しと露出評価、委託先を含めた責任分界の設計、CVSS10.0級の緊急パッチに72時間で動ける体制づくりまで支援します。
※ 営業電話はしません | オンライン対応可 | 緊急時は最短当日対応