「CVSS 10.0 の RCE」は、脆弱性ニュースの中でも特に深刻なものを表す言葉です。なぜRCEが“最悪クラス”なのか、他の脆弱性と何が違うのかを、ゼロから解説します。
他の脆弱性と何が違うのか
多くの脆弱性は被害が限定的です。RCEは「サーバー本体でコマンドが動く」ため、桁が違います。代表的な3つと比べてみます。
| 脆弱性 | コードが動く場所 | 主な被害 | 一般的な深刻度 |
|---|---|---|---|
| XSS | 利用者のブラウザ | セッション窃取・画面改ざん | 中〜高 |
| SQLi | データベース | データの読み出し・改ざん | 高 |
| RCE | サーバー本体 | 乗っ取り・他のサーバーへの侵入拡大・あらゆる操作 | 最悪（10.0級も） |
なぜ最悪クラスなのか
攻撃者がサーバー上でコマンドを実行できる＝そのプロセスができることは何でもできることを意味します。
RCE 成立（任意コード実行）
.env を読んでシークレット窃取被害範囲は「そのプロセスの権限」で決まります。だからこそ、**コンテナ化・最小権限・分離（被害範囲の最小化）**が効きます。root で動かしていればサーバー全体を操作され、非特権ユーザー＋分離なら被害を閉じ込められます。
多くは自分のバグではなく、公開済みの脆弱性から起きる
RCEは、自分が書いたバグだけでなく、使っているフレームワークやライブラリの既知の脆弱性から起きることが非常に多いです。歴史的な大事故も、その多くがRCEでした。
- Log4Shell（CVE-2021-44228）：ログ部品経由のRCE。世界中で対応に追われた。
- Equifax（CVE-2017-5638）：未パッチのStruts RCEで1.47億人。
- 放置したCVSS 10.0を悪用された話：公開済みRCEを数ヶ月放置。
利用者にできる防御
公開済みCVEを放置しない（最大の防御）
CVE を機械で監視（Dependabot / osv-scanner）し、修正版へ迅速に更新する。RCEの大半は「既知の脆弱性の放置」から起きる。
実稼働版で判定する
マニフェストの下限表記ではなく、実際に動いているバージョンで危険を測る。表記を信じると危険度を誤判定する。
被害の範囲を小さくする
非特権ユーザーで動かし、コンテナ・ネットワークを分離。万一悪用されても被害を限定する。
入力を実行系に直接渡さない
外部入力をシェルコマンドやデシリアライズ・テンプレート評価へそのまま渡さない。自分でRCEを作り込まない基本。
RCEにつながる主な原因
RCEは結果の名前で、原因はいくつかの種類に分かれます。MITREが2025年12月に公表した「CWE Top 25」（危険なソフトウェアの弱点の上位25）にも、RCEにつながる弱点が多く入っています。
| 原因（CWE） | どういうものか | CWE Top 25（2025） |
|---|---|---|
| OSコマンドインジェクション（CWE-78） | 外部入力がシェルのコマンドに混ざり、命令として実行される | 9位 |
| コードインジェクション（CWE-94） | 外部入力が、プログラムのコードとして評価・実行される | 10位 |
| 危険なファイルのアップロード（CWE-434） | 実行できるファイルを置かれ、サーバーで動かされる（→ ファイルアップロードの脆弱性） | 12位 |
| 安全でないデシリアライズ（CWE-502） | 外から受け取ったデータを復元する処理で、コードが動く（→ 安全でないデシリアライズ） | 15位 |
| メモリ破損（CWE-787 など） | C/C++製のソフトでメモリの範囲外に書き込まれ、処理を乗っ取られる | 5位（範囲外書き込み） |
自分のアプリで作り込みやすいのは上の4つです。メモリ破損は、主にOSやネットワーク機器、ライブラリの側で見つかり、利用者にできる対策は更新です。
具体例：外から届く場所にある製品が狙われる
- ネットワーク機器：米国のCISAとFBIは2024年7月、ネットワークの境界に置く機器のOSコマンドインジェクションが、認証なしのRCEとして悪用された事例を受けて、この種類の欠陥をなくすよう製品の作り手に求める注意喚起を出しました（→ VPN機器の脆弱性への備え）。
- AIツール：AIエージェント構築ツールLangflowでは、コードを検証する機能に認証なしのRCE（CVE-2026-0770）が見つかり、KEVに載りました（→ CVE-2026-0770の解説）。
- CMS：WordPress本体のファイルインクルードの脆弱性（CVE-2026-87902）は、サーバー側の条件がそろうとRCEに至ります（→ CVE-2026-87902の解説）。
共通しているのは、インターネットから認証なしで届く場所にある製品だという点です。RCEの危険度は、脆弱性そのものに加えて「外から届くか」で大きく変わります。
「CVSS 10.0のRCE」と聞いたら確認すること
使っているか
CVE / KEV ルックアップでCVE番号から対象の製品と版を確認し、自分の環境の実際の版と照らし合わせる。依存ライブラリは osv-scanner で一括確認できる。
外から届くか
対象の機能や管理画面が、インターネットから認証なしで到達できるかを確認する。届くなら、更新まで公開を止めることも検討する。
悪用されているか
CISAのKEVに載っていれば、実際に悪用されている。点数の読み方は CVSS・EPSS・KEVで優先順位を決めるを参照。
更新したら、侵入の痕跡も確認する
更新前に侵入されていれば、更新しても攻撃者は残る。不審なファイル、新しいアカウント、外向きの不審な通信（C2）がないかを確認する。
出典（一次情報）
- MITRE「2025 CWE Top 25 Most Dangerous Software Weaknesses」（2025年12月） — cwe.mitre.org（CWE-78・94・434・502・787の順位）
- CISA・FBI「Secure by Design Alert: Eliminating OS Command Injection Vulnerabilities」（2024年7月10日） — cisa.gov
- FIRST「CVSS v3.1 Specification Document」 — first.org（深刻度の評価基準）
- CISA「Known Exploited Vulnerabilities Catalog」 — cisa.gov
次に読む
- 用語：CVE とは / CVSS とは
- 歴史：Log4Shell — 依存経由のRCE
- 対策：Next.js を安全に運用する（CVE追従）
よくある質問
QRCEとよくある脆弱性（XSSなど）は何が違う？
XSSなどが主に『利用者のブラウザ内』で悪さをするのに対し、RCEは『サーバー本体』で任意のプログラムを動かせます。サーバーの権限・データ・他サービスへ波及しうるため、一般に最も深刻です。
QRCEの被害はどこまで広がる？
『攻撃された時に動いていたプロセスの権限』までです。rootや広い権限で動かしていれば被害は甚大に、非特権ユーザー＋コンテナ分離なら被害を閉じ込められます。だから最小権限と分離が効きます。
Q利用者（開発者）側でRCEをどう防ぐ？
自分でRCEバグを書かない工夫（入力を実行系に直接渡さない等）に加え、最大の防御は『使っているフレームワーク/ライブラリの公開済みRCEを放置しない』こと。CVE監視と迅速な更新が要です。
Q「CVSS 10.0のRCE」とはどういう意味？
CVSS（脆弱性の深刻度を0.0〜10.0で表す共通の尺度）で最高点がついたRCEという意味です。一般に、ネットワーク越しに、認証なしで、利用者の操作も要らずに攻撃でき、機密性・完全性・可用性のすべてに大きな影響があり、さらにその影響が脆弱な部品の外にまで及ぶときにこの点数になります。使っている製品が該当するなら、他の作業より先に更新や公開の停止を検討する水準です。
QRCEと任意コード実行（ACE）の違いは？
任意コード実行（ACE）は、攻撃者が好きなプログラムを動かせる状態全般を指します。RCEはそのうち、ネットワーク越しに外から実行できるものです。手元のファイルを開かせる必要がある場合などは、任意コード実行でもRCEとは呼ばないことがあります。
QRCEの脆弱性が見つかったら、最初に何をする？
①その製品と版を本当に使っているかを確認、②インターネットから到達できるかを確認、③修正版への更新、それができなければ公開の停止や回避策、④CISAのKEV（実際に悪用が確認された脆弱性の一覧）に載っているなら、侵害の痕跡がないかも確認、の順です。更新だけで終わらせず、更新前に侵入されていないかを確かめることが大切です。