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)
- 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 or unreachable, 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 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.
- 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.
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
- 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
- PROFIT!!!
Reserved CVEs
Allocated
Unallocated
CVE-2022-31631 CVE-2022-31632 CVE-2022-31633 CVE-2022-31634
Old reserved CVEs:
CVE-2021-21709 CVE-2021-21710 CVE-2021-21711 CVE-2021-21712 CVE-2021-21713 CVE-2021-21714 CVE-2021-21715 CVE-2021-21716 CVE-2021-21717 CVE-2021-21718 CVE-2021-21719 CVE-2021-21720 CVE-2021-21721
CVE-2020-7072 CVE-2020-7073 CVE-2020-7074 CVE-2020-7075 CVE-2020-7076 CVE-2020-7077 CVE-2020-7078