トップ/記事一覧/広告配信ソフト『Revive Adserver』に乗っ取りの脆弱性 CVE-2026-50741、6.0.8へ更新を
revive-adserver-cve-cover-ja

広告配信ソフト『Revive Adserver』に乗っ取りの脆弱性 CVE-2026-50741、6.0.8へ更新を

自前のサーバーで広告を配信するオープンソースソフト『Revive Adserver』に、サーバーを乗っ取られる脆弱性CVE-2026-50741(CVSS 8.8)が見つかりました。権限の低いログインアカウントから任意のプログラムを実行でき、6月に直したCVE-2026-34916の修正を回避する再発です。typeパラメータとox.setChannelTargeting XML-RPCの2経路で悪用可能。6.0.7以前が対象で、修正版6.0.8への更新が必要です。

ニュース2026年6月26日公開 本日更新
目次
この記事のポイント

自前のサーバーで広告を配信するオープンソースソフト『Revive Adserver』に、サーバーを乗っ取られる脆弱性CVE-2026-50741(CVSS 8.8)が見つかりました。権限の低いログインアカウントから任意のプログラムを実行でき、6月に直したCVE-2026-34916の修正を回避する再発です。typeパラメータとox.setChannelTargeting XML-RPCの2経路で悪用可能。6.0.7以前が対象で、修正版6.0.8への更新が必要です。

自分のサーバーで広告配信を行うためのオープンソースソフト「Revive Adserver(リバイブ・アドサーバー)」に、サーバー上で任意のプログラムを実行されてしまう脆弱性(CVE-2026-50741)が見つかり、修正版が公開されました。危険度はCVSSで8.8(最高10.0)。2026年6月25日にNVDが登録し、同日に修正版の6.0.8がリリースされています。

やっかいなのは、これが「以前ふさいだはずの穴の、ふさぎ方が不十分だった」という再発である点です。同じ箇所のコード実行は今年6月3日に別の番号(CVE-2026-34916)として一度修正されました。ところがその修正を回避する新たな抜け道が複数の研究者から報告され、改めてCVE-2026-50741として切り出されたのが今回です。開発元のアドバイザリ(REVIVE-SA-2026-003)は、6.0.7以前のすべてのバージョンが対象だとしています。

攻撃には管理画面にログインできる権限が要りますが、必要なのは権限の低い一般アカウントです。広告主や代理店にアカウントを配っている運用では、その1つが乗っ取られたり悪用されたりするだけで、広告サーバーそのものが乗っ取られかねません。そして広告サーバーが乗っ取られると、被害は運用者だけにとどまらず、その広告を表示しているすべてのサイトの訪問者に及ぶおそれがあります。Revive Adserverを自前で動かしているなら、最優先で6.0.8へ更新してください。

Revive Adserverとは何で、誰が対象なのか

Revive Adserverは、Webサイトに出す広告(バナーや動画など)を自分で管理・配信するためのオープンソースのソフトウェアです。どの広告を、どのページに、いつ、誰に向けて出すかを細かく設定し、表示回数やクリック数を集計できます。かつて広く使われた「OpenX」「phpAdsNew」の流れをくむ定番で、PHPで書かれており、外部の広告配信事業者に頼らず自社で広告を回したいメディアや企業が、自前のサーバーに設置して使っています。

今回の脆弱性が効いてくるのは、この「自分のサーバーに設置して運用している(セルフホスト)」ケースです。広告サーバーは性質上、複数のサイトにまたがって広告タグを配り、多くの訪問者のブラウザにコンテンツを送り込む“配信のハブ”になります。だからこそ、ここを乗っ取られると影響範囲が広い。攻撃者が広告枠に不正なスクリプトを仕込めば、配信先のサイトを直接いじらなくても、そのサイトを見にきた人へまとめて悪意あるコードを届けられます。これが「不正広告(マルバタイジング)」と呼ばれる、広告の仕組みを悪用した攻撃の入口です。

逆に言えば、広告配信を外部のサービス(GoogleアドマネージャーやSSPなど)にすべて任せていて、Revive Adserverを自分で立てていないなら、この脆弱性の直接の対象ではありません。まずは「うちはRevive Adserverを自社サーバーで動かしているか」を確認するのが出発点です。

何が起きるのか — CVE-2026-50741の中身

