CVSSv3とは？v3.1のスコアの目安・計算式と計算機の使い方を解説

CVSSv3は、脆弱性の深刻度を0.0〜10.0の数値で表す共通脆弱性評価システム（CVSS）のバージョン3系で、2015年公開のv3.0と2019年公開のv3.1を指します。この記事では、FIRSTの仕様書にある重みと計算式でスコアの出し方を追い、ベクトル文字列をFIRSTの計算機に読み込ませて点数を確かめる方法と、IPAの21事例で一致を確かめたPythonの検算コードを載せます。NVDで2026年9月に公開されたCVEを全件集計し、よく見るベクトルと深刻度の分布もまとめました。2023年11月に公開された後継のv4.0で何が変わったかは、後半の章で扱います。

まとめ：CVSSv3の要点

• CVSSv3は基本（Base）・現状（Temporal）・環境（Environmental）の3つの評価基準でスコアを出します。公開情報に載るのはほぼ基本値です。
• 基本値は8指標（AV・AC・PR・UI・S・C・I・A）の組み合わせで決まり、計算式と重みは仕様書で固定されています。同じベクトル文字列なら誰が計算しても同じ値になります。
• 深刻度の目安は、9.0〜10.0がCritical（緊急）、7.0〜8.9がHigh（重要）、4.0〜6.9がMedium（警告）、0.1〜3.9がLow（注意）です。2026年9月公開のCVEでは、v3.1の値の57.4%がHigh以上でした。
• 点数を確かめるなら、FIRSTの計算機のURLの末尾に #CVSS:3.1/AV:N/… を付けて開くのが早道です。接頭辞の版が計算機と合っていないと読み込まれません。
• v3.1は指標を増やしていません。変わったのは切り上げ関数の定義、環境値の一部の式、採点ガイダンスです。
• v4.0が公開された後も、2026年9月にNVDで公開されたCVEの83.3%にv3.1の値が付いていました。v4.0は攻撃要件の新設やスコープの廃止で尺度が変わったので、v3.1の数値と並べて比べないでください。
• 基本値は深刻度であってリスクではありません。対応順は、環境値・露出・悪用実績（KEV）と合わせて決めます。

CVSSv3の定義とv3.0・v3.1の公開時期

CVSSは、FIRST（Forum of Incident Response and Security Teams）のCVSS-SIGが管理する、ベンダーに依存しない脆弱性評価の手法です。IPAの「共通脆弱性評価システムCVSS v3概説」によると、2004年10月に原案が作られ、2005年6月にv1、2007年6月にv2が公開されました。v3は2012年6月に検討が始まり、2015年6月10日にv3.0が公開されています。

v3の設計で大きく変わったのは評価の単位です。v2は攻撃対象のホストやシステム全体で深刻度を見ていましたが、v3は仮想化やサンドボックス化の普及を受けて「脆弱性のあるコンポーネント」単位で評価します。この考え方から、影響がコンポーネントの外へ広がるかを表すスコープ（S）という指標が生まれました。

FIRSTのCVSSページは現行の規格をv4.0と明記していて、v3.1の仕様書や計算機は「CVSS v3.1 Archive」の見出しの下に置かれています。v3.1の仕様書自体は「CVSSバージョン3.1の公式仕様」として公開が続いていて、実際に公開されるスコアも今はv3.1が中心です（後述）。

v3.0からv3.1で変わった計算結果と変わらない計算結果

v3.1のUser Guideは、変更の範囲を「新しい指標や指標値を追加せず、既存の式にも大きな変更を加えない」と説明しています。ベクトル文字列の先頭が CVSS:3.0/ から CVSS:3.1/ に変わりますが、8つの基本指標と重みは同じです。計算結果に影響する変更は次の2つです。

• Roundup関数の再定義：v3.0の「Round up」は、浮動小数点の誤差で0.1ずれることがありました。v3.1は、入力を100,000倍して整数に直してから切り上げる方式を仕様書のAppendix Aで示しています。User Guideは、基本値が2.5・5.0・10.0でE:H/RL:U/RC:Uの組み合わせでは、現状値がv3.0より0.1低くなると明記しています。
• 環境値のModifiedImpactの式：修正スコープが「変更あり」で、要求度（CR・IR・AR）のどれかが「高」のとき、v3.0では値を上げる方向の設定をしても環境値が下がる逆転がありました。v3.1は末尾の指数を15から13に変え、MISSに0.9731を掛けて修正しています。User Guideによると、環境値が0.1上がる組み合わせは7%未満、0.1下がる組み合わせは1%未満で、0.1を超える差はありません。

User Guideが差分として挙げているのは現状値と環境値だけで、基本値の差は挙がっていません。計算以外では、隣接（A）の定義がMPLSやVPNのような論理的に隣接するネットワークまで広がり、ライブラリの採点指針や、追加指標を定義するExtensions Frameworkが入りました。

CVSSv3スコアの目安：深刻度5段階と0.0〜10.0の対応

「CVSSv3のスコアの目安は？」への答えが、v3.1仕様書のTable 14にある定性的な深刻度の区分です。日本語はIPAの訳語を併記し、2026年9月にNVDで公開されたCVEのv3.1の値（12,443件）がどの区分に入ったかも並べました。

仕様書はこの区分の使用を任意としています。区分の境目にも余裕が取られていて、式を作る際には、想定した深刻度から0.5の範囲に収まるずれを許容しています。仕様書は、Highを想定した組み合わせでも6.6〜9.3の値になりうると書いています。6.9と7.0の0.1差を根拠に対応期限を大きく分ける運用は、この精度を超えた使い方です。

分布の偏りにも注意してください。v3.1の値が付いた12,443件のうち、HighとCriticalを合わせると57.4%（7,137件）です。「High以上はすぐ対応」という線引きでは対象の半分以上が即時対応に入るので、その中の順番を決める別の基準が必要になります。

基本評価基準（Base）の8指標と計算に使う重み

基本評価基準は、時間や利用環境で変わらない脆弱性そのものの性質を評価します。各指標の値と、計算式に入る重み（仕様書Table 16）は次のとおりです。

攻撃のしやすさを表す4指標（AV・AC・PR・UI）と影響を表す3指標（C・I・A）を別々に計算して足し、スコープで式を切り替える構造です。

攻撃容易性の4指標：AV・AC・PR・UI

攻撃元区分（AV、英語名Attack Vector）は、ネットワーク（N）・隣接（A）・ローカル（L）・物理（P）の4段階です。物理はv3で新設された値で、v2ではUSB経由のような攻撃もローカルに含まれていました。必要な特権レベル（PR）とユーザ関与レベル（UI）もv3で入った指標です。v2の「攻撃前の認証要否（Au）」は廃止され、PRの一部として評価するようになりました。

攻撃条件の複雑さ（AC）はv2にも同名の指標がありました。v3.1では、ACの説明から「特定のシステム設定の有無」という表現が削除されています。攻撃に特定の設定が必要でも、それが合理的な設定であれば、その設定で動いている前提で採点します。

スコープ（S）：権限の範囲を越える影響の評価

スコープは、脆弱性のあるコンポーネントと、影響を受けるコンポーネントが同じ権限の範囲にあるかを表します。IPAは、Webアプリのクロスサイトスクリプティングが利用者のブラウザに影響する例と、ゲストOSの脆弱性がホストOSに影響する例を挙げています。

変更あり（C）では影響度の式が変わって合計に1.08が掛かり、PRの重みも上がります。IPAの集計では、全組み合わせの平均値がスコープ変更なしで4.99、変更ありで6.00です。満点の10.0は、スコープ変更ありでなければ出ません。NVDはLog4Shell（CVE-2021-44228）を S:C で10.0と評価しています。

影響の3指標：機密性・完全性・可用性

機密性（C）・完全性（I）・可用性（A）は、それぞれ高（H）・低（L）・なし（N）で評価します。v2は「部分的／全面的」という影響の広さで判定していましたが、v3は重要な情報への影響があるかで判定します。この違いで、同じ脆弱性でもv2からv3で点数が大きく変わることがあります（後述のHeartbleed）。v3.1のガイダンスは、攻撃前から持っていた権限ではなく、攻撃によって新たに得られる権限の増分で影響を採点するよう定めています。

CVSSv3の計算式とベクトル文字列の読み方

ベクトル文字列 CVSS:3.1/AV:N/… の構造

ベクトル文字列は、評価に使った指標の値を1行で記録する形式です。先頭のバージョン識別子の後に「指標:値」をスラッシュで並べます。

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

