Switch to CVSS scoring

+1

v4 is the current version - so e.g. https://nvd.nist.gov/vuln-metrics/cvss/v4-calculator

I had a look at scoring a Drupal SA recently and it seems we'll have to get used to some new concepts if we're going to use v4 such as "Vulnerable System Impact" vs "Subsequent System Impact".

There are comprehensive docs:

https://www.first.org/cvss/user-guide#Assessment-Guide

I think perhaps we should aim to start doing a CVSS (v4) score in parallel to the existing system for a while, with the aim of switching over as soon as practical.

An overlap seems fine, but I'd also be fine if we just did as a "big bang migration" it if that helps get it done faster.

+1 on switching as well.

This would also help the CVE process as it is preferred CVE’s be scored with CVSS (although they can be scored with a priority metric it is just not preferred).

As well as documentation there is also an entry level training course https://learn.first.org/catalog/info/id:126,cms_featured_course:1

I was intending to circle back after the last contrib SA I worked on and post an example score:

SA-CONTRIB-2024-043: TFA: Session Fixation:

Under Drupal’s scoring system this scored Critical 15 ∕ 25 AC:Complex/A:None/CI:Some/II:Some/E:Theoretical/TD:All

Cross scoring to CVSS:4.0 the score would be closer to Low: 2.1 CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N/AU:N/R:U/V:D/RE:L/U:Clear

This is an extream example, and I’ve seen some SA’s become higher under the CVSS, however in all cases CVSS told a more complete story.

Partly a note-to-self: the current risk calc system lives in the drupalorg project e.g.

https://git.drupalcode.org/project/drupalorg/-/blob/ab295c10770375254eef...

There would likely need to be changes in other places if we were to switch to a new system.

The CVSS 4.0 questions are extremely vague and confusing, it would be helpful to document each of the questions and provide recommendations on how to fill it in for common scenarios.

One nice thing about broader standards is there's plenty of docs we don't have to write, e.g. https://www.first.org/cvss/v4-0/user-guide

The security team has discussed a plan that for a few weeks we publish a CVSSv4 score alongside the usual risk score in all SAs.

We can label this as experimental, and perhaps link back to this issue.

The idea of doing this for a relatively short period is to minimise the extra work of doing two risk scores in parallel, but give everyone a chance to try using CVSSv4 before we actually switch over.

Anecdotally, a lot of organisations are still using CVSSv3.1 because 4 introduces some good additional features but along with that comes increased complexity.

https://www.first.org/cvss/calculator/4-0

I'd suggest that we only complete the first section of the v4 calculator initially. That should give us a score that looks like:

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

CVSS v4.0 Score: 7.1 / High

We could also provide a link to the calculator with the values pre-filled e.g.

https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:L/U...

Once we've done a couple of these in SAs we can put a template here for the markup.

Drumm pointed out it would be nice to only have one kind of data in the field.

Can we automatically migrate old Drupal scores to CVSS in some way? Anyone interested in this feature could work on that and it would be very helpful.

I'd suggest that we only complete the first section of the v4 calculator initially.

You may want to consider the “Provider Urgency” value from the supplemental metrics as it can be used by projects to signify “how much do we think you really need to worry about this”. An extra signifier for “yes this is technically a vulnerability, the odds of it causing you a problem are almost nil however we have to disclose it” (clear) vs “This is the new drupelgeddon, patch now” (red).

https://mcdruid.gitlab.io/drupal-sa-cvss-map

This is a quickly prototyped (with Claude) app to experiment with mapping the legacy NISTIR 7864 risk scores that Drupal uses today to CVSS for all historical SAs.

It links to the PHP class that does the actual mapping up in the top right (currently https://gitlab.com/mcdruid/drupal-sa-cvss-map/-/blob/main/src/Mapper/Dru... ).

There are tooltips (/ contextual info) to explain the different metrics / components of the risk scores.

One quirk is that I'm applying nudges for different vulnerability types (e.g. XSS always requires User Interaction but that can't be read from the current risk calc values) - that's shown in the table as "mapping notes" if you hover over the CVSS score (separate link on devices where hover is not a thing).

The idea of doing it like this is that we can make tweaks to the mapping and observe the impact across lots of SAs at once, although it's a bit cumbersome that I have to commit the changes; I'm not aware of a way we could present a front-end like this based on d.o's gitlab pipelines.

Hopefully we can use the mapping class (or something based on the logic) to update all SAs with a CVSS score, and switch to using CVSS from then on.

If certain SAs get a mapped score that's not quite right, I imagine that we could tweak those manually after the migration has run. The aim would be to get the mapping close enough that most SAs would get an appropriate score automatically.

We could perhaps have the migration append the legacy risk calc as text to the end of each SA for posterity.

I've gone with CVSSv3.1 as a path of least resistance to try to get this done.

Feedback welcome - particularly on the mapping logic, with the aim of getting it to the point where we can run it on historical SAs.

We could perhaps have the migration append the legacy risk calc as text to the end of each SA for posterity.

Would be best if these olds scores are not destroyed, if they remain available through (unauthenticated) revision history that may be sufficient, however I would encourage they be easily accessible. Appending to the bottom of the SA seems most appropriate.

 * Factor mapping:
 *   AC:None    → AC:L, UI:N
 *   AC:Basic   → AC:L, UI:R  (user must follow a path = user interaction)
 *   AC:Complex → AC:H, UI:R

