diff --git a/AGENTS.md b/AGENTS.md index a09b5681ec21..931d7fb42df4 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -10,5 +10,4 @@ reason to do it. ## Vulnerability reports When scanning php-src for vulnerabilities, please respect our security policy -summarized in `./SECURITY.md`. You can find the full policy -[here](https://raw.githubusercontent.com/php/policies/refs/heads/main/security-classification.rst). +described in [SECURITY.md](SECURITY.md). diff --git a/SECURITY.md b/SECURITY.md index b6337a80bdc4..6145717a27d4 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,3 +1,9 @@ +# Vulnerability Disclosure Policy + +For the sake of our users, we classify some of the issues found in PHP as +"security issues". This document explains how to report such issues, which +issues are thus classified, and how we handle them. + # Reporting Security Issues Please report security vulnerabilities on GitHub at: @@ -11,8 +17,31 @@ Vulnerability reports remain private until published. When published, you will be credited as a contributor, and your contribution will reflect the MITRE Credit System. +When creating reports, please **skip** the theatrics. Drop the impact essay, +send a short reproducer with the few lines that matter, and make each point +once. This allows us to triage and respond to your report quickly. + # Classification +We classify as security issues bugs that: + +- allow users to execute unauthorized actions +- cross security boundaries +- access data that is not intended to be accessible +- severely impact availability or performance of the system + +The purpose of this classification is to alert the users and the developers +about the bugs that need to be prioritized in their handling. + +The severity of each security issue is assessed using the [Common Vulnerability +Scoring System version 4 (CVSS v4)](https://www.first.org/cvss/v4-0/), following +its specification as closely as possible. The resulting score and vector are +published in the security advisory. Whether an issue is classified as a security +issue at all is decided by the PHP developers based on the criteria above and +the list below. + +## Not a Security Issue + Issues commonly reported that are _not_ considered security issues include (but are not limited to): @@ -27,11 +56,30 @@ are not limited to): unsanitized values, e.g. `mysqli_query()`. `escapeshellarg()` on the other hand should clearly be hardened against unsafe inputs. +- Issues that require specific actions to be performed on the server which are + not commonly performed, or are not commonly permissible for the user (uid) + executing PHP. + +- Issues that require privileges superior to those of the user (uid) executing + PHP. + +- The use of debugging facilities, e.g. Xdebug or `var_dump()`. + +- The use of settings not recommended for production, e.g. error reporting to + output. + +- The use of non-standard environment variables, e.g. `USE_ZEND_ALLOC`. + +- The use of non-standard builds, e.g. an obscure embedded platform or a + compiler that is not commonly used. + - The use of legacy APIs or settings known to be insecure, particularly those documented as such, or those with a secure alternative. - The use of FFI. +- The use of the built-in web server, which is intended for development only. + - `open_basedir` or `disable_functions` bypasses. - Malicious `unserialize()` inputs. @@ -39,11 +87,47 @@ are not limited to): - Memory exhaustion from a size the input declares, where `memory_limit` refuses the allocation and only the current request dies. -When creating reports, please **skip** the theatrics. Drop the impact essay, -send a short reproducer with the few lines that matter, and make each point -once. This allows us to triage and respond to your report quickly. +- Issues that are present only in branches without a stable release. Such + branches are per se not intended for production use. + +If your report is classified as not being a security issue, it has nothing to do +with the bug being real or its importance to you. It just means it does not fit +our specific definitions for issues that we handle in a special way. Such issues +should be reported as regular bugs in the [issue +tracker](https://github.com/php/php-src/issues), and pull requests are always +welcome. + +# Handling Security Issues + +All security issues are handled through [GitHub security +advisories](https://github.com/php/php-src/security/advisories) in the +`php/php-src` repository. Each report is triaged by the PHP security team, which +confirms whether the issue is a security issue and assesses its severity. + +Fixes for security issues are developed and reviewed in our private security +repository, and are merged into the public repository only when the release +containing them is tagged. A CVE identifier is assigned to each security issue +before the release, and the advisory is published together with the release. + +Security fixes are shipped in a scheduled release (releases usually happen on +Thursdays). The time between the report and the release depends on the +complexity of the fix and the number of issues being handled at the time, so +please be patient. Fixes are released for all [supported +versions](https://www.php.net/supported-versions.php) affected by the issue, as +described in the [Release +Process](https://github.com/php/policies/blob/main/release-process.rst). + +# Responsible Disclosure + +Please report the issue as described above and communicate with the developers +about when the fix will be released. After the fix is released, please feel free +to disclose the issue as you see fit. + +If you think an issue is a security issue but the developers disagree, please +read the classification above and try to explain to us why it fits the +description. Each bug usually has its aspects. If a short discussion does not +yield agreement, we would rather do more fixing and less arguing. -# Vulnerability Policy +# Bounties -Our full policy is described at -https://github.com/php/policies/blob/main/security-classification.rst +PHP is a volunteer project. We have no money, thus we can't pay bounties.