CVSS 4.0 的 9.2 分在说什么，以及它没说三件事
今天 PHP 那两个漏洞都是 CVSS v4.0 9.2。这个分数是筛选器，不是优先级——它衡量漏洞本身的严重性，不衡量你的资产、你的暴露面，也不衡量修它要停多久业务。
今天 PHP 的两个漏洞都被评为 CVSS v4.0 9.2。这个数字会被大量转发，然后变成“很严重”的同义词。但它到底在说什么，值得拆开看一次。
分数只有四档，9.2 在最上面一档
CVSS 的定性分档从 v3 到 v4 没变：
| 分数 | 等级 |
|---|---|
| 0.0 | None |
| 0.1 – 3.9 | Low |
| 4.0 – 6.9 | Medium |
| 7.0 – 8.9 | High |
| 9.0 – 10.0 | Critical |
9.2 落在 Critical 的下沿。也就是说：它和 10.0 是同一档，但离满分还差 0.8。 这个差距通常来自“需要某个前置条件”——比如特定配置、特定扩展，或者攻击复杂度不是最低。
v4.0 算的是哪些东西
v4.0 的评分由四组指标构成，只有第一组是漏洞自带的：
基础组（Base） 分两半。一半描述怎么打进去：攻击途径（AV）、攻击复杂度（AC）、攻击前置要求（AT）、所需权限（PR）、是否需要用户交互（UI）。另一半描述打进去之后的影响，而且分成两套：对被攻击系统的机密性/完整性/可用性（VC/VI/VA），以及对下游系统的影响（SC/SI/SA）。
威胁组（Threat） 描述现实世界的利用状态，最常用的是 E（Exploit Maturity，利用成熟度）。
环境组（Environmental） 让你按自己的部署改分：资产重要性（CR/IR/AR）、修改后的基础指标、以及安全影响（S）、可自动化程度（AU）、恢复代价（R）等。
补充组（Supplemental） 不进分数，只做说明，比如漏洞响应成本、厂商紧迫度。
关键在最后两组：同一漏洞，在你和在我这里的“应得分”可以不一样。 只是绝大多数转发只带基础分。
它没说三件事
第一，它不知道你受不受影响。 9.2 描述的是一个漏洞在“条件成立”时有多严重，条件是否成立要看版本和配置。公告里的“受影响版本范围”比分数重要得多。
第二，它不知道你的暴露面。 一个需要已认证管理员才能触发的 9.2，和一个匿名 GET 就能打的 9.2，分数可能接近，但在你的网络里完全不是一回事。反过来也一样：内网里一个“低危”的信息泄露，配上一个横向移动的跳板，能变成最要命的那条。
第三，它不衡量修复代价。 升级要停多久、要不要改配置、有没有兼容性问题——这些决定“今天修还是下周修”的因素，CVSS 一个都不管。
还有一个容易踩的坑：不能跨版本比较
CVSS v4.0 去掉了 v3.1 里的 Scope 指标，换成 AT 与 SC/SI/SA 的组合；评分算法也重写了。结果是同一组事实，在 v3.1 和 v4.0 下算出来的数字不可比。
所以看到“这个 9.8 比那个 9.2 更严重”的时候，先确认两个分数是不是同一个版本算的。不同版本之间，连排序都可能反过来。
基础分只描述漏洞；威胁组和环境组才把它变成“我的问题有多大”。
我会怎么用这个分数
把 CVSS 当筛选器，不当优先级：
- 先按“能不能被匿名触发”过一遍。这一刀切下去，剩下的量通常少一个数量级；
- 再看受影响版本，不匹配的直接出队；
- 最后才看分数，用它给同一批里的条目排序。
如果你的团队只有一个人管安全，这套顺序比“按分数从高到低修”有效得多——因为高分里混着大量“你没装那个扩展”的情况。
一句判断
CVSS 是一个共识数字：它让不同厂商、不同漏洞之间有了可比的语言。但它从来不是你的风险结论。真正决定今天先修哪个的，是你的资产清单、你的暴露面，和你能承受多长的停机。
评论
…