7

I found a vulnerability in a library of vendor A, I reported it, they fixed it and I received a CVE.
We noticed that some application (let's call it vendor B), contained the library of vendor A, we reported it, he updated the application with the fixed library and release it with a new version.

Should vendor B also assign a CVE to its application?
He told me that he will write in the change log of the fix, that it addresses the CVE of vendor A.
Both applications are open-source.

What is usually the process in such thing?

I thought that any program that has a vulnerability, even if they contained a vulnerable library, should assign a CVE when they fix and release a new version of their application. In such case, if the vulnerable library affects 1000 applications, should all the 1000 application report the CVE? I suppose not but I don't know.

Improve this question

2 Answers 2

Reset to default
10

From the CVE Numbering Authority (CNA) Rules:

2.1.2

2.1.2 If a CVE ID is being assigned to a vulnerability, the CNA MUST make a reasonable effort to notify the maintainer of the code in which that vulnerability exists.

For example, if an operating system vendor discovers a vulnerability in a library from an upstream supplier, in addition to assigning the CVE ID to the vulnerability, the operating system vendor should attempt to contact the upstream supplier. This will help avoid duplicate CVE ID assignments and ensure that others affected by the vulnerability will be made aware of it.

7.3

CNAs are restricted to assigning CVE IDs to vulnerabilities within their scope. Sometimes, a CNA’s scope overlaps with another CNA’s. Examples include researcher CNAs who discover the same vulnerability at the same time and maintainer CNAs whose products are dependent on the same vulnerable library. In cases like these, CNAs are expected to negotiate between themselves to determine who should assign the CVE ID. If an agreement cannot be achieved, then the issue should be escalated to the appropriate Root CNA.

So vendor B must not assign a CVE to its application.

Improve this answer
1
  • 2
    Note that the big exception to this is when assigning a CVE to the upstream library is not appropriate because the vulnerability is in the application's use of it contrary to the way it's intended to be used. For example, use of a library not specifically designed to run in a suid context in one prior to dropping privileges.
    – R.. GitHub STOP HELPING ICE
    Commented Mar 11, 2021 at 18:19
0

Benoit Esnard's answer is correct, assuming no modifications have been made to the library code in question by vendor B, or that said modifications have been applied upstream.

If this is not the case, you need to determine if the vulnerable code is within the upstream release of the library or is part of the modifications vendor B made. If the former, the CVE applies upstream only. If the latter, the CVE should be attributed to vendor B's product and not the upstream project.

Given what you've said, it doesn't appear that modifications were made, so assign to vendor A's project

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .