(No particular disagreement with the rest of your comment though)
Not really. They are very good at describing the technical impact. Sometimes pre-condition is very rare and that reduces overall likelihood but for those few it applies, the impact still could be catastrophic. Who wants to risk it if whole business could go down?
This isn't just a CVSS issue: there have been a variety of attempts to reduce a risk score down to a single general number and they all end up as somewhere between marketing material, scare tactic, and junk science.
Would you say that vulnerability with CVSS score that points to low is equally important to verify and take care of than CVSS which points to critical?
The most boring reason, even if you take CVSS scores at face value, is that in many cases it is possible to leverage multiple "low" severity vulnerabilities into a massive impact.
But the bigger reason is that CVSS scores are all over the place, and the people operating roulette wheel that generates them do not have any insight into any specific person's systems.
Many GUI CVSS calculators exist just for this, it takes a minute to requalify a vuln and adjust its CVSS based on your specific environment.
This one for example is pretty basic but works well: https://www.first.org/cvss/calculator/4.0
> These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of complementary/alternative security controls in place, Confidentiality, Integrity, and Availability. The metrics are the modified equivalent of base metrics and are assigned metric values based on the component placement in organization infrastructure.
For example, you might react differently to these scores:
- <8/10: check that your systems are indeed secure
- 8.6/10: check that your systems are indeed secure and tell your junior analyst to train on creating a custom monitoring rule for that attack and follow-up with you
- 9.8/10: double-check that your systems are indeed secure, ensure that if you had a hole another security layer would have caught it (if not, that's a problem!), set up a honeypot to get some info on the assholes that have repeatedly attacked you lately and will undoubtedly try to 0-day you in the next few hours, etc.
That is dangerously incorrect, a whole lot of themes are vulnerable. The main pre-condition, "presence of a top-level directory named 'page-xxx' like 'page-templates' in the theme's directory" is actually an official recommendation in the WordPress documentation.
See here: https://developer.wordpress.org/themes/classic-themes/templa...
> As discussed in Organizing Theme Files, WordPress can recognize page templates stored in the theme’s root folder or in a first-level subdirectory of the theme folder. *The page-templates/ folder is a common convention* for organizing global page templates, but it is not required. Page templates can also be stored in other first-level subdirectories, such as templates/ or page_templates/.
When you use a dependency and a 9+CVSS vuln comes out, you read it and respect it. If you come to the conclusion that CVSS don't mean anything because there's just so many vulns, that's saying something of the dependency and your security posture.
Burn Wordpress with a flemmenwerfer, or build a hard virtualization layer around it, give it its own scoped certs, your Wordpress things will get hacked, especially if they use plugins.