Adobe Campaign 脆弱性 CVE-2026-48449｜build 9398 適用の判断ポイント

はじめに

2026 年 7 月 29 日、Adobe はマーケティングオートメーション基盤である Adobe Campaign Classic（ACC）向けのセキュリティアップデート APSB26-114 を公開しました。修正対象には CVSS 3.1 で最大値となる 10.0 の脆弱性 CVE-2026-48449 が含まれ、Adobe による優先度評価は最上位の Priority 1 です。

ACC はメール配信やキャンペーン管理を担う基盤であり、オンプレミス構成では顧客データを保持するデータベースと直結しています。一方で、更新にはアプリケーションサーバー（nlserver）の再起動が必要になるため、配信ジョブを止めるタイミングをマーケティング部門と調整する必要があります。「深刻度は最大だが、すぐには止められない」という状況に置かれる運用担当者は少なくないと考えられます。

対処の要点は 3 点です。影響を受けるのは ACC v7: 7.4.3 build 9397 以前のオンプレミス構成、およびハイブリッド構成のオンプレミス側コンポーネントのみで、Adobe ホスト型インスタンスは対応済みのため利用者側の作業は不要とされています。恒久対処は build 9398 への更新で、再起動後に修正が既定で有効になります。2026 年 8 月 2 日時点で実環境での悪用は確認されておらず、CISA の KEV カタログにも登録されていないため、計画的なメンテナンス枠を確保して適用する判断が取りやすい状況です。

CVE-2026-48449 と CVE-2026-48448 の概要

APSB26-114 は 2 件の脆弱性を修正しています。いずれも Adobe の分類では Critical に位置づけられており、影響は任意コード実行と任意ファイル読み取りです。

参考: Security update available for Adobe Campaign Classic | APSB26-114
“This update addresses critical vulnerabilities that could result in arbitrary code execution”
（このアップデートは、任意コード実行につながる可能性のある重大な脆弱性に対処するものです）
https://helpx.adobe.com/security/products/campaign/apsb26-114.html

なお海外の速報記事の一部は CVE-2026-48448 を「high-severity」と表現していますが、Adobe 公式アドバイザリの脆弱性一覧では Critical と記載されています。社内報告や管理台帳へ転記する際は、公式アドバイザリの表記を基準にすることをおすすめします。

CVE-2026-48449: 不適切な認可（CWE-863）による任意コード実行

CWE-863 は、アクセス制御の判定そのものは行われるものの、その判定が正しくないために本来許可されるべきでない操作が通ってしまう分類です。認可チェックが完全に欠落している CWE-862（認可の欠落）とは区別されます。ACC のようにコンソール、Web アプリケーション、配信処理といった複数のコンポーネントが権限モデルを共有する製品では、この種の不備が任意コード実行へ直結する場合があります。

Adobe および NVD の記載では、影響は「現在のユーザーのコンテキストでの任意コード実行」と表現されており、悪用にユーザー操作は不要とされています。攻撃の具体的な手法や再現手順は公開されていないため、本記事でも踏み込みません。

CVE-2026-48448: SQL インジェクションによる任意ファイル読み取り

CVE-2026-48448 は CWE-89 に分類される SQL インジェクションで、影響は任意ファイルの読み取りです。CVSS ベクトルは CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N で、完全性（I）と可用性（A）への影響はなく、機密性（C）のみが High と評価されています。

ACC のデータベースには配信先アドレス、開封・クリックのトラッキングログ、セグメント条件といった個人情報が集約されます。設定ファイル内の接続情報や認証情報が読み取られた場合、そこを起点に影響が広がる可能性も想定されます。深刻度が CVE-2026-48449 より低いからといって後回しにせず、同一のアップデートでまとめて解消する方針を推奨します。

CVSS 10.0 の内訳と、NVD が未評価である点の読み方

CVE-2026-48449 のベクトルは CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H です。内訳は次のとおりです。

Base Score が 9.8 ではなく 10.0 に達している要因は S: Changed です。スコープ変更は、脆弱性が存在するコンポーネントの権限範囲を越えて別のコンポーネントへ影響が及ぶことを示します。同じ「未認証・リモート・全項目 High」でも、スコープが Unchanged なら 9.8、Changed なら 10.0 になります。この 1 項目の差が最大値到達の分かれ目である点は、優先度を説明する際の根拠として使えます。

