In short: The time window between patch and attack was negative with PHP2Shell: according to media reports, there was a first attack attempt as early as 17 October 2026, four days before the updates. For operators, the question is therefore not "How much time is left?" but "How long is my server open?" This personal window only ends once the update is installed and all PHP processes have been restarted.
The trigger: attacks before the patch
For a long time a comfortable assumption held: some days pass between a security update and the first attacks, enough time for the next maintenance window. PHP2Shell has refuted this assumption. According to media reports citing Amazon, a first attack attempt was observed as early as 17 October. Cloudflare also reported early attacks. The patches came on 21 October at 14:00 UTC.
This article explains how such time windows arise and how to shorten yours. You will find the exact sequence of dates in the PHP2Shell timeline.
The time window between patch and attack in phases
Around a security vulnerability, several phases can be distinguished. With PHP2Shell they looked like this:
| Phase | In general | With PHP2Shell |
|---|---|---|
| Before disclosure | vulnerability known only to discoverers and the vendor | development of the fix under embargo |
| First attacks without a patch | attackers exploit the vulnerability before an update exists | according to media reports, first attempt on 17 October |
| Advance announcement | vendor announces the update | 20 October, php.net announces the release |
| Patch available | update and security announcement appear | 21 October, 14:00 UTC |
| Analysis of the patch | researchers and attackers analyse the changes | watchTowr says it reproduced CVE-2026-109618 |
| Broad exploitation | automated campaigns against unpatched servers | expected by the BSI; confirmed successful attacks on a broad scale initially not known |
| Your patch | update and restart on your servers | individual |
The last row is the only one you can influence. Everything before it is determined by others.
Why the patch itself increases the pressure
A security update closes the vulnerability but at the same time makes it visible. Source code changes in open-source projects such as PHP are public. Anyone who compares the differences between the old and new version learns where the flaw was. That is no reproach to the PHP project but the normal case with open software and the basis on which distributions can build backports.
For operators it follows that with every day after the patch, the number of people who know how the vulnerability works grows. At the same time, the number of unpatched servers falls. The remaining ones thus become the obvious targets. How PHP delivers security updates as part of its version maintenance is explained in the article on the PHP release cycle.
If your server was reachable between 17 October and your patch, a check for traces is part of the job. Preserve the logs from 20 October onward before they are lost through rotation.
Measuring your own time window
Your personal time window begins at the latest with the publication of the patches and ends with the restart of the last PHP process. Record for each server:
- Awareness: When did someone in the company learn of the vulnerability?
- Availability: When was the package from your distribution or hosting provider ready?
- Installation: When was it installed?
- Restart: When were no old PHP processes running any more?
The restart in particular is often forgotten. An installed update only takes effect once the old processes have ended. How to check this is described in Restarting PHP-FPM and all PHP processes. Whether processes from before the update are still running is shown by a look at the start times:
# Show the start time of all PHP processes
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
If the start time is before the installation of the update, the window is still open.
Why your window depends on the source of your packages
How quickly you can patch depends not only on you but also on where your PHP comes from. According to reports, distributions in some cases shipped backports as early as 21 October. Anyone who gets PHP from a third-party repository depends on its pace. Anyone who uses containers has to rebuild and roll out images; a mere update inside the running container is not enough. And with shared hosting, the hosting provider determines the timing.
If you know the source of each server's packages, you also know where your window stays open longest. That is exactly where preparation pays off most, for example through an agreement with the hosting provider or a tested procedure for new container images.
How to shorten the time window next time
- Subscribe to announcements: Receive security announcements from php.net and your distribution directly, not only via the press.
- Assign responsibility: For each server, a responsible person with a deputy.
- Use automation where it fits: Security updates from the distribution can be installed automatically. What speaks for and against this is described in Automatic security updates.
- Plan the restart: The restart of the PHP services belongs firmly in the procedure, not in the follow-up.
- Prepare an emergency route: An emergency page and a decision on a temporary shutdown in case an update is not immediately possible.
- Keep proof: Document the times of installation and restart so that you can substantiate your window later.
A lasting process that bundles these points is described in the article on the patch management process.
How does PHP SOS help?
- Patch and restart: We install the update and make sure that no old PHP processes are running any more.
- Substantiating the time window: We document installation and restart for each server with timestamps.
- Trace check: For the period in which your server was open, we preserve logs and check for anomalies.
- Process for the future: Together with you, we set up reporting channels, responsibilities and update procedures.
More under PHP patch service.
Conclusion
With PHP2Shell there was no grace period. With critical vulnerabilities, the time window between patch and attack is now often zero or even negative. What you can control is your own window: it ends with the restart, and with preparation it can be shortened from days to hours.
Frequently asked questions
How much time is there after a security update before attacks start?
There is no fixed deadline. With PHP2Shell, a first attack attempt was observed as early as 17 October according to media reports, that is, four days before the patches. With critical vulnerabilities in widely used software, you should assume that there is practically no grace period.
What is a zero-day?
A vulnerability that is attacked before an update is available. The vendor had, so to speak, zero days to fix it. Afterwards one often speaks of a known or N-day vulnerability, for which a patch already exists.
Why do attacks often become more frequent after a patch?
With the patch, it becomes public where the flaw was. Security researchers and attackers can analyse the changes. At the same time, many servers remain unpatched for days or weeks and are thus worthwhile targets.
When is my server really protected?
When the update is installed and all PHP processes have been restarted. New files alone have no effect as long as old processes are running in memory. The end of your personal time window is therefore the restart, not the download.