この例は「ネットワークから・攻撃者の制御外にある特別な条件を必要とせず・事前の特権なし・ユーザ操作なしで攻撃でき、スコープは変わらず、機密性・完全性・可用性すべてに高い影響がある」という意味で、基本値は9.8です。現状・環境の指標は /E:F/RL:X のように後ろへ足します。スコアの数値だけでは根拠が分からないので、社内で記録するときもベクトル文字列ごと残してください。

9.8の計算過程：ISS・影響度・攻撃容易性

基本値は仕様書7.1節の式で計算します。上のベクトルに重みを当てはめると次のようになります。

• ISS（影響の小計）＝1 −（1−0.56）×（1−0.56）×（1−0.56）＝0.914816
• 影響度（スコープ変更なし）＝6.42 × ISS ≒ 5.873
• 攻撃容易性 ＝8.22 × 0.85 × 0.77 × 0.85 × 0.85 ≒ 3.887
• 基本値 ＝Roundup（min（5.873＋3.887, 10））＝Roundup（9.760）＝9.8

スコープ変更ありにすると、影響度は 7.52×（ISS−0.029）−3.25×（ISS−0.02）の15乗 ≒ 6.048 になります。1.08×（6.048＋3.887）≒10.73 は上限の10で切られ、10.0です。C・I・Aがすべて「なし」なら影響度が0以下になり、基本値は他の指標に関係なく0.0です。

FIRSTの計算機にベクトル文字列を読み込ませる手順

手元にベクトル文字列があるなら、指標を1つずつ選び直す必要はありません。FIRSTの計算機の設計説明には「URLでベクトル文字列を渡すと、計算機の指標ボタンがその値に設定される」とあり、例として次の形式が示されています。

https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

このURLを開くと、基本値7.5（High）の状態で計算機が表示されます。指標を変えるとURLの末尾も書き換わるので、そのURLを共有すれば相手も同じ評価を開けます。計算機のJavaScript（cvsscalculator31.js）は、URLの「#」以降を正規表現で検査してから指標に反映します。この正規表現をnodeで実行して確かめた、読み込まれない書き方は次の4つです。

• 接頭辞の版が違う：3.1の計算機は CVSS:3.0/ で始まる文字列を受け付けません。v3.0のベクトルは /cvss/calculator/3.0 で開くか、接頭辞を3.1に書き換えます（基本値は同じです）。
• 接頭辞がない：資料によっては AV:N/AC:L/… のように版の接頭辞を省いて書かれていますが、この形は受け付けません。先頭に CVSS:3.1/ を足します。
• 小文字や末尾のスラッシュ：cvss:3.1/av:n/… のような小文字や、末尾に / が残った文字列は不正な形式として扱われます。
• 基本指標の欠け：8つの基本指標のどれかが欠けると反映されません。現状・環境の指標は省略でき、省いたものは「未評価（X）」になります。

URLを開いても指標が選ばれないときは、上の4点を疑ってください。日本語の画面で使いたい場合は、JVN iPediaの計算機（jvndb.jvn.jp/cvss/ja/v3.html）があります。どの計算機でも、画面に表示されたCVSSの版を確かめ、ベクトルの接頭辞と合わせて使ってください。基本値の全2,592通りで、v3.0の素朴な切り上げとv3.1の切り上げ関数の結果は一致するので、基本値だけならv3.0の計算機でもv3.1の計算機でも同じ値が出ます。

Pythonでの検算コードとIPA掲載21事例での照合

多数のベクトルをまとめて計算したいときは、仕様書の式をそのまま書いた関数が使えます。次のコードは、仕様書の重み・式・Appendix Aの切り上げ方式で基本値と現状値を計算します。正しいベクトルを検算するための簡易版で、版の接頭辞、指標の重複、不正な値は検査しません。

import math

AV = {"N": 0.85, "A": 0.62, "L": 0.55, "P": 0.2}
AC = {"L": 0.77, "H": 0.44}
UI = {"N": 0.85, "R": 0.62}
CIA = {"H": 0.56, "L": 0.22, "N": 0.0}
E = {"X": 1, "H": 1, "F": 0.97, "P": 0.94, "U": 0.91}
RL = {"X": 1, "U": 1, "W": 0.97, "T": 0.96, "O": 0.95}
RC = {"X": 1, "C": 1, "R": 0.96, "U": 0.92}

def roundup(x):
    # 仕様書 Appendix A の方式：整数に直してから小数第1位へ切り上げる
    i = round(x * 100000)
    if i % 10000 == 0:
        return i / 100000.0
    return (math.floor(i / 10000) + 1) / 10.0

def metrics(vector):
    return dict(p.split(":") for p in vector.split("/")[1:])

def base_score(vector):
    m = metrics(vector)
    changed = m["S"] == "C"
    pr = {"N": 0.85, "L": 0.68 if changed else 0.62,
          "H": 0.5 if changed else 0.27}[m["PR"]]
    iss = 1 - (1 - CIA[m["C"]]) * (1 - CIA[m["I"]]) * (1 - CIA[m["A"]])
    if changed:
        impact = 7.52 * (iss - 0.029) - 3.25 * (iss - 0.02) ** 15
    else:
        impact = 6.42 * iss
    expl = 8.22 * AV[m["AV"]] * AC[m["AC"]] * pr * UI[m["UI"]]
    if impact <= 0:
        return 0.0
    total = 1.08 * (impact + expl) if changed else impact + expl
    return roundup(min(total, 10))

def temporal_score(vector):
    m = metrics(vector)
    return roundup(base_score(vector) * E[m.get("E", "X")]
                   * RL[m.get("RL", "X")] * RC[m.get("RC", "X")])

print(base_score("CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"))  # 9.8
print(base_score("CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"))  # 10.0
print(base_score("CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N"))  # 3.1
print(temporal_score("CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C"))  # 8.8

IPAのCVSS v3概説には、実在する21件の脆弱性についてv3.0のベクトルと基本値が載っています。base_score に21件のベクトルを入れると、21件すべてがIPA掲載の基本値と一致します。3つめのprint文のベクトルは、そのうちの1件であるPOODLE（CVE-2014-3566）です。temporal_score は、4種類の基本ベクトルにX（未評価）以外のE・RL・RCの値を組み合わせた192通りと、User Guideの切り上げ例1通りの計193通りで、FIRSTが配布する計算機のJavaScript（cvsscalc31.js）と同じ値になることを確かめています。

切り上げを math.ceil(x * 10) / 10 で済ませると、User Guideが挙げる CVSS:3.1/AV:P/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:H/E:H/RL:U/RC:U で誤差が出ます。基本値5.0に0.92を掛けた値は、浮動小数点では4.6000000000000005になり、現状値が正しい4.6でなく4.7になります。v3.0時代の計算機と現状値が0.1ずれるのは、この切り上げが原因です（環境値は前述のModifiedImpactの変更も関わります）。

NVDでよく見るv3.1ベクトルと点数：2026年9月公開CVEの集計

脆弱性のニュースやNVDで見かける点数は、限られたベクトルに集中しています。NVDのAPIで2026年9月に公開されたCVE（取り下げを除く14,933件）を2026年10月25日に全件取得し、v3.1の値が付いた12,443件のベクトルを数えました。1件につき1つ、APIで種別がPrimaryの値があればその値、なければ配列の先頭の値を採っています。

基本値は上の関数で計算し、FIRSTの計算機のJavaScriptでも同じ値になることを確かめています。最も多いのは9.8ではなく、ローカルで一般権限を持つ利用者が使える7.8でした。一般権限から全面的な影響に届く、権限昇格にあたる形です。悪用にはその端末での低い権限が必要で、インターネットから単独では狙えませんが、別の脆弱性で得た実行権限から連鎖して悪用されることがあります。一方、件数4位の7.5は「認証なしで遠隔から停止させられる」脆弱性で、点数はHighの下の方でも、公開サーバーなら止められるのが実害です。同じ7.5でも、機密性だけが高い7位のベクトルは情報漏えいで、取るべき対策が違います。点数が同じでも中身が違うので、ベクトルを見ずに点数だけで並べないでください。

6.1の行は、IPAの事例でphpMyAdminのクロスサイトスクリプティング（CVE-2013-1937）に付いている組み合わせと同じです。利用者にリンクを踏ませる必要があり（UI:R）、影響が利用者のブラウザに及ぶ（S:C）ため、スコープ変更ありの評価になります。

現状評価基準（Temporal）：3係数で基本値を割り引く仕組み

現状評価基準は、攻撃コードの出回り具合や対策の有無など、時間とともに変わる要素を反映します。現状値は「基本値 × E × RL × RC」を切り上げたもので、上のコードの temporal_score がこの計算です。

