Tenable Security Centerに緊急脆弱性、非管理者でRCE

【更新 2026-08-19】本記事を見直し、修正しました。主な修正点：CVE-2026-19681／CVE-2026-19682 の「詳細は未公開」という記述を、NVDで公開済みの概要（19681＝ファイルアップロード処理、19682＝未認証の攻撃者による実行と記載）に更新。あわせて、19682 のCVSSスコアがアドバイザリ（9.0）とNVD（9.9）で食い違う点に要確認の注記を追加し、スタンドアロンパッチの表記を SC202607.1 に修正しました。

脆弱性管理の司令塔である「Tenable Security Center」自体に、緊急度の高い脆弱性が見つかりました。Tenableは2026年8月13日、アドバイザリ TNS-2026-22 を公開し、Security Center 6.8.0 以前を対象に計20件の脆弱性を修正した 6.9.0 をリリースしました。うち最も深刻なリモートコード実行（CVE-2026-19626、CVSS 9.9）は、管理者権限を持たない一般ユーザーのアカウントがあれば成立します。

スキャン用の認証情報と「社内の未修正脆弱性の一覧」を同時に抱えるサーバなので、優先度は高めに見積もるべき案件です。

この記事でわかること

• Tenable Security Center とは何をするサーバで、社内のどこに置かれているか
• 今回修正された脆弱性のうち、どれを優先して見るべきか
• 「認証が必要だから低リスク」と切り捨てられない理由
• すぐにバージョンアップできない場合の暫定的な考え方

Tenable Security Center とは何か

Tenable Security Center とは、社内に設置して使うオンプレミス型の脆弱性管理コンソールです。「Security Center」という一般名詞のような製品名なので気づきにくいのですが、次の3点を押さえると自社に関係あるかを判断できます。

• 何をするものか：Nessus スキャナや Nessus Manager、エージェントが集めたスキャン結果を1か所に集約し、ダッシュボード・レポート・リスクの優先度付けを行う管理サーバです。
• 誰が使うか：情シスやセキュリティ部門が、資産全体の脆弱性を継続的に把握するために導入します。クラウド版にあたるのが Tenable Vulnerability Management で、クラウドに出せない閉域網や、オンプレ運用が要件の組織が Security Center を選びます。
• どこで動いているか：Red Hat Enterprise Linux / Oracle Linux / CentOS Stream 上に RPM で導入され、管理画面は HTTPS で提供されます。「Nessus を社内で回している」組織の“親サーバ”がこれにあたるケースが多く、旧称の Tenable.sc（さらに以前は SecurityCenter）の名前で台帳に載ったままのこともあります。

製品名で心当たりがない場合でも、資産管理台帳を「Tenable.sc」「SecurityCenter」で検索し直すと出てくることがあります。導入がベンダー任せだった場合は特に見落としやすい部分です。

何が起きたのか

Tenable は2026年8月13日、Security Center 6.8.0 以前を対象とするアドバイザリ TNS-2026-22 を公開しました。修正は Security Center 6.9.0 で提供されます。

修正された脆弱性は計20件で、内訳は Security Center 本体の脆弱性が11件、残りが同梱されているサードパーティ製コンポーネント（curl、underscoreJS）の脆弱性です。curl は 8.20 へ、underscoreJS は 1.13.8 へ更新されています。

本体側11件のうち、深刻度が「Critical」「High」に分類されたものは次のとおりです。

このほか、アクセス制御不備（CVE-2026-19639、CVSS 4.3）、総当たりによる列挙（CVE-2026-19636、CVSS 5.3）、SQLインジェクション（CVE-2026-19631、CVSS 4.9）が Medium として修正されています。同梱の curl 側にも CVE-2026-11856（CVSS 9.8）、CVE-2026-11564（CVSS 9.1）といった Critical が含まれます。

なお、CVSSスコアの読み方や優先度判断への使い方はCVSSとは？脆弱性の深刻度を評価する仕組みと使い方で整理しています。

最優先はどれか？ 認証済みの「非管理者」で成立するRCE

