Let's consider the following code in a hypothetical C library.

uint8_t size;
uint8_t buf[128];
read(untrusted_fd, &size, 1);
read(untrusted_fd, buf, size);

In the early 2000s, it would be a serious buffer overflow vulnerability that enables arbitrary code execution, a CVSS score would be high (definitely C:P/I:P/A:P). On the other hand, in 2020, modern kernels and compilers typically employ vulnerability mitigations such as NX, ASLR, or SSP. If an attacker only has limited access, and if an additional vulnerability (such as an infoleak) does not exist, such an exploitation can be nearly impossible in practice. If it's a product shipped in binary form, it may only receive a low CVSS score, such as C:N/I:N/A:P (i.e. vendor: nothing to see here, it's just a simple DOS attack).

But what if it's only a library in source-form? Sure, on nearly all modern systems, there are at least several mitigations in place that makes an exploitation difficult, but the caveat is: the library itself has no control over its execution environment, it's very unlikely, but still possible, that it would be deployed on systems with no mitigations. How should we correctly rate the CVSS score of a vulnerability in this situation?


The CIA scores are indications of the impact of a succesful exploitation. The CVSS is meant to rate the severity of the vulnerability, not the risk. So that it's hard to exploit is not sufficiently incorporated in the CVSS, and certainly not in the CIA scores.

So I think this vulnerability has CIA set to P at least. You can set access complexity (AC) to high (H) to indicate that it's hard to exploit.

  • These situations is exactly what AC is for.
    – forest
    Jan 13 '21 at 0:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.