係数はすべて1以下なので、現状値が基本値を超えることはありません。「攻撃コードが公開されると現状値が上がる」というのは、E:U（未実証）からE:P（実証可能）やE:F（攻撃可能）へ変わって、割引が小さくなるという意味です。E:H（容易に攻撃可能）は、自動化された攻撃コードが出回っているか、攻撃コードなしで攻撃できる状態を指します。基本値9.8の脆弱性でRL:O・RC:Cなら、E:Uで8.5、E:Pで8.8、E:Fで9.1、E:Hで9.4です。どれも9.8を上回りません。

環境評価基準（Environmental）：自社環境でスコアを付け直す手順

環境評価基準は、利用者が自社のシステムに当てはめて付け直す部分です。1つは、機密性・完全性・可用性の要求度（CR・IR・AR）で、低 0.5／中 1／高 1.5 の係数を掛けます。もう1つは、基本指標を自社の実態で上書きする修正版の指標（MAV・MAC・MPR・MUI・MS・MC・MI・MA）です。修正後の影響の小計（MISS）は0.915で頭打ちになります。

IPAは、ネットワークから攻撃できる脆弱性でも、実システムでファイアウォールによってアクセスが限られていれば攻撃元区分を「隣接」と評価し直す例を挙げています。FIRSTのv3.1 User Guide（3.6節）も、インターネットから届かない安全なネットワークに置かれていれば、MAVを「隣接」にしてよいとしています。基本値9.8のベクトルに当てはめると、環境値は次のように下がります。

• MAV:A（社内ネットワークからしか届かない）→ 8.8
• MAV:L（その端末にログインしないと届かない）→ 8.4
• CR・IR・ARをすべてL（機密性・完全性・可用性のどれが損なわれても組織への影響が限られる環境）→ 8.0
• MAV:AとCR・IR・AR:Lの組み合わせ → 6.9

これらの値は、FIRSTが配布する計算機のJavaScript（cvsscalc31.js）で計算した結果です。計算機の画面で再現するなら、CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/CR:L/IR:L/AR:L/MAV:A を前述のURLの「#」の後ろに付けて開きます。公開された基本値が9.8でも、安全な社内ネットワークに限られていることを確かめてMAV:Aとし、3つの要求度もLと評価できれば、6.9のMediumまで下がります。逆方向の例もあります。基本値7.5のHeartbleed（C:H/I:N/A:N）に機密性の要求度CR:Hを付けると、環境値は9.3のCriticalです。環境値を付けずに基本値だけで対応期限を決めると、この差がすべて抜け落ちます。

CVSSv2とCVSSv3の違い：同じ脆弱性で点数が上下した6事例

IPAの21事例には、同じ脆弱性のv2とv3の基本値が並んでいます。差が大きい6件を抜き出しました。

上がった3件は、影響の判定基準とスコープの導入が効いています。Heartbleedは、v2では機密性が「部分的」でしたが、v3では重要な情報が漏れるので「高」になりました。JunosとESXiは影響が他のコンポーネントへ及ぶため、スコープ変更ありで評価されています。下がった3件のうち2件は、評価の前提が変わっています。Adobe Readerは不正なファイルを開かせる攻撃なので、v2のネットワークからv3ではローカル（AV:L）になり、新設のUI:Rも付きました。POODLEは中間者攻撃が前提なのでAC:Hで、新設のUI:Rも付いています。Shellshockは、v2ではネットワーク・認証不要で3つの影響が全面的なら10.0でしたが、v3ではスコープが変わらない限り上限は9.8です。

2026年のCVSSv3の位置づけ：v4.0公開後もv3.1が併記される実態

v4.0の仕様書は2023年11月1日に初版が出ていますが、現場の数値は今もv3.1が中心です。

版ごとの付与状況：2026年9月公開CVEの83.3%にv3.1

前章と同じ2026年9月公開のCVE 14,933件を、付いているスコアの版で数えました。

• v3.1のスコアが付いたCVE：12,443件（83.3%）
• v4.0のスコアが付いたCVE：4,387件（29.4%）
• v3.xとv4.0の両方が付いたCVE：3,272件
• v4.0だけが付いたCVE：1,115件
• どの版のスコアも付いていないCVE：1,313件

v3.1は8割を超えるCVEに付いていて、v4.0は3割に届きません。2026年8月公開分（12,259件）を9月29日に数えたときも、v3.1は85.1%、v4.0は28.7%で、1か月で大きな変化はありません。v3.0の値が付いたCVEは62件だけで、v3系の値はほぼv3.1です。

