undefined

points

[-]

Imagine a YAML parsing library that can cause an out-of-memory exception if you give it a YAML file greater than 3 megabytes.

If you're an online service where untrusted users can submit arbitrary YAML, and an out-of-memory exception is a severe problem, then it's severity 10.

If you're an online service that doesn't use yaml in any way, but your web framework bundled the library as a transitive dependency because yaml is one of their five supported configuration options, then it's severity 2.

The problem is figuring out which of those situations you're in takes a load of time - and the flow of CVEs is endless, as CVE numbers are given out like candy at halloween. Often it's quicker to just update to the latest version of the YAML library.

by pixl973 hours ago|

parent|

[-]

Exactly, the amount of time it takes to figure out if you're exploitable generally exceeds the time to patch the application in the majority of the cases. You tend to try to focus on the ones that will cause the most interruption.

And then you can have all kind of other fun things, like users don't upload YAML so you think you're safe, but a clever hacker figures out another minor parser error that makes your JSON seem like YAML and suddenly YAML.so has loaded and you're now parsing a document that shouldn't be possible.

by lucideer2 hours ago|

prev|

[-]

I could reword that CVSS is useless on its own - EPSS takes CVSS as an input afterall. The point here is that applying environmental scoring is the hard part. That's the algorithm that's containing the complexity.

by mr_mitm1 hours ago|

parent|

[-]

True, I guess you might as well evaluate each vulnerability yourself without the CVSS base score.