もう 1 点、台帳運用で注意したい事実があります。NVD の CVE-2026-48449 のページは 2026 年 8 月 2 日時点で Awaiting Enrichment（エンリッチメント待ち）の状態にあり、表示されている 10.0 は CNA である Adobe が付与したスコアです。NVD 独自の評価はまだ付与されていません。CVSS スコアを脆弱性管理台帳へ転記する運用では、スコアの出所（CNA か NVD か）を併記しておくと、後日 NVD が異なる値を付与した際の整合ずれを避けられます。

CVSS ベクトルの読み方や、CISA KEV を優先度判断に組み込む考え方については、関連記事『Oracle 脆弱性対応の進め方』でベンダー横断の判断プロセスとして整理しています。あわせて参照いただくと、本記事の優先度判断の背景が把握しやすくなります。

影響を受ける構成と対象ビルド

APSB26-114 の対象は ACC v7: 7.4.3 build 9397 以前で、プラットフォームは Windows と Linux です。ただし、対象となるのはすべての ACC 環境ではありません。デプロイ形態によって、利用者側の作業要否が明確に分かれます。

オンプレミスとハイブリッドのみが対象となる理由

ACC v7 のデプロイ形態は 3 種類あります。

Adobe のアドバイザリには、本セキュリティ情報が完全なオンプレミス構成、およびハイブリッド構成のオンプレミス側コンポーネントにのみ適用されると明記されています。Adobe ホスト型インスタンスは対処済みで、利用者側の作業は不要とされています。

ハイブリッド構成では、どのコンポーネントが自社管理でどれが Adobe 管理かが環境ごとに異なります。ミッドソーシングサーバーやトラッキングサーバーを自社で保有しているケースでは、そこが対象に含まれる可能性があります。構成図と管理主体の一覧を照合したうえで対象範囲を確定することをおすすめします。

稼働ビルドの確認方法

自環境のビルド番号は、次のいずれかの方法で確認できます。

クライアントコンソール

メニューの Help > About… を開きます。コンソール側とサーバー側の双方について、バージョンとビルド番号が表示されます。

サーバー側のコマンド

アプリケーションサーバー上で nlserver pdump を実行すると、先頭行にアプリケーションサーバーのバージョンとビルド番号、ビルド日付が出力されます。

nlserver pdump の出力例は次の形式です。

HH:MM:SS > Application Server for Adobe Campaign Classic (7.X YY.R build XXX@SHA1) of DD/MM/YYYY
No tasks

このコマンドは稼働中タスクの一覧も返すため、後述の更新作業でも停止確認に使います。ビルド確認と停止確認の双方に使える点を覚えておくと便利です。

参考: Campaign Classic Build Upgrade FAQ
“Select the Help> About… menu in the Adobe Campaign Client console.”
（Adobe Campaign クライアントコンソールで Help > About… メニューを選択します）
https://helpx.adobe.com/ie/campaign/kb/build-upgrade-faq.html

29 日前の CVE-2026-48286 との関係

今回のアドバイザリを読むうえで見落としやすいのが、build 9397 そのものが 1 か月前に公開されたセキュリティビルドであるという点です。ACC v7 7.4.3 の直近の系譜を整理すると次のようになります。

CVE-2026-48286 も CVE-2026-48449 と同じ CWE-863（不適切な認可）に分類される CVSS 10.0 の任意コード実行で、公開日は 6 月 30 日でした。同一分類の最大深刻度の脆弱性が 29 日間隔で 2 回公開されたことになります。6 月末に緊急メンテナンスを実施して build 9397 へ更新した環境も、今回あらためて対象に含まれます。

この間隔は偶然ではなく、後述する Adobe の脆弱性公開サイクルの変更と関係しています。年 1 回のアップグレード計画を前提としたメンテナンス枠の取り方では追随が難しくなっている、という前提で計画を見直す価値があります。

参考: Latest release（Campaign Classic v7 リリースノート）
“This build is now deprecated for on-premise and hybrid deployments”
（このビルドは、オンプレミスおよびハイブリッド構成では非推奨となりました）
https://experienceleague.adobe.com/en/docs/campaign-classic/using/release-notes/latest-release