付け手によるv3.1スコアの食い違い

v3.1の値の付け手は1つではありません。NVD自身が付けた値は932件で、それより多いのが、CISAがADP（追加データの提供者）として付けた値（2,285件）や、CVEを採番したCNA（ベンダーや調査機関）の値です。付け手が2者以上いるCVEは525件あり、そのうち422件（80.4%）で基本値が食い違い、249件（47.4%）では深刻度の区分まで違いました。たとえばCVE-2026-73778は、HPEが攻撃条件の複雑さを「高」として8.1、NVDが「低」として9.8を付けています。NVDのページで点数を確認するときは、誰が付けた値かと、ベクトルのどの指標で差が出ているかを見てください。

同じ付け手が後から値を差し替えることもあります。axiosの脆弱性CVE-2026-40175は公開時に10.0と発表されましたが、6日後に評価した当のGitHubが4.8へ差し替えました。NVDの変更履歴では、2026年4月10日に登録された S:C/C:H/I:H/A:H のベクトルが、4月16日に AC:H/S:U/C:L/I:L/A:N へ置き換えられています。経緯はCVE-2026-40175（axios）とは｜CVSS10.0から4.8になった経緯と確認・更新手順で解説しています。

v4.0で変わった指標と計算方式

v4.0は、基本（Base）・脅威（Threat）・環境（Environmental）・補足（Supplemental）の4つの指標群で構成されます。v3.1から見た主な違いは次のとおりです。

• 攻撃要件（AT）の新設：攻撃が成立するために脆弱なシステム側で必要な展開・実行条件を、攻撃条件の複雑さ（AC）から切り離して評価します。
• スコープの廃止：v3.0で入ったスコープは、脆弱なシステムへの影響（VC・VI・VA）と後続システムへの影響（SC・SI・SA）を分けて評価する形に置き換わりました。
• 現状評価基準から脅威評価基準へ：残った指標は攻撃の成熟度（E）だけで、v3.1の利用可能な対策のレベル（RL）と脆弱性情報の信頼性（RC）はありません。
• ユーザ関与（UI）の3段階化：なし（N）に加え、利用者の関与を受動的（P）と能動的（A）に分けます。
• スコアの呼び方：どの指標群を使ったかを、CVSS-B（基本のみ）・CVSS-BT・CVSS-BE・CVSS-BTEの表記で示すよう求めています。

計算方法も変わりました。v3.1は重みを掛け合わせる式ですが、v4.0はベクトルをMacroVectorという集合に分け、その間を補間して点数を出します。この記事の検算コードはv4.0には使えません。

同じ脆弱性にv3.1とv4.0の両方が付くと、数値が食い違います。F5はNGINXの脆弱性CVE-2026-42945に、v4.0で9.2（Critical）、v3.1で8.1（High）を付けています。v4.0は攻撃条件の扱いや影響の分け方が違う別の尺度なので、「v4.0では9.2に上がった」と読むのは誤りです。比べるときは同じバージョン同士で比べてください。この脆弱性の影響条件はNGINX Rift（CVE-2026-42945）の影響条件とPoC公開後の対応で解説しています。

基本値だけで対応順を決めてはいけない場面

v3.1のUser Guideは「CVSSは脆弱性の深刻度を測るもので、それだけでリスクを評価するものではない」と明記しています。基本値は、露出（インターネットから届くか）と悪用の実績を見ていません。

米CISAは2026年6月10日に拘束的運用指令BOD 26-04を出し、BOD 19-02とBOD 22-01を失効させました。新しい指令は、修正の緊急度を4つの変数で決めます。資産の露出、KEVカタログへの掲載、悪用の自動化の可否、悪用後の技術的影響です。実装ガイダンスには「BOD 19-02の失効により、連邦民間行政機関は脆弱性の優先順位付けにCVSSの使用を求められなくなった」とあります。ただし直後に、FIRSTのCVSS SIG消費者向け実装ガイダンスに沿うと続き、同ガイダンスの技術・脅威・環境の情報を使った優先順位付けを勧めています。CISAが外したのはCVSSそのものではなく、基本値だけで決める運用です。

「基本値9.0以上は即日、7.0台は月次パッチ」という一律ルールは採らないでください。HeartbleedはHigh（7.5）ですが、CISAのKEVカタログに2022年5月4日に登録されています。このルールでは、悪用が確認された脆弱性が月次に回ってしまいます。実務では次の順で判断します。

