cve

This is an old revision of the document!


This document describes how CVEs are issued for vulnerabilities in PHP code.

For bug reporters

CVE numbers will be assigned to security issues by PHP developers. Please do not request CVEs for PHP issues independently, this would create confusion. If you need a CVE number for a certain issue before the fix is released and CVE is published, please contact security@php.net with explanation and bug number and the number will be allocated if necessary.

For PHP developers

The following is the procedure for issuing CVE to a vulnerability. If you do not have access to security issues, please ask somebody who does to follow this procedure (asking on security@php.net is a good way to start)

  1. If there's no bug on bugs.php.net for the issue, create one. Use type “Security” for it.
  2. Read the issues and ensure the vulnerability needs a CVE. Refer to https://wiki.php.net/security for guidance. The rules of thumb are:
    • What usually needs a CVE: an issue where remote user gets to read what is not supposed to be read, write what is not supposed to be written, crash what is not supp... you get the idea.
    • What usually does not need a CVE: configuration issues, security enhancements not linked to a specific vulnerability, issues requiring code execution access, issues triggered by code/configuration known to be insecure or unreachable, issues in non-release versions (e.g. master), third-party library issues (may be still issued CVE, but not by us).
  3. Take first item from the list of unallocated IDs below, and move it to the list of allocated IDs together with the bug ID
  4. If there's no unallocated IDs left, use “needed” in CVE field of the bug and notify security@php.net that new CVE number allocation is needed. We'll be watching the number of available ones and allocate more on need, but if certain release's bug harvest is particularly bountiful, they may run out quicker then expected.
  5. Edit the bug and add CVE id to the issue
  6. Once the bug is fixed, add the CVE number selected to the bug fix to the release notes (NEWS).
  7. Submit bug description to CVE list as described below

Submitting CVE data to MITRE

The following procedure is for making CVE report for MITRE database.

Preparation

Fork and clone repo in https://github.com/CVEProject/cvelist. Do not forget to update your fork from master each time new set of bugs is submitted. It is recommended to submit all issues for the release together.

For each issue

  1. Create JSON file describing the issue. https://vulnogram.github.io/ is a good tool for this.
  2. Add the resulting file with the name CVE-YEAR-NNNN.json into directory YEAR/NNxxx/ - e.g. CVE-2019-11035 goes to 2019/11xxx/CVE-2019-11035.json. Note there can already be a “reserved” file there, overwrite it (ensure it was empty before, mistakes happen)
  3. Create a commit with new issues in a separate branch
  4. Push it to your fork
  5. Create a pull request for upstream repository on github
  6. Wait for cvelist team to approve it
  7. PROFIT!!!

Reserved CVEs

Allocated

Unallocated

CVE-2020-7059 	
CVE-2020-7060 	
CVE-2020-7061 	
CVE-2020-7062 	
CVE-2020-7063 	
CVE-2020-7064 	
CVE-2020-7065 	
CVE-2020-7066 	
CVE-2020-7067 	
CVE-2020-7068 	
CVE-2020-7069 	
CVE-2020-7070 	
CVE-2020-7071 	
CVE-2020-7072 	
CVE-2020-7073 	
CVE-2020-7074 	
CVE-2020-7075 	
CVE-2020-7076 	
CVE-2020-7077 	
CVE-2020-7078
cve.1579121971.txt.gz · Last modified: 2020/01/15 20:59 by stas