build 9398 適用の事前準備

更新作業そのものに入る前に、確認しておきたい前提が 3 点あります。特に 1 点目は、公式の標準手順どおりに進めると行き詰まる可能性がある部分です。

Limited Availability ステータスの扱い方

ACC v7 のビルドには 3 つのステータスが定義されています。

build 9398 は 2026 年 8 月 2 日時点で Limited Availability です。一方、オンプレミス利用者向けのアップグレード手順には「最新の安定版（GA）をダウンロードしてすべての環境をアップグレードする」と記載されています。つまり、公式の標準的な導線をたどると、今回適用すべき build 9398 には到達しない可能性があります。

実務上の選択肢は次のように整理できます。

オンプレミス構成

ソフトウェア配布ポータルでの提供状況を確認し、入手できない場合は Adobe のカスタマーケアまたは担当者経由で build 9398 の提供を依頼する

ハイブリッド構成

Adobe 管理側のコンポーネントについては、公式手順どおりカスタマーケアへ連絡して環境の更新を依頼する

GA 昇格を待つ判断

現時点で悪用は確認されておらず KEV にも登録されていないため、外部公開していない環境では GA 昇格を待つ判断もあり得る。ただし、その間は対象ビルドのまま稼働する点を許容できるかどうかで判断する

判断の分かれ目は、ACC のコンポーネントがインターネットから到達可能かどうかです。Web フォームやトラッキングサーバーを外部公開している構成では、待機ではなくオンデマンド提供の依頼を先行させる進め方を推奨します。

参考: Release updates（Campaign Classic v7 ドキュメント）
“Limited Availability: On-demand deployment only.”
（Limited Availability: オンデマンドでの提供のみ）
https://experienceleague.adobe.com/en/docs/campaign-classic/using/release-notes/rn-overview

データベースバックアップとクライアントコンソールの整合

公式のアップグレード手順では、更新前に各インスタンスでデータベースのバックアップを取得することが強く推奨されています。ACC のデータベースには配信履歴やトラッキングログが蓄積されるため、取得所要時間はデータ量に依存します。メンテナンス枠を見積もる際は、バックアップ時間を別枠で確保しておくと安全です。

もう 1 点、見落としやすいのがクライアントコンソールです。クライアントコンソールはサーバーインスタンスと同一ビルドである必要があります。サーバーだけを更新すると、マーケティング担当者の手元のコンソールが接続できなくなる可能性があります。

コンソールの更新は、アプリケーションサーバー（nlserverweb）上の [インストールパス]\datakit\nl\en\jsp に配布用のセットアップファイルを配置することで、次回接続時に利用者へ更新が案内される仕組みです。サーバー側の作業完了時刻と、利用部門へのコンソール更新の案内タイミングをセットで計画しておくことを推奨します。ここを分離すると、深夜のメンテナンス完了後に翌朝の問い合わせが集中する事態になりかねません。

現行ビルド別に見た作業量の差

build 9398 への更新は、現在稼働しているビルドによって作業規模が大きく変わります。同じ「最新ビルドへの更新」でも、必要な検証項目と所要時間が異なる点に注意が必要です。

特に注意したいのが 9396 からの更新です。build 9397 では webForm.jsp が既定でクライアントから渡される ctx パラメータを無視する変更が入りました。この挙動は disableCtxInWebForm パラメータで制御され、既定値は true です。Web フォームのリクエストで ctx パラメータを渡している実装がある場合、更新後にフォームが期待どおり動作しなくなる可能性があります。

公式リリースノートでは、暫定的に従来の挙動へ戻す設定として、config-<インスタンス名>.xml の <web> 要素配下に次の記述を追加する方法が案内されています。あわせて、この使い方を段階的に廃止していくことも推奨されています。

<web>
  ...
  <jsp disableCtxInWebForm="false" />
  ...
</web>

build 9394 以前から更新する場合は、Debian 13 と PostgreSQL 17 という OS・データベース側の前提変更が加わります。この場合はセキュリティパッチ適用というより基盤更改に近い規模になるため、対応可能な互換バージョンを互換性マトリクスで確認したうえで、別途プロジェクトとして計画することをおすすめします。

