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 email@example.com 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 firstname.lastname@example.org is a good way to start)
- If there's no bug on bugs.php.net for the issue, create one. Use type “Security” for it.
- 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, issues in non-release versions (e.g. master), third-party library issues (may be still issued CVE but not by us)
- Take first item from the list of unallocated IDs below, and move it to the list of allocated IDs together with the bug ID
- If there's no unallocated IDs left, use “needed” in CVE field of the bug and notify email@example.com that newCVE 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.
- Edit the bug and add CVE id to the issue
- Once the bug is fixed, add the CVE number selected to the bug fix to the release notes (NEWS).
- 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.
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
- Create JSON file describing the issue. https://vulnogram.github.io/ is a good tool for this.
- 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)
- Create a commit with new issues in a separate branch
- Push it to your fork
- Create a pull request for upstream repository on github
- Wait for cvelist team to approve it
CVE-2019-11036 CVE-2019-11037 CVE-2019-11038 CVE-2019-11039 CVE-2019-11040 CVE-2019-11041 CVE-2019-11042 CVE-2019-11043 CVE-2019-11044 CVE-2019-11045 CVE-2019-11046 CVE-2019-11047 CVE-2019-11048 CVE-2019-11049 CVE-2019-11050 CVE-2019-11051 CVE-2019-11052 CVE-2019-11053