最優先は CVE-2026-19626 です。レポート生成機能の欠陥で、認証済みの非管理者ユーザーが細工した入力を与えると、サーバ側のレポート描画処理でサービスアカウント権限の任意コード実行に至ります。

CVSSベクトルは CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H です。ここで注目したいのは2点あります。

• PR:L（必要権限＝低）：管理者アカウントは不要です。閲覧・レポート参照のために配った一般アカウントで足ります。
• S:C（スコープ変更）：影響がアプリケーションの境界を越えます。9.9という値はここから来ています。

一方、High に分類された CVE-2026-19628 は、認証済み「管理者」が設定値を書き換えることでOSコマンドを実行できるというもので、必要権限が高いぶんスコアが 7.2 に抑えられています。同じOSコマンドインジェクションでも「誰なら踏めるか」で優先度は大きく変わります。攻撃手法そのものの解説はSQLインジェクションとは？仕組みと情シスの対策を解説や権限昇格とは？攻撃の仕組みと情シスの対策を解説もあわせてご覧ください。

なお CVE-2026-19681 と CVE-2026-19682 は、Tenableのアドバイザリ本体には種類とスコアしか記載がありませんが、NVDに登録された説明（2026年8月14日公開、採番元はTenable）で概要が公開されています。CVE-2026-19681 はファイルアップロード処理に関する認証済みユーザーのコマンドインジェクションで、細工したファイルをアップロードするとOS上で任意のコマンドが実行され得るとされています。CVE-2026-19682 は、NVDの説明では「リモートの未認証の攻撃者」がサービスアカウント権限でOSコマンドを実行できる、と記載されています。

ただし CVE-2026-19682 は、同じTenable由来の情報どうしで記載が食い違っています。アドバイザリのCVSSベクトルは PR:L（＝何らかの権限が必要）で、上記の「未認証」という説明と整合しません。スコアも アドバイザリの表では 9.0 【要確認 2026-08-19：同ページのベクトル AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H はCVSS v3.1で9.9に相当し、NVD側のTenable提供スコアも9.9（CVSS v4.0では9.4）。どちらが正しいかはTenableの続報で要確認】。NVDのステータスも「Undergoing Analysis（分析中）」のままです。未認証で悪用できるのかどうかは現時点で確定していないという前提で、続報を確認してください。

なぜ「この1台」が特に危ないのか

脆弱性管理サーバは、一般的な業務サーバとは危険度の質が違います。理由は、攻撃者にとって価値の高いものを2つ同時に持っているためです。

ひとつはスキャン用の認証情報です。Tenable の公式ドキュメントによれば、Security Center は再利用可能なオブジェクトとして認証情報を保持し、Windows、SSH、データベース、SNMP、Web、APIゲートウェイなど複数種類を登録できます。認証スキャン（クレデンシャルスキャン）を回している組織なら、そこに広い範囲に通る強い権限のアカウントが登録されているはずです。

もうひとつは未修正脆弱性の一覧そのものです。どの端末のどのソフトにどんな穴が残っているかが、部門・IPアドレス単位で整理されています。攻撃者から見れば、これは「攻撃計画書」に近い資料です。

つまりこのサーバの侵害は、鍵束と社内地図を同時に渡すことに近い。スコアだけを見て他の High と横並びに扱うと、判断を誤ります。脆弱性管理の全体像は脆弱性管理とは？プロセスと情シスの進め方を解説で解説しています。

現場目線の課題：セキュリティ製品ほど後回しになる

率直に言って、この手の案件がいちばん厄介なのは技術面ではなく運用面です。現場では次のことが起こりがちです。

「セキュリティ製品なんだから安全だろう」という無意識の前提があります。脆弱性を探すための製品が脆弱性を持つ、という構図は頭では理解していても、パッチ適用のキューでは自然と後ろに回されます。業務システムを止める話ではないので、止める調整も要らない代わりに、急ぐ理由も社内的に説明しにくいのです。