なお、トランザクションメッセージ（Message Center）を有効にしている環境では、実行インスタンス側の更新と postupgrade スクリプトの実行という追加手順が必要です。該当する場合は作業項目に加えてください。

build 9398 への更新と配信停止の設計

ACC の更新作業は、単純なパッケージ入れ替えでは完結しません。配信処理を含む複数のモジュールを止め、リソース同期を行い、競合が出た場合は解決したうえで再起動する、という流れになります。ここでは停止範囲の設計から順に整理します。

nlserver 再起動と配信の停止範囲を先に決める

build 9398 のリリースノートには、ビルドを読み込んで適用を完了させるためにアプリケーションサーバー（nlserver）の再起動が必要であり、再起動後に修正が既定で有効になると記載されています。したがって、再起動を伴わない適用は成立しません。

nlserver 配下では複数のモジュールが動作しており、停止によって業務影響が出る範囲を事前に把握しておく必要があります。

このうち実務で調整が必要になるのは mta と webmdl です。すでに配信済みのメールに含まれるリンクはリダイレクトサーバーを経由するため、作業中に受信者がリンクをクリックすると到達できない可能性があります。深夜帯であっても、直前に大量配信を行った直後の時間帯は避ける、といった配慮が必要になります。

現在の稼働モジュールと接続状況は、次のコマンドで確認できます。

nlserver pdump -who

-who を付けると、稼働中のモジュール一覧に加えて、進行中の接続（利用者とプロセス）が表示されます。マーケティング担当者がコンソールで作業中でないかを確認してから停止に入る運用が安全です。

計画時の観点は次のとおりです。

• 実行中および直近で予約されている配信ジョブの有無を確認し、作業枠と重ならないようスケジュールを調整する
• ワークフローの実行スケジュールを確認し、作業枠内に起動するものがあれば一時停止する
• データベースバックアップの所要時間を別枠で確保する
• 作業枠と、利用部門への停止案内の時間帯を一致させる

ACC は業務部門が日中に使う配信基盤であるため、技術的な作業時間よりも部門調整のリードタイムのほうが長くなりがちです。build 9398 の入手依頼と並行して、停止枠の調整を先に始めておくことを推奨します。

Windows 環境での更新手順

Windows 環境では、サービス停止、アプリケーションの更新、リソース同期、サービス再開の 4 段階で進めます。

iisreset /stop
net stop nlserver6

nlserver pdump

nlserver config -postupgrade -allinstances

iisreset /start
net start nlserver6

Linux 環境での更新手順

Linux 環境では、パッケージの取得、更新の実行、Web サーバーの再起動という流れになります。パッケージ名は nlserver6-v7-XXXX の形式で、ソフトウェア配布ポータルから取得します。

RPM 系ディストリビューション（Red Hat、SUSE）の場合

yum update ./nlserver6-v7-XXXX.rpm

実行前に、出力が Upgrading: になっていることを確認します。Removing: と表示された場合はコマンドを中止します。依存関係の不足など、その前に出力されているエラーが原因である可能性が高いため、依存パッケージを解決してから再実行する流れになります。

なお v7.4.1 以降、RPM Linux パッケージに XML ライブラリが同梱されなくなっているため、別途インストールが必要です。epel-release が未導入の場合は先に導入します。

DEB 系ディストリビューション（Debian）の場合

apt install ./nlserver6-v7-XXXX-amd64_debX.deb

Linux では、リソースの同期は自動的に実行されます。ただしエラーが発生していないかは自分で確認する必要があります。

Web サーバーの再起動

新しいライブラリを反映するため、Apache の停止と起動が必要です。

/etc/init.d/apache stop
/etc/init.d/apache start

環境によってスクリプト名が httpd である場合があります。

参考: Upgrading to a new build（on-premise）
“You must shut down Apache for the new library to become applicable.”
（新しいライブラリを適用するには、Apache を停止する必要があります）
https://experienceleague.adobe.com/en/docs/campaign-classic/using/monitoring-campaign-classic/updating-adobe-campaign/upgrading

ここで注意したいのは、公式のアップグレード手順ページの Linux 側には nlserver そのものを停止・再起動する明示的な記述がない点です。一方、build 9398 のリリースノートでは nlserver の再起動が必要と案内されています。パッケージ更新前後で nlserver を停止・再開する手順を作業計画に明示的に組み込んでおくことをおすすめします。

