# How the PHP Project Handles Security Vulnerabilities

> How the PHP project handles vulnerabilities: reporting via GitHub or security@php.net, severity rating, fix in the release and what operators should take from it.

Source: https://phpsos.de/en/php/php-sicherheitsprozess/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**In short:** Vulnerabilities in PHP are reported confidentially, preferably through the private advisory form in the GitHub repository `php/php-src`, alternatively to security@php.net. The PHP developers rate the finding as high, medium or low; serious bugs are fixed in a separate security repository and published only with the release, together with a GitHub security advisory and usually a CVE number. With PHP2Shell, this process ran at top speed: advance notice on 20 October 2026, patches on 21 October 2026, supplementary notice on 23 October 2026.

## Who takes care of security at PHP?

PHP is an open-source project. The security policy in the wiki describes it as a volunteer project without a budget for rewards. Every version has release managers who are responsible for the releases. In addition there is the PHP Foundation, which, by its own account, commissions a team of part-time and full-time developers working on PHP's maintenance, security and new features.

For companies this means: there is no vendor with a contract, hotline or guaranteed response times. Anyone who needs binding commitments gets them from their Linux distribution, their hosting provider or a provider of long-term support, not from the PHP project itself. You should know this supply chain.

## How a vulnerability is reported

The path is described in the security policy on GitHub:

1. **Report:** through the private form for security advisories in the `php/php-src` repository. Anyone who cannot use it, or wants to discuss a topic that is not a bug report, writes to security@php.net.
2. **Describe briefly:** A short example that shows the bug is wanted, not a long report on possible impact. This lets the team triage faster.
3. **Confidentiality:** The report stays private until publication.
4. **Credit:** Reporters are credited as contributors according to MITRE's credit system.

The older wiki page additionally mentions the classic bug tracker with the type “Security”. Today the path via GitHub is the authoritative one.

## What the PHP project classifies as a security vulnerability

Not every crash is a security vulnerability. The wiki names four criteria: a bug allows unauthorised actions, crosses security boundaries, opens access to other people's data or seriously impairs availability or performance. Ratings come in three levels:

| Level | Meaning according to the policy | CVE number |
|---|---|---|
| High | Third parties can compromise most installations, execute code or read files | as a rule yes |
| Medium | similar effect, but only under rarer conditions, such as a rare extension or configuration | mostly yes |
| Low | theoretically possible, practically very hard to exploit | mostly no |

Equally informative is the list of what is expressly not a security vulnerability: malicious code that is deliberately executed, bypasses of `open_basedir` and `disable_functions`, malicious input to `unserialize()`, the use of FFI and an ordinary memory abort where `memory_limit` takes effect and only the current request ends. For operators this means: [disable_functions](https://phpsos.de/en/ratgeber/disable-functions/) is sensible hardening, but not a protective wall.

## From fix to publication

According to the wiki, fixes for high and medium vulnerabilities are integrated into a separate security repository before the release is built. Bugs rated low are handled like normal bug fixes. The vulnerability is published following the principle of responsible disclosure: first the fix, then the details. According to the wiki, releases usually appear on Thursdays, often as part of the regular monthly releases.

With the release comes a GitHub security advisory with its own identifier (GHSA) and severity. In the repository, for example, several advisories on stream wrappers, FastCGI and filters appeared on 24 September 2026, with severities from low to high. The source packages on php.net are offered with SHA-256 checksums and GPG signatures of the release managers; the Git tags are signed. Which version branches still receive security fixes at all is shown on the page on [PHP versions and the release cycle](https://phpsos.de/en/php/release-zyklus/).

## PHP2Shell as an example of an emergency

PHP2Shell shows how the process runs under pressure:

- **20 October 2026:** php.net announces a critical security release for 21 October 2026 at 14:00 UTC and reserves the right to publish earlier if details become public or attacks appear. According to several reports, details had in fact become known before the embargo expired; the background is examined in [Why the PHP vulnerability became known before the patch](https://phpsos.de/en/blog/php-luecke-vorzeitig-bekannt/).
- **21 October 2026:** PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released, along with the advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), both rated critical. According to php.net, Linux distributions and providers of long-term support had received the fixes in advance. For 7.4, 8.0 and 8.1 there are minimal backports.
- **23 October 2026:** An informational notice on CVE-2026-115560 recommends `session.upload_progress.enabled=0`; the full advisory follows with the next release.

## What operators should take from this

1. **Subscribe to sources:** php.net, the GitHub advisories of `php/php-src` and the security announcements of your distribution.
2. **Know the supply chain:** Who supplies your PHP package, and how quickly do backports arrive there?
3. **Plan the time window:** Critical releases can come outside the usual rhythm; a patch window must be possible at short notice.
4. **Plan the restart:** An update takes effect only when all PHP processes have been restarted.
5. **Secure the evidence:** Document the version, package state and time.

## How does PHP SOS help?

With the [PHP patch service](https://phpsos.de/en/leistungen/php-patch-service/), we take over the part that lies with you:

- **Follow announcements:** We monitor php.net, the advisories and the distributions' announcements and assess whether your systems are affected.
- **Carry out the patch:** Update from the appropriate source, restart of all processes, check of the running version.
- **Secure the interim period:** Where the update is stuck, we implement the official interim measures.
- **Document:** You receive evidence with versions, package states and times.


## Frequently asked questions

**How do you report a security vulnerability in PHP?**  
Preferably through the private security advisory reporting form in the GitHub repository php/php-src. Anyone who cannot use that writes to security@php.net. The report remains confidential until publication.

**Does the PHP project pay a reward for vulnerabilities found?**  
No. According to the security policy, PHP is a volunteer project without money for bug bounties. Reporters are credited as contributors, though.

**Is a bypass of disable_functions a security vulnerability?**  
Not according to the PHP project's policy. Bypasses of open_basedir and disable_functions are not regarded as a security problem of PHP. The settings are hardening but not a reliable security boundary.

**Where do I learn about new PHP vulnerabilities?**  
On the php.net home page with the release announcements and in the security advisories of the php/php-src GitHub repository. Anyone who obtains PHP from a distribution should also follow its security announcements.

**Why was PHP2Shell published on a Wednesday?**  
According to the wiki, releases usually appear on Thursdays. For PHP2Shell, php.net announced on 20 October 2026 a security release for Wednesday, 21 October 2026, 14:00 UTC and reserved the right to publish earlier if details became public.

## Sources

- [php-src: Security policy and advisories (GitHub)](https://github.com/php/php-src/security)
- [PHP Wiki: Security policy](https://wiki.php.net/security)
- [php.net: Announcements of 20 to 23 October 2026](https://www.php.net/)
- [php.net: Supported versions](https://www.php.net/supported-versions.php)