CVSSは、脆弱性の技術的な深刻度を0〜10で表す共通の評価方法です。 数値が高いものほど注意が必要ですが、更新する順番は、自社で使っているか、攻撃が届くか、どの業務に影響するかまで確認して決めます。
「9.2なら被害に遭う確率が92%」という意味ではありません。ニュースの点数をそのまま対応期限へ置き換えると、実際に悪用されている別の問題を後回しにしかねません。
本記事はFIRSTの仕様書、IPAの概説、JVNの告知とPHP公式アドバイザリを確認して作成しました。（調査時点：2026年10月23日）
CVSSのスコアは何を表すのか
CVSSはCommon Vulnerability Scoring Systemの略で、日本語では共通脆弱性評価システムと呼ばれます。IPAの概説は、ベンダーや管理者が共通の基準で深刻度を議論するための評価方法と説明しています。脆弱性を特定するCVE番号と、深刻度を評価するCVSSは役割が異なります。
| スコア | 区分 | 日本語の目安 |
|---|---|---|
| 0.0 | None | なし |
| 0.1〜3.9 | Low | 低 |
| 4.0〜6.9 | Medium | 中 |
| 7.0〜8.9 | High | 高 |
| 9.0〜10.0 | Critical | 緊急 |
出典：FIRST v4.0仕様書の深刻度区分。v3.1も同じ区分ですが、評価項目と算出方法は異なります。「緊急」は深刻度の区分であり、全企業に共通の修正期限を定めるものではありません。
数値だけでは条件が分かりません。報告書では、CVE番号、評価元、CVSSの版、スコア、ベクター、確認日を一緒に残します。ベクターはAV:Nなどの短い記号で評価条件を並べた文字列です。評価が食い違うときも、点数の平均を取らず、条件の違いを確認できます。
v3.1とv4.0は何が変わったか
v3.1には基本・現状・環境の3グループがあり、v4.0では基本・脅威・環境・補助の4グループになりました。次は、読むときに押さえたい変更です。
| 見る項目 | v3.1 | v4.0 |
|---|---|---|
| 攻撃が成立する条件 | ACで攻撃条件の複雑さを評価 | ACに加え、配置・実行上の条件をATで評価 |
| ユーザーの関与 | 不要／必要 | 不要／受動的／能動的に分ける |
| 影響範囲 | Scopeと機密性・完全性・可用性で評価 | 脆弱なシステムと後続システムの影響を別々に評価 |
| 時間で変わる要素 | 現状評価に攻撃コード・修正状況・情報の信頼性 | 脅威評価を悪用の成熟度に整理 |
| 補助情報 | 独立グループなし | 自動化の可否や復旧など。スコア自体には加算しない |
出典：FIRST v3.1仕様書、v4.0ユーザーガイドの変更点。版が違う点数を並べて「危険性が下がった」と判断しないようにします。
JVNは2025年4月21日からv4による評価を開始し、v3も併記しています。複数の点数を見かけたら、まず版の表示を確かめてください。
図のうち、基本（Base）は脆弱性そのものの性質、脅威（Threat）は攻撃コードや悪用状況、環境（Environmental）は自社の構成や守る情報の重要度を扱います。右端の補助（Supplemental）は判断材料を増やすための情報です。
v4.0の表記では、基本評価がCVSS-B、脅威を加味するとCVSS-BT、環境を加味するとCVSS-BE、両方ならCVSS-BTEです。未指定の脅威・環境項目には既定値が使われます。Bだけの数値を、自社環境まで調べた評価として報告しないことが大切です。
php2shellの「9.2」をベクターから読む
PHP開発元の公式アドバイザリでは、CVE-2026-109618とCVE-2026-109619はいずれも**CVSS v4.0、CVSS-B 9.2（Critical）**です。両方に次のベクターが記載されています。
出典：PHP公式：CVE-2026-109618、PHP公式：CVE-2026-109619（2026年10月23日確認）。この数値は当社の独自採点ではありません。
| 表記 | 読み取れること |
|---|---|
| AV:N | ネットワーク経由で攻撃可能 |
| AC:H / AT:P | 攻撃の複雑さは高く、成立に配置・実行上の条件がある |
| PR:N / UI:N | 攻撃前の権限も、利用者の操作も不要 |
| VC:H / VI:H / VA:H | 脆弱なシステムの情報漏洩・改ざん・停止への影響が大きい |
| SC:N / SI:N / SA:N | この基本評価では後続システムへの影響をNoneとしている |
AC:Hだから対応を急がなくてよい、とは読めません。PHP公式は認証なしのリモートコード実行を確認しており、成立条件と成功時の影響を合わせて9.2と評価しています。また、後続システムの評価がNoneでも、自社の接続先や権限の確認は必要です。
自社が該当するかはphp2shellの影響範囲と対応、修正を適用した後の確認はパッチの内容と確認ポイントを参照してください。スコアを読む作業と、対象環境へ修正を反映する作業をつなげます。
対応する順番は自社の条件で決める
FIRSTのFAQも、基本スコアだけをパッチの優先順位に使わないよう説明しています。現場では次の問いに答えると、担当者が判断の根拠を共有できます。
対象を照合する
製品・実行バージョン・有効な機能を確認し、影響対象の資産と管理者を特定します。
攻撃が届くか確認する
インターネット公開、認証、内部ネットワークからの経路を調べます。到達性が不明なら調査担当を決めます。
悪用と業務影響を確認する
開発元の告知と悪用情報を読み、顧客データ・決済・業務停止への影響を整理します。
対応と期限を決める
更新または一時対策を選び、担当者・期限・再確認日・本番での完了条件を記録します。
たとえば、公開中の顧客向けシステムで悪用が確認され、管理権限に届く脆弱性と、到達経路を制限した検証環境の脆弱性では、同じ基本スコアでも対応の順番は変わります。これは判断の例であり、wrenの顧客事例ではありません。内部向けという理由だけで対象外にはせず、侵入後の横展開や設定変更も考慮します。
攻撃コードの公開と、実際の悪用確認は分けて記録します。CISAのKEVカタログは悪用が確認された脆弱性を調べる資料ですが、未掲載でも安全の証明にはなりません。侵害の兆候がある場合は、更新だけで完了せず、情報漏洩時の初動と原因調査へ進みます。
すぐ更新できないときは、提供元が示す一時対策の適用可否と影響を確認し、残るリスクと再確認日を残します。WAFの導入や公開制限だけで恒久対応が済んだとは扱いません。修正版が提供されない古い環境は、PHPのサポート期限とバージョンアップも判断材料になります。
更新の優先順位や担当範囲を整理する支援は、wrenのSRE顧問で案内しています。相談時は、対象のシステムと分かっている影響を受託開発の相談フォームから共有できます。
更新を完了とする条件まで記録する
チケットには、CVEと評価元へのリンク、対象資産、判断理由、担当者、期限を残します。完了条件には「更新PRを作成」ではなく、本番で動くバージョンの確認、主要機能の動作、監視結果を含めます。未対応を受け入れる場合も、承認者と見直す条件が必要です。
wrenの自社サイトでは、依存関係のlockfileをリポジトリで管理し、記事の追加時にもLint・記事規約チェック・本番ビルドを実行する構成になっています。これは当サイトの実装について確認できる事実です。すべての脆弱性への即日対応や、顧客環境の安全性を保証するものではありません。
継続する運用項目はWebサービスのセキュリティ対策チェックリストに整理しています。CVSSを確認した後に、対象の把握と本番反映まで追える記録を残しておくと、次の脆弱性が公表されたときにも判断を引き継げます。