サービスの停止・起動には、20.1 以降は次のコマンドが推奨されています。

systemctl stop nlserver
systemctl start nlserver

補足として、Experience League のコミュニティには、Web サーバーを停止しないまま postupgrade を実行した結果、共有メモリのバージョン不整合を示すエラー（SRV-810031）が発生し、nlserver コマンドが通らなくなった事例が投稿されています。公式ドキュメントに記載された事象ではありませんが、停止順序を守る根拠として把握しておく価値があります。

リソース同期（postupgrade）での競合解決

postupgrade は、同期の過程でエラーと警告を検出します。コマンドラインの出力では、エラーは三重の山括弧（>>>）で示され、同期は自動的に停止します。警告は二重の山括弧（>>）で示され、同期完了後に解決する対象になります。

同期結果は次のログファイルにも出力されます。

<インストールディレクトリ>/var/<インスタンス>/postupgrade/

リソースの競合が発生した場合は、クライアントコンソールのツリーで Administration > Configuration > Package management > Edit conflicts を開いて解決します。解決方法は 3 種類です。

標準スキーマやレポートをカスタマイズしている環境では、この競合解決に時間がかかる場合があります。作業枠を見積もる際は、パッケージ更新の所要時間だけでなく、競合解決の可能性も織り込んでおくと安全です。事前に検証環境で同じ更新を実施し、発生する競合の件数と内容を把握しておく進め方を推奨します。

更新後の確認とクライアントコンソールの案内

更新完了後は、次の順で確認します。

最後にクライアントコンソールの更新案内です。アプリケーションサーバー上の配布用ディレクトリにクライアントコンソールのセットアップファイルを配置すると、次回接続時に利用者へ更新が案内されます。

Linux の場合の配置例は次のとおりです。

cp setup-client-6.XXXX.exe /usr/local/neolane/nl6/datakit/nl/eng/jsp

Windows の場合は [アプリケーションのパス]/datakit/nl/eng/jsp に配置します。ファイルの読み取り権限（Windows では IIS_XPG ユーザー、Linux では Apache ユーザー）が付与されているかを確認してください。権限不足のまま配置すると、利用者側に更新案内が表示されません。

なお、公式ドキュメント内ではこの配布ファイルの名称とパスに表記のゆれがあります（setup-client-6.XXXX.exe と Setup-client-7.xxxx.exe、nl/eng/jsp と nl/en/jsp など）。実際に取得したパッケージのファイル名と、稼働環境のディレクトリ構成を確認したうえで配置することをおすすめします。

Adobe の脆弱性公開サイクルの変更への備え

今回の CVE-2026-48449 は、単発の脆弱性としてだけでなく、Adobe の脆弱性開示のあり方が変わりつつある局面で公開された案件という側面を持ちます。ここは製品を問わず、脆弱性管理を担当する立場に影響する部分です。

2026 年 7 月 14 日からの第 2・第 4 火曜サイクル

Adobe は 2026 年 7 月 14 日から、セキュリティ情報とアドバイザリの公開を月次から隔週へ変更しました。公開日は毎月の第 2 火曜と第 4 火曜で、対象は正式に採番された CVE を含み利用者側の対応が必要となるすべてのアドバイザリです。

参考: Protecting customers faster（Adobe Security Blog）
“Effective July 14, 2026, Adobe is moving from monthly to twice-monthly publication”
（2026 年 7 月 14 日より、Adobe はセキュリティ情報の公開を月次から隔週へ移行します）
https://blog.adobe.com/security/protecting-customers-faster-how-adobe-is-responding-to-ai-accelerated-vulnerability-discovery

Adobe が挙げている理由は、AI を活用した脆弱性発見の加速です。同社 CSO の Aanchal Gupta 氏は、公開から実際の悪用までの猶予が日単位から時間単位へ縮まっているとし、月 1 回の公開枠では追随できなくなったと説明しています。

運用面では次の変化が生じます。

ACC のように業務部門との調整が必要な製品では、この頻度変更の影響が特に大きくなります。Adobe は無償のセキュリティ通知サービスを提供しているため、公開のたびに手動で確認するのではなく、通知を受け取ってから対象製品の該当有無を判定する運用へ切り替えることをおすすめします。