今回の修正が 6.9.0 というバージョンアップである点も重いです。Tenable は過去に SC202607.1 のようなスタンドアロンパッチを出したこともありますが、今回のアドバイザリで示されている対策は 6.9.0 への更新です。6.9.0 は脆弱性の検出結果画面が刷新されるなど機能面の変更も含むため、「セキュリティ修正だけ当てて他は変えない」という進め方ができません。ダッシュボードやレポートを他部署・監査向けに提供している組織ほど、検証と周知に時間がかかります。

そして、閲覧アカウントの棚卸しは後回しになりがちです。脆弱性管理コンソールは「各システム担当者に自部門の結果を見てもらう」使い方をすることが多く、低権限アカウントが増えやすい構造です。今回の CVE-2026-19626 は、まさにその低権限アカウントで成立します。異動して使っていないアカウント、委託先に渡したまま残っているアカウントが、そのまま攻撃の入り口になり得ます。台帳と実態が一致しているかを、この機会に確認したいところです。

情シスはどうすべきか

まず該当判定です。心当たりがない場合も、次の手順で存在を確認できます。

• 資産管理台帳を「Tenable」「Tenable.sc」「SecurityCenter」で検索する（旧称のまま登録されていることがあります）
• サーバ上で rpm -qa | grep -i securitycenter を実行し、導入パッケージとバージョンを確認する
• 管理画面にログインできる場合は、画面上でバージョンを確認する
• 6.8.0 以前であれば対象です

対象だった場合の基本方針は 6.9.0 への更新ですが、検証にどうしても時間がかかるなら、その間のリスクを下げる観点として次を検討する価値があります。いずれも根本対策ではなく、更新までの時間を稼ぐための措置です。

• 管理画面へのアクセス元を管理用ネットワーク・特定端末に限定する（インターネットや広い社内セグメントから直接届く状態を避ける）
• 不要なユーザーアカウントを停止・削除し、残すアカウントの権限を見直す
• 登録済みのスキャン用認証情報を洗い出し、過剰な権限のものがないか確認する
• 管理画面へのログイン試行やレポート生成まわりのログを、通常より注意して確認する

あわせて、こうした「パッチが多すぎて順番がつけられない」状況への向き合い方は、公的機関の指針を土台にするのが結局は近道です。IPAの中小企業の情報セキュリティ対策ガイドラインは資産把握と対策の優先順位づけの考え方が整理されており、規模を問わず土台として使えます。実際にインシデントが起きたときの動き方を事前に確かめておきたい場合は、セキュリティインシデント対応 机上演習教材が役立ちます。件数の多い月例パッチをどうさばくかについては、Microsoft月例パッチ751件、実質420件の見極め方でも考え方を整理しています。

なお、管理コンソールを守るうえでは、地道な話ですが「アカウントを配ったら台帳に書く・使わなくなったら消す」という運用の徹底が、結局いちばん効きます。今回のように低権限アカウントが起点となる脆弱性では、その差がそのまま被害範囲の差になります。

まとめ

• Tenable Security Center 6.8.0 以前に計20件の脆弱性。2026年8月13日公開の TNS-2026-22 で、修正版は 6.9.0。本体11件のうち3件が Critical。
• 最優先は CVE-2026-19626（RCE、CVSS 9.9）。管理者権限は不要で、認証済みの非管理者ユーザーで成立する。閲覧用アカウントの棚卸しもあわせて実施したい。
• 脆弱性管理サーバは「鍵束と社内地図」を持つ。スキャン用認証情報と未修正脆弱性の一覧を抱えるため、スコアの横並び比較ではなく、資産の重要度を加味して優先度を上げるべき。

出典

• Tenable: Security Center 6.9.0 Fixes Multiple Vulnerabilities（TNS-2026-22）
• Tenable: Tenable Product Security Advisories
• Tenable Docs: Welcome to Tenable Security Center
• Tenable Docs: Credentials
• Tenable Docs: Tenable Security Center 2026 Release Notes
• Security NEXT: 「Tenable Security Center」に深刻な脆弱性 – 修正版を公開