CVE assignment without upstream knowledge

In the past few months I’ve been dealing with aligning PHP CVE information to enable easier tracking of security fixes. The two main locations are the NEWS file which is part of each release and the changelog available on the website which is more popular (and easier to update).

Usually the CVE are assigned per PHP.net security team request or with cooperation with one of the Linux distribution’s teams (either PHP or security), as should be in a good ecosystem.

Recently I got a few notifications issued by Debian about its PHP package, which I wasn’t familiar with these CVE IDS. When checking this, I found out a few CVE assigned per 3rd party (Linux distribution, bug reporter, etc…) request without upstream knowledge. Digging deeper I found out that some CVE were assigned a month after the fixes were released, while others were only a week or two after. While this makes sure the security information is documented, it’s harder to add the information after tagging and releasing.

In another case, while discussing about a CVE for a specific bug, we found out one was already assigned per the reporter’s request but without the our or the upstream library knowledge. Even if the issue isn’t severe, upstream should get a fair chance to fix issue before making them public. Which also leads to a problem with requesting CVE IDs on a public mailing list which in some cases leads to security information leakage. We should balance transparency with some grace period for upstreams (as projects share code).