1. 公開されている基本値とベクトル文字列を確認します。付け手が複数いれば、どの値を採るかを決めます。
2. KEVへの掲載（悪用の事実）とインターネットへの露出を確認し、悪用の自動化の可否と悪用後の技術的影響も合わせて緊急度を決めます。KEVに載っている脆弱性は、基本値が低くても先に回します。
3. 環境値で自社環境での深刻度を評価し、業務への影響、攻撃経路、緩和策の有無、修正作業の制約も含めて対応順と期限を決めます。

ライブラリの脆弱性は特に注意が必要です。User Guideは、利用のされ方が分からないライブラリは「合理的な最悪ケース」で採点するよう定めています。自社製品で外部入力が届かない使い方なら、環境値で下げる余地があります。自社のシステムで実際に届く経路があるかを確かめるには、脆弱性診断・セキュリティ診断で外部から確認できる露出を調べ、構成情報やコード上の到達可能性の確認と組み合わせてください。脆弱性管理を継続的なプロセスとして組み立てる考え方はCTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説を参照してください。

よくある質問

CVSS v2とv3はどっちを使えばよいですか？

新しく評価するならv3.1かv4.0を使い、v2は使わないでください。v2はユーザ操作の要否やスコープを評価できず、ファイルを開かせる攻撃などの点数が実態とずれます。2026年9月公開のCVEでは83.3%にv3.1の値が付いていて、v2の値はVulDBが付けた913件だけです。v2の値しかない古いCVEは、NVDでv3.1の値が追加されていないか確認してください。NVDはHeartbleedのような古いCVEにもv3.1の値（7.5）を付けて、v2の値（5.0）と併記しています。v4.0との使い分けは、配布元が付けたバージョンに合わせるのが原則です。

CVSSv3はいつ公開されましたか？

v3.0は2015年6月10日にFIRSTから公開されました（IPAの概説による）。改訂版のv3.1は2019年に公開され、指標を増やさずに定義の明確化と切り上げ関数の再定義を行いました。後継のv4.0は2023年11月1日に初版が出ています。v1は2005年6月、v2は2007年6月の公開です。

CVSS 9.8と10.0は何が違うのですか？

違いはスコープです。ネットワークから認証なし・操作なしで攻撃でき、機密性・完全性・可用性すべてに高い影響がある脆弱性は、スコープ変更なしなら9.8、変更ありなら10.0です。変更ありは、脆弱性のあるコンポーネントとは別の権限の範囲に影響が及ぶことを表します。ゲストOSの脆弱性からホストOSへ、Webアプリの脆弱性から利用者のブラウザへ、といった場合です。10.0は、スコープ変更ありでなければ出ない値です。Log4Shell（CVE-2021-44228）はNVDで S:C の10.0と評価されています。

攻撃コードが公開されると現状評価のスコアは上がりますか？

Eの評価が上がり、RLとRCが変わらなければ、現状値は上がるか据え置きになります。基本値を超えることはありません。現状評価の係数E・RL・RCは最大でも1で、攻撃コードが公開されるとEはU（0.91）からP（0.94）やF（0.97）に、自動化された攻撃が出回ればH（1）に変わり、割引が小さくなるだけです。基本値9.8の脆弱性で正式な修正が出ている場合、E:Uなら現状値8.5、E:Hなら9.4です。基本値より高いスコアが出るのは、環境評価で要求度を「高」にしたり、修正版の指標を基本指標より厳しく付け直したりした場合です。

CVSSv3.1とv4.0のスコアはそのまま比べられますか？

比べられません。v4.0は指標の構成も計算方法も違う別の尺度です。F5はCVE-2026-42945にv4.0で9.2、v3.1で8.1を付けていますが、深刻度が上がったわけではありません。社内の基準でv3.1を使っているなら、v3.1の値どうしで比べてください。配布元がv4.0の値しか付けていない脆弱性は、FIRSTの4.0の計算機で評価するか、社内の基準をv4.0へ移す時期を決めてください。

関連記事

• CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化
• CVEとCWEの違いとは？脆弱性管理の基礎をCVSS・相互関係とあわせて解説
• CVE-2026-40175（axios）とは｜CVSS10.0から4.8になった経緯と確認・更新手順
• SCAPとは？セキュリティ設定共通化手順とSCAP 1.4の変更点【2026年版】
• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説