# Why the PHP Vulnerability Became Known Before the Patch

> Why the PHP vulnerability became known before the patch: how embargoes work, what happened on 20 October and what operators can learn for patching.

Source: https://phpsos.de/en/blog/php-luecke-vorzeitig-bekannt/  
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:** The PHP vulnerability became known early because, according to several reports, details became public before the agreed embargo expired, among other things through a forum post on 20 October 2026. php.net then announced the security release for 21 October at 14:00 UTC. As a result, operators had hardly any time to prepare. The lesson: a patch process has to work even without advance warning.

## The trigger: an announcement with only a few hours' notice

Normally, administrators learn of a critical vulnerability at the moment the update is also available. With PHP2Shell it was different. On 20 October 2026, php.net published an advance announcement: a critical security release the following day at 14:00 UTC, that is, 4 p.m. German time, for two vulnerabilities rated CVSS v4.0 9.2.

One sentence in the announcement was unusual. The PHP team reserved the right to release earlier if details of one of the vulnerabilities became public or if signs of active exploitation appeared. According to several reports, including from SOC Prime and BleepingComputer, that was exactly the background: information was already in circulation before the planned date.

## How coordinated disclosure normally works

Behind large security updates there is usually a process that specialists call "coordinated disclosure". In simplified terms, it works like this:

1. **Report:** Researchers find a vulnerability and report it confidentially to the project.
2. **Analysis and fix:** The project reviews the report, develops a fix and assigns CVE numbers.
3. **Advance notice:** Selected partners, such as Linux distributions, receive the fix under embargo so that their packages are ready on the due date.
4. **Release:** On a fixed date, the patch, the security announcement and the packages appear at the same time.

The embargo is an agreement to withhold details until that date. It is meant to prevent attackers from getting a head start while no update exists yet. How the PHP project handles security announcements in general is explained in the article on the [PHP security process](https://phpsos.de/en/php/php-sicherheitsprozess/).

## How the PHP vulnerability became known early: 20 October

According to consistent media reports, the CVE numbers appeared in a public forum post on 20 October, together with the claim that both vulnerabilities were rated with the maximum score of 10.0. According to reports, the post was later deleted. The PHP team confirmed the vulnerabilities but gave the rating as 9.2 and the release date as 21 October.

In the following hours, screenshots and a video that were supposed to show an attack reportedly circulated. The security company watchTowr said it had reproduced CVE-2026-109618. Cloudflare, by its own account, had had its own protection rules active since the early morning of 21 October.

Independently of the leak, media reports citing Amazon describe a first observed attack attempt on 17 October. Whether this is connected with the later leak has not been publicly established. The full sequence of dates is shown in the [PHP2Shell timeline](https://phpsos.de/en/ratgeber/php2shell-chronologie/).

## What early disclosure changes for operators

For companies, the leak had three practical consequences:

- **Less lead time:** There was roughly one day between the advance announcement and the patch. Anyone who only reacted after the release had no time to coordinate maintenance windows.
- **Unclear information:** In the first hours, rumours stood alongside official statements. The incorrect rating of 10.0 persisted for days.
- **Earlier starting point for attackers:** Anyone who knows the details early can start searching early. Automated scans for vulnerable servers, in experience, begin quickly, as the article on [mass scans for unpatched PHP](https://phpsos.de/en/blog/automatisierte-massenscans/) describes.

At the same time, the advance announcement showed that the process worked despite the leak: the updates for all supported branches appeared on the announced date, and distributions in some cases shipped backports the same day.

### Why a project does not simply release immediately

One might ask why the PHP team did not release everything immediately after the leak. The answer lies in the trade-off every project faces in this situation. A release without finished distribution packages only helps those who build PHP from source themselves. The vast majority of servers, however, get PHP through Debian, Ubuntu, Red Hat, hosting providers or container images. A date that was too early would therefore have made details public without most operators being able to install anything yet.

The advance announcement with a fixed date and the reservation to release earlier if necessary was a middle path. Operators could prepare, and distributions could finish their packages. For you as an operator, this means that such an advance announcement is a signal to schedule staff and maintenance windows immediately, not only on the day of the patch.

> **Tip:**
> Subscribe directly to the security announcements from php.net and your distribution, for example by RSS or mailing list. An advance announcement is only useful if someone in the company reads it.

## What to take away for your patch process

Whether a vulnerability becomes known as planned or early is not in your hands. How quickly you can act afterwards is. These points proved decisive with PHP2Shell:

| Building block | Question that should be answered beforehand |
|---|---|
| Inventory | Which servers and websites use PHP, in which version and operating mode? |
| Responsibility | Who patches: your own IT, a service provider or the host? Who decides on a shutdown? |
| Update path | Does PHP come from the distribution, a third-party repository or a container image? |
| Restart | How are all PHP processes reliably restarted? |
| Proof | How is the patch level documented if the version number stays the same? |
| Emergency operation | Is there an emergency page in case a server has to go offline temporarily? |

Anyone who has already answered these questions only needs the date for the next advance announcement. What such a process looks like in the long term is described in the article on the [patch management process](https://phpsos.de/en/blog/patch-management-prozess/).

## How does PHP SOS help?

- **Quick inventory:** We record all PHP systems with version, operating mode and the source of the packages.
- **Patch on the due date:** We install updates, restart all PHP processes and document the status per server.
- **Bridging a delay:** Where an update is not possible immediately, we apply the interim measures from php.net and clarify a temporary shutdown with you.
- **Preparation for next time:** Together with you, we define responsibilities, reporting channels and emergency operation.

You can find details of the process under [PHP patch service](https://phpsos.de/en/leistungen/php-patch-service/).

## Conclusion

The early disclosure of PHP2Shell was not a failure on the part of operators, but it was a test of their preparation. An embargo can break. A process that has already settled inventory, responsibility, update path and proof holds up even then.


## Frequently asked questions

**What is an embargo for security vulnerabilities?**  
An embargo is an agreement to publish the details of a vulnerability only at a fixed point in time, usually together with the patch. Until then, only the discoverers, the vendor and selected partners know the details, so that updates can be prepared.

**Was the PHP patch released earlier because of the leak?**  
On 20 October, php.net announced the security release for 21 October at 14:00 UTC and reserved the right to release earlier if details became public or attacks appeared. According to several reports, the announcement was made because details were already circulating before the embargo expired.

**Is a vulnerability that becomes known early more dangerous?**  
It shortens the time operators have to prepare and gives attackers an earlier starting point. According to media reports, a first attack attempt was observed as early as 17 October, that is, before the patches.

**What can a company do about surprises like this?**  
It cannot prevent vulnerabilities from becoming known early. But it can be prepared: with a list of all PHP systems, fixed responsibilities, tested update paths and an emergency page in case a server has to go offline temporarily.

## Sources

- [php.net: security announcements](https://www.php.net/)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [Help Net Security: PHP2Shell vulnerabilities patched](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619)