なお、本記事で扱った APSB26-114 の公開日は 2026 年 7 月 29 日で、第 4 火曜（7 月 28 日）の翌日にあたります。隔週サイクルへの移行後、実際に公開間隔が短くなっていることを示す一例といえます。

2026 年 8 月 11 日以降の CVE 集約と脆弱性管理への影響

APSB26-114 には、もう 1 つ見落としやすい注記が添えられています。2026 年 8 月 11 日以降、Adobe は自社で発見した脆弱性について、深刻度と CWE カテゴリが同一で、かつリリースが体系的な修正を含む場合、単一の CVE 識別子を割り当てる場合があるという内容です。

この変更が脆弱性管理に与える影響は次のとおりです。

• CVE 件数が実際の修正件数と一致しなくなる。1 つの CVE の背後に複数の修正が含まれる可能性がある
• CVE 単位の管理台帳では修正内容を追跡しきれなくなる。CVE ではなくビルド番号を管理の主軸に置く必要が生じる
• 前年比の CVE 件数を指標にしている場合、統計の連続性が失われる。件数の減少がリスク低下を意味しなくなる

対応の方向性としては、「どの CVE に対処したか」ではなく「どのビルドで稼働しているか」を資産管理の基準に据える形への移行が現実的です。ACC でいえば、build 9398 で稼働していることを記録し、リリースノートで公開される新しいビルドとの差分を定期的に確認する運用になります。

なお、この方針については 2026 年 8 月 2 日時点で APSB26-114 の注記以外に独立した方針文書を確認できていません。適用範囲や運用の詳細は今後の公開情報で明確になる可能性があるため、8 月 11 日以降のアドバイザリの記載を確認することをおすすめします。

ベンダー横断で進む同じ方向の変化

同じ動きは Adobe に限りません。Cisco も 2026 年 7 月から、リスクベースの脆弱性開示モデルへ移行しています。共通する CWE を持つ脆弱性を「アンブレラ CVE」として集約し、そのカテゴリ内で最も高い深刻度に基づいて CVSS スコアを付与する方式です。公開は毎月の第 1・第 3 水曜で、7 日前に対象技術の事前通知が出されます。

実例として、2026 年 7 月 15 日に公開された Cisco RoomOS のハードニングリリースでは、内部レビューで発見された複数の脆弱性が 6 つの CWE グループにまとめられ、それぞれに 1 つの CVE が割り当てられています。

両社とも、変更の理由として AI による脆弱性発見の加速を挙げています。Cisco は、CVE ごとにリスクを評価して個別に緩和策を当てる手法はもはや適切ではなく、ハードニング済みの最新リリースで稼働することが最も有効な保護になる、という考え方を示しています。

脆弱性管理の実務は、個別 CVE への対処から「サポート対象の最新ビルドを維持する体制」へと重心が移りつつあります。公開サイクルが速くなるほど、外部への露出面をあらかじめ小さくしておく設計の価値も相対的に高まります。アタックサーフェス削減の考え方については、関連記事『FortiGate のハードニング設定』でネットワーク機器を題材に整理しています。

まとめ

Adobe Campaign Classic の CVE-2026-48449 は CVSS 10.0 の任意コード実行で、同時に修正された CVE-2026-48448 とあわせて build 9398 で解消されます。対象はオンプレミス構成とハイブリッド構成のオンプレミス側コンポーネントに限られ、Adobe ホスト型インスタンスは対処済みです。悪用は確認されていないものの、build 9397 に更新したばかりの環境も対象に含まれる点が今回の特徴です。

• CVE-2026-48449 は CWE-863 の任意コード実行で CVSS 10.0
• スコープ変更（S:C）が最大値到達の要因
• 対象は build 9397 以前のオンプレミス構成とハイブリッド構成
• 修正版 build 9398 は Limited Availability での提供
• 適用には nlserver の再起動と配信停止の調整が必要
• 現行ビルドが 9394 以前の場合は基盤更改に近い規模
• 2026 年 8 月 11 日以降は CVE 集約により台帳運用の見直しが必要

以上、最後までお読みいただきありがとうございました。