問題は、Revive Adserverが「広告の配信条件(デリバリー制限)」を扱う部分にあります。「平日の昼間だけ」「日本からのアクセスにだけ」といった出し分けのルールを、Revive Adserverは内部でそのまま動くPHPプログラムに変換して保存し、広告を表示するたびに実行します。ここに細工した文字列を紛れ込ませられると、ルールのふりをしたプログラムがサーバー上で実行されてしまう、というのが一連の穴の本質です。危険度の数字は、深刻さを0〜10で表す国際的な共通スコア「CVSS」です。

項目内容
番号CVE-2026-50741
種類コードインジェクション
(CWE-94)→ 任意コード実行
危険度CVSS 8.8(高)
必要な権限権限の低い
ログインアカウント
対象6.0.7 以前のすべて
修正版6.0.8
(2026年6月25日公開)

攻撃が成功すると、Revive Adserverを動かしている権限のまま、サーバー上で任意のコマンドを実行できます(機密性・完全性・可用性のすべてに被害が及ぶと評価されています)。広告の設定データはもちろん、サーバーに置かれた別のファイルや、つながっているデータベースにも手が届きます。攻撃に高度な権限は不要で、一般の広告運用者レベルのアカウントがあれば足りる点が、危険度8.8の根拠です。

狙われると何が起きるのか

広告サーバーを狙うのは、配信網を踏み台にして多数のサイト訪問者へマルウェアをばらまきたい不正広告(マルバタイジング)の運用者、広告の表示データや会員情報を抜きたい情報窃取グループ、そして広告主アカウントを乗っ取って侵入の足場にする攻撃者です。彼らにとって広告サーバーは、1か所を押さえれば多数のサイトに同時に手を伸ばせる、効率のよい標的です。

この穴を握った相手がまず行うのは、配信条件のふりをした不正なプログラムを仕込み、広告が表示されるたびにサーバー上で自分の命令を走らせることです。そこから、広告枠に偽の警告やフィッシングを差し込んで訪問者を別サイトへ誘導したり、サーバーに保存された統計や設定を抜いたり、その広告サーバーを足場に社内の別システムへ侵入を広げたりします。広告という“信頼されている枠”を使うため、訪問者は自分が攻撃を受けていることに気づきにくいのも特徴です。

被害の責任は、最終的にその広告サーバーを運用するメディアや企業に返ってきます。自社サイトの訪問者がマルウェアに感染すれば信用は大きく傷つき、配信先の提携サイトにも被害が波及します。会員や広告主の情報が漏れれば、個人情報保護委員会への報告や本人への通知が必要になることもあります。CVSS 8.8という数字は技術的な深刻さの目盛りにすぎず、現実のコストは事故後の対応——訪問者への告知、原因調査、提携先への謝罪——にこそ表れます。ログイン権限が要るとはいえ、広告主や代理店に広く配るアカウントの1つが悪用されれば成立する以上、「内部だから安全」とは言い切れません。

技術的に見ると — なぜ一度の修正で止まらなかったのか

今回の核心は、「ユーザーが指定した配信条件を、実行可能なPHPコードに変換して保存する」という設計そのものにあります。入力をそのまま命令に変えてしまう構造のため、入力の検証が少しでも甘いと、条件のふりをしたコードが紛れ込みます。最初の番号CVE-2026-34916は、まさにこのcompiledlimitations(変換後のPHP)へ低権限ユーザーがコードを注入できるもので、6.0.7で「許可しない値をはじく」検証が追加されました。

ところが、その検証には抜け道が残っていました。開発元の説明によると、回避の経路は2つあります。1つは、本来は禁止されているものの形式としては正しい「プラグイン識別子」をtypeという項目に渡す方法。もう1つは、ox.setChannelTargetingというXML-RPC(外部からプログラム経由でRevive Adserverを操作するための仕組み)のメソッドを使う方法です。どちらも、最初の修正が想定していなかった入口から同じコード注入にたどり着きます。報告したのはRio Darmawan(riodrwn)氏、Mikhail Ilin(doomtech)氏、phucrio氏、offsetmd氏の各研究者です。

