What a CVSS 4.0 score of 9.2 says, and the three things it does not
Both PHP vulnerabilities today are rated CVSS v4.0 9.2. That number is a filter, not a priority: it measures the vulnerability, not your assets, your exposure, or the cost of patching.
Both PHP vulnerabilities today carry CVSS v4.0 9.2. The number will be quoted everywhere and read as “very bad”. Worth taking apart once.
Four bands, and 9.2 is in the top one
The qualitative scale has not changed from v3 to v4:
| Score | Rating |
|---|---|
| 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 sits at the bottom edge of Critical: same band as 10.0, still 0.8 short of it. That gap usually comes from a precondition — a specific configuration, a specific extension, or attack complexity that is not the lowest.
What v4.0 actually measures
Four metric groups, and only the first belongs to the vulnerability itself.
Base has two halves. One describes how you get in: attack vector (AV), attack complexity (AC), attack requirements (AT), privileges required (PR), user interaction (UI). The other describes what happens after: impact on the vulnerable system (VC/VI/VA) and on subsequent systems (SC/SI/SA).
Threat describes real-world exploitation, most often E (exploit maturity).
Environmental lets you adjust the score to your deployment: asset criticality (CR/IR/AR), modified base metrics, and safety, automatability, recovery and similar.
Supplemental does not affect the score; it annotates, e.g. response effort or provider urgency.
The last two groups are the point: the same vulnerability can legitimately score differently for you than for me. Most reposts only carry the base score.
Three things it does not say
It does not know whether you are affected. A 9.2 describes severity when the conditions hold. Whether they hold depends on version and configuration. The affected-version range in the advisory matters far more than the number.
It does not know your exposure. An authenticated-admin 9.2 and an anonymous-GET 9.2 can score similarly and mean completely different things inside your network. The reverse also holds: a “low” information leak on an internal host, next to a lateral-movement path, can become the worst finding you have.
It does not price the fix. Downtime, config changes, compatibility risk — the things that decide “patch today or next week” — are not in the model at all.
One trap: scores are not comparable across versions
CVSS v4.0 dropped the v3.1 Scope metric in favour of AT plus SC/SI/SA, and rewrote the scoring maths. The consequence: the same facts produce non-comparable numbers under v3.1 and v4.0.
So when someone says “this 9.8 beats that 9.2”, check which version produced each. Across versions even the ordering can flip.
The base score describes the vulnerability; threat and environmental metrics make it your problem.
How I use the number
As a filter, not a priority:
- Does it need anonymity to trigger? That cut alone usually removes an order of magnitude.
- Does the affected range include your version? If not, out of the queue.
- Only then sort by score within what is left.
For a team where one person owns security, this beats “fix from the top of the score list” — because the top of the list is full of “you do not have that extension installed”.
The short version
CVSS is a consensus number: it gives vendors and vulnerabilities a shared language. It was never your risk conclusion. What decides today’s order is your asset list, your exposure, and how long you can afford to be down.
Comments
…