I'm concerned how well this holds up for the UI condition.

This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner. 

I'm mostly thinking the recent OTP related vulnerabilities, access bypasses where routes do not validate a Token. Several of them did require a user have a token configured (or to be configured to require a token), at some time in the past, however the user wasn't required as part of the attack itself. Is having configured something years prior still UI:R ?

Disclosure: the Enterprise MFA flaws mentioned below also occurred in the TFA module which I am a co-maintainer of, I am reference the Enterprise MFA SA's as they did better in separating out the flaws into separate concise targeted public disclosures.

https://www.drupal.org/node/3523194 for example with AC:complex.

"This vulnerability is mitigated by the fact that an attacker must have access to the password reset link." that is most likely presumed to be triggered by the end user requesting the link and it being exposed, however an attacker can request links as well (MITM attack on email, perhaps a contrib module has its own bug that exposes one time login links, etc). This isn't easy to get (hence complex) however it s far from requiring the user to perform an action.

https://www.drupal.org/node/3532428 an attacker only needs username/password to exploit (if they have a token policy configured, otherwise the module and exploit is moot as your not actually bypassing any protections).

https://www.drupal.org/sa-core-2023-005 and https://www.drupal.org/node/3404970: These too do not require another user to be involved in the attack, yet they were given AC:Basic.

Going to one of my modules: https://www.drupal.org/node/3312377
That attack requires that a certain configuration layout (chosen by an administrator), in CVSS 4.0 we would likely file this under Attack Requirements (AT), It does require an attacker scout the environment a bit (determine the paths they need to access).

Arguably some of this might be less than ideal current scoring, I do know from time to time I'm on the fence which level to score under the D.O. calculator. Sometimes I will score higher (less complex) where a DST member will come back and correct me to lower (more complex) and vice versa.

Most of these I've noted I believe have higher complexity levels due to how unlikely they are to be exploited (or dependent upon server config which should have been solely in the TD metric IMO) and not related to second user interaction during the exploit cycle.

Thanks for the feedback @cmlara

Definitely see your point that Access Complexity: Basic or Complex mapping to AC:L, UI:R meaning "a victim must take some action" won't always fit.

Hopefully not stating the obvious too much, but for the existing risk calc there are only so many variables to tweak so there's almost always some degree of fudging the exact scores to achieve a "best fit".

CVSS has a richer palette which can hopefully capture some more of the nuance.. although there will be cases where it's not obvious how to fit a specific situation into the "right boxes".

The additional guidance available in terms of explaining what each value for the different metrics means, and the examples provided is one of the benefits I think we're all looking forward to; I really like the detailed contextual help for each option at https://www.first.org/cvss/calculator/3.1 for example.

In terms of an automated migration, it's definitely a challenge. I suppose it's a bit like trying to resize an image that's been highly compressed in that there are only so many bits of information we can go on in the source material.

I expect there will definitely be some SAs that we might want to review and manually tweak the CVSS score the migration came up with.

In the specific case of the Access Bypass examples you provided, do you think it would improve the mapping to have a special case where we do not bump UI to R for "Basic" (or something along those lines)?

Happy to add that to the "Vulnerability-type overrides" and see if we can get Access Bypass SAs coming out with better mappings.

I’ve only made it to August 2025 on the Contrib advisory list.

Vast majority being XSS and Access Bypass.

I see XSS/CSRF is already bumped to UI:R.

Access Bypass: I do not belive I saw a single one that would be UI:R, binding them all to UI:N may work.

The sample size so far is not great, I did see a few other vulnerabilities that I would question UI on that were not Access Bypass.

https://www.drupal.org/sa-contrib-2025-126 information disclosure. Not clear if it requires UI (I think not, as in theory it could possibly leak internal CMS data too based on its actions).

https://www.drupal.org/sa-contrib-2025-112 another information disclosure

https://www.drupal.org/sa-contrib-2025-068 denial of service.

I’m wondering if it makes more sense to just always assume UI:N and only bump on XSS/CSRF and possibly Open Redirect.

There could be more advisories latter in the list I have not yet seen that would conflict with that.

Looking at core:
The Gadget chains do not appear to be UI:R.

https://www.drupal.org/sa-core-2025-008 Would automated systems (timed expired of roles) count as UI? (I could see this UI:N or UI:R).

https://www.drupal.org/sa-core-2025-007 defacement does indeed appear to be UI:R which would break my proposal above.

https://www.drupal.org/sa-core-2024-002 doesn’t appear to be UI:R

I suppose best solution is choose whatever has the least issues needing manual adjustment and catch the obvious errors in a manual review before conversion.

I think the suggestion to not change UI based on Access Complexity by default is a good one.

We will continue to set UI:R for XSS and CSRF, and I've added the same for Open Redirect.

The Defacement SA is a bit of a one-off. It should probably be treated the same as a (reflected) XSS but I'm not going to fiddle with the mapping just for that one.

Changes pushed to https://mcdruid.gitlab.io/drupal-sa-cvss-map/

Thanks again for the useful feedback.