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-2019-11047  
CVE-2019-11048  
CVE-2019-11049  
CVE-2019-11050  
CVE-2019-11051  
CVE-2019-11052  
CVE-2019-11053
cve.1576484232.txt.gz · Last modified: 2019/12/16 08:17 by stas