6.0.8では、プラグイン識別子とXML-RPCの入力に対する検証を強化し、危険なコード経路に到達できないよう手当てされました。「入力を実行可能なコードに変換する」機能は、便利な一方で、検証の網に1か所でも穴があると今回のように再発します。同じ構図は、外部からの値をそのまま命令として扱ってしまう他の脆弱性——たとえばデータベースのMariaDBで起きたOSコマンドインジェクションでも繰り返し現れており、入力の検証は「一度直したから安心」とはなりにくい領域です。

自分のRevive Adserverは更新が必要か(バージョン別早見表)

いま使っているバージョンは、管理画面のフッターやVERSIONファイルで確認できます。下の表で、自分のバージョンが対象かどうかを照合してください。

いま使っているバージョンCVE-2026-50741の影響やること
6.0.7 以前
(6.0.6・6.0.5…を含む)
影響あり
(最優先)
6.0.8へ更新
6.0.8 以降修正済み対応不要
OpenX / phpAdsNew
など旧製品
サポート終了
(別途リスク大)
Reviveへ移行を検討

なお、6.0.8の一つ前の6.0.7は「12件の脆弱性をまとめて直したリリース」(REVIVE-SA-2026-002)でした。その中にSQLインジェクションや別のコード実行(CVE-2026-44959)も含まれていたため、6.0.6以前を使い続けている場合は、今回の1件だけでなく多数の穴が放置されている状態です。いずれにせよ、最新の6.0.8まで一気に上げるのが安全です。

いま取るべき対応

1. 6.0.8へ更新する。 これが根本対策です。公式の配布ページから最新版を入手し、手順に沿って入れ替えます。更新前にはデータベースとファイルのバックアップを取り、管理画面に正常にログインできること、広告が問題なく配信されることを確認してください。

2. すぐに更新できないなら、入口を絞る。 当座の手当てとして、外部から叩けてしまうXML-RPC APIへのアクセスを、信頼できるIPだけに制限する(またはWeb経由で無効化する)ことが有効です。今回の回避経路の1つがox.setChannelTargetingというXML-RPCメソッドである以上、APIの露出を断つことで攻撃面を減らせます。ただしこれは時間稼ぎであり、根本対策は更新です。

3. アカウントを棚卸しする。 攻撃には低権限でもログインアカウントが必要です。使われていない広告主・代理店アカウントを削除し、推測されやすいパスワードを変更し、管理者でないユーザーに過剰な権限が付いていないかを見直します。心当たりのないアカウントが増えていないかも確認してください。

4. 侵害の痕跡を点検する。 6.0.7以前を外部に公開していたなら、配信中の広告に身に覚えのないスクリプトが混じっていないか、サーバーに見慣れないファイルやプロセスがないか、不審な外向き通信がないかを確認します。広告枠は改ざんが訪問者に直接届くため、配信内容のチェックは特に重要です。心当たりがあれば、クリーンな環境への作り直しが最も確実です。

攻撃状況と関連情報

2026年6月時点で、CVE-2026-50741が実際の攻撃に使われたという公的な報告は確認されていません。米政府CISAが公開する「実際に攻撃されている脆弱性リスト(KEV)」にも登録されていません。攻撃が確認されたCVEの最新状況は、本サイトのCISA KEVダッシュボード(日本語版)で随時更新しています。

ただし、今回は技術的な詳細(回避の2経路)が公開されており、過去の同種の穴に比べて攻撃のハードルは下がっています。修正版の公開後は穴の場所が把握されやすくなるため、攻撃が確認されていないうちに更新を済ませておくのが安全です。広告という「信頼された枠」を悪用する不正広告は、配信側が気づきにくいまま訪問者に被害が広がる典型例であり、配信のハブである広告サーバーの防御は優先度を上げて取り組む価値があります。

まとめ

CVE-2026-50741は、オープンソースの広告配信ソフトRevive Adserverで、低権限のログインアカウントからサーバー上の任意コード実行に至るCVSS 8.8の脆弱性です。今年6月に一度ふさいだCVE-2026-34916の修正に抜け道が残っていたための再発で、typeパラメータとox.setChannelTargeting XML-RPCメソッドの2つの経路から悪用できます。修正版の6.0.8が2026年6月25日に公開されています。

広告サーバーは、乗っ取られると運用者だけでなく配信先サイトの訪問者にまで被害が及ぶ“配信のハブ”です。Revive Adserverを自社で運用しているなら、6.0.8への更新を最優先で進め、XML-RPCの露出を絞り、不要なアカウントを整理しておくことをおすすめします。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go