OneUptimeに致命的コマンドインジェクション：CVE-2026-27728でProbeサーバーが乗っ取られる条件と今すぐやるべき対策

稼働監視は「止まったら気づく」ための仕組みですが、監視基盤そのものが踏み台にされると被害は一気に拡大します。OneUptimeのProbe Serverに、認証済みユーザーでもサーバー上で任意コマンドを実行できるクリティカル脆弱性（CVE-2026-27728）が報告されました。影響範囲は広く、10.0.7未満を使っている場合は“監視のためのサーバー”が“侵入の入口”になり得ます。 Tenable®+1

OneUptimeに致命的コマンドインジェクション：CVE-2026-27728でProbeサーバーが乗っ取られる条件と今すぐやるべき対策

何が起きる脆弱性なのか（CVE-2026-27728の要点）

CVE-2026-27728は、OneUptimeのProbe Server（監視の実行役）でOSコマンドインジェクションが可能になる問題です。前提として攻撃者は「未認証の外部者」ではなく、プロジェクトにログインできる“認証済みユーザー”である必要があります。しかし、権限が強くなくても「監視設定を作れる/編集できる」程度のアクセスで成立する点が厄介です。 Tenable®+1

深刻度も高く、CVSS v3.1のベクターではネットワーク経由で低い権限（PR:L）から成立し、機密性・完全性・可用性に高い影響が出る評価になっています。 CVEFeed+1

技術的にどこが危ないのか：traceroute実行部分の落とし穴

問題の中心は、Probe Server側の NetworkPathMonitor.performTraceroute() にあります。ネットワーク経路監視の一環で traceroute を実行する際、監視設定に含まれる「destination（宛先）」がユーザー入力として渡されます。 GitHub+1

ここで、Node.jsの child_process.exec() のように「シェル経由で文字列コマンドを実行する」作りになっていると、; や |、&&、$()、バッククォートなどのシェルメタ文字が解釈され、tracerouteの引数を“抜けて”別コマンドを連結できてしまいます。結果として、監視宛先の欄に悪意ある文字列を入れるだけで、Probeサーバー上で任意コマンド実行（RCE）に到達します。 GitHub+1

攻撃シナリオ：内部犯だけでなく「乗っ取られた低権限アカウント」でも成立

成立条件が「認証済み」なのは一見ハードルに見えますが、現実の事故パターンでは次が頻出です。

フィッシングやパスワード使い回しで、閲覧中心のアカウントが奪われる
権限分離が甘く、一般ユーザーでも監視作成・編集が可能
外部委託や一時アカウントが残存し、最小権限が守られていない

Probeは監視を成立させるためにネットワーク到達性が高く、環境によっては強い権限で動いていることもあります。その場合、被害は「Probe一台」では終わらず、認証情報の窃取、設定ファイルの閲覧、社内ネットワークへの横展開（ラテラルムーブメント）へ進みやすくなります。 Tenable®+1

影響を受けるバージョンと修正：10.0.7未満は要注意

影響があるのは、修正前のバージョン（10.0.7より前）です。修正は10.0.7で提供されており、脆弱性の根本である「シェル解釈」を避ける方向での対策が取られています。 Tenable®+1

一般にこの種の修正は、exec() のような“シェルに渡す”実行から、execFile() のような“バイナリを引数配列で直接起動する”方式へ切り替えるのが定石です。シェルが介在しないため、メタ文字を使った注入が成立しにくくなります。 Tenable®+1

いま取るべき実務対策：最短でリスクを落とす手順

ここからは「現場で今日やること」を優先順にまとめます。

1) 最優先：10.0.7以降へアップデート

パッチ適用が最も確実です。Probe Serverを含む関連コンポーネントが混在している場合は、実際に脆弱な実行経路が残っていないか、デプロイ単位で洗い出してください。 Tenable®+1

2) 監視設定（destination）を棚卸し：メタ文字の混入チェック

緊急対応として、監視の宛先に以下が含まれていないか点検します。
; | & && || $() \ < >` などのシェルで意味を持つ文字列、または不自然に長い宛先、空白や改行の混入は要警戒です。脆弱性は「設定に入れて実行される」ため、設定の監査が有効な抑止になります。 GitHub+1

3) Probeサーバーの監視を強化：プロセス・通信・改ざん兆候

侵害の痕跡は、次の観点で見つかりやすいです。

traceroute以外の不審プロセス生成（シェル、curl/wget、圧縮・転送系）
外向きの未知ドメイン/未知IPへの通信
監視対象外のファイル改変、権限変更、永続化（cron、systemd、SSH鍵）

Probeは運用上ログが薄くなりがちなので、少なくともコマンド実行ログ・プロセス生成・送信先通信の3点を優先して可視化すると、復旧判断が速くなります。

4) パッチまでの暫定策：ネットワーク隔離と権限最小化

やむを得ず即時更新できない場合は、被害半径を縮めます。

Probeの配置を分離（重要サーバーと同居させない）
外向き通信を必要最小限に制限（更新/監視に必要な宛先だけ許可）
監視作成・編集権限を限定し、プロジェクト参加者の棚卸しを実施

「認証済みで成立する」脆弱性は、権限設計とアカウント衛生で現実的に発火率を下げられます。 Tenable®+1

再発防止の観点：監視基盤を“特権システム”として扱う

監視や運用ツールは、便利さの裏で権限と到達性が集約されやすい領域です。今回のように「入力→シェル実行」が紛れ込むと、低権限アカウントからでも一気にRCEへ到達します。Probeや監視実行ノードは、以下の原則で守るのが効果的です。

シェル経由の実行を避け、引数配列での安全な起動に統一
設定値は“データ”として扱い、コマンド文字列に連結しない
監視実行ノードをゼロトラスト前提で分離し、横展開を困難にする

OneUptimeを使っている組織は、まずバージョン確認と10.0.7以降への更新、次に監視設定の監査とProbeの隔離・権限見直しをセットで実施してください。監視基盤の安全性は、インフラ全体の安全性そのものです。 Tenable®+2Miggo+2