In short: The PHP2Shell timeline so far has four confirmed dates: a first observed attack attempt on 17 October, the advance notice from php.net on 20 October, the patches on 21 October at 16:00 German time, and a further note on CVE-2026-115560 on 23 October 2026. For operators this means: patch, restart all PHP processes and secure logs from 20 October at the latest.
Why a PHP2Shell timeline matters for operators
With a vulnerability of this severity, it is not only a question of whether your server is patched today. How long it was vulnerable beforehand matters just as much. That window determines which logs you secure, which files you check and whether you can rule out a compromise with good reason.
PHP2Shell affects PHP itself, not a single CMS. Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, allow remote code execution without authentication. Both are rated CVSS v4.0 9.2. An accessible introduction is at What is PHP2Shell?.
The following chronology contains only dates that are confirmed as of 25 October 2026. Where a statement rests on media reports, this is noted.
| Date | Event | Basis |
|---|---|---|
| 17 Oct 2026 | First observed attack attempt (Amazon) | Media reports |
| 20 Oct 2026 | Advance notice from php.net | php.net |
| 21 Oct 2026, 14:00 UTC | Patches released (16:00 German time) | php.net |
| 23 Oct 2026 | Note on CVE-2026-115560 | php.net |
| 25 Oct 2026 | Status of this overview | – |
17 October: the first observed attack attempt
According to media reports, a first attack attempt was observed on 17 October 2026, reported by Amazon. That was four days before the patches. So there was a period in which attacks were already being attempted but no update existed yet.
Whether, and how many, attacks succeeded in this phase is not documented. What matters is the consequence for your own check: a server that is patched today may have been compromised beforehand. A patch does not remove planted malware and does not prove that nothing happened before.
20 and 21 October: advance notice and patches
On 20 October 2026 the PHP project announced the security updates on php.net. On 21 October 2026 at 14:00 UTC, which is 16:00 German time, the fixed versions followed.
| Branch | Last vulnerable release | Fixed in |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |
For PHP 8.1 and older there are no official updates any more, only minimal source backports for 7.4, 8.0 and 8.1. According to the trade press, nearly all versions back to PHP 5.4 are affected. The affected operating modes are PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team sees the highest risk in mod_php, where an exploit was demonstrated before any application code even runs.
Distributions and hosts sometimes apply backports. In that case Plesk, for example, keeps showing 8.2.34 even though the server is patched. What counts is the package status and the provider's confirmation, not the displayed version number. How to check this properly is described under Checking the PHP version and patch status correctly.
23 October: note on CVE-2026-115560
On 23 October 2026 the PHP project published a further note, this time on CVE-2026-115560. According to it, exploitation is possible only with an unusual configuration: the configuration sets serialize_handler to php_binary or php_serialize, the application switches it to php via ini_set() before session_start(), and session upload progress is active.
The workaround is simple and should be applied regardless of whether you know of this constellation in your setup:
; in php.ini, in the FPM pool or in the server configuration
; not via ini_set() or .user.ini
session.upload_progress.enabled = 0
Then restart all PHP workers. The full advisory is to follow with the next regular bugfix release. Until then, this setting remains the recommended interim solution.
25 October: situation and open questions
The BSI (German Federal Office for Information Security) declared warning level 3 / orange. It recommends the immediate update and, where that is not immediately possible, temporarily taking web servers off the network. The BSI expected rapid, large-scale exploitation; according to the BSI, successful attacks in the wild were initially not known. The page What the BSI recommends on PHP2Shell summarises the BSI's assessment.
Cloudflare reported observed attack attempts and has rolled out protective rules, but warns that rules based on request data alone are not sufficient. Palo Alto Networks (Unit 42) counted more than 22.6 million exposed, potentially vulnerable instances. No confirmed indicators of compromise have been published; detection relies on behavioural analysis.
Some providers took websites offline as a precaution. That does not automatically mean those sites were hacked. As of this overview, the main open question is how many servers were actually compromised in the period before the patch.
What the timeline means for your logs and checks
The dates yield three periods: before 17 October, between 17 October and your own patch and restart time, and afterwards. The middle period is the critical one. The longer it lasted for you, the more thorough your check should be.
The trade press advises keeping server logs from 20 October 2026 onward. Also secure any older logs before automatic rotation deletes them.
A simple way to secure logs unchanged and record the state:
# Back up logs together (adjust paths to your system)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Checksum for later proof
sha256sum /root/logs-sicherung-*.tar.gz
# How long does the system keep logs?
grep -R "rotate" /etc/logrotate.d/
Also note exactly when the update was applied and when the PHP processes were restarted. New files alone do not protect you as long as old processes are still running in memory. How to analyse the secured logs is described in the guide Analysing web server logs after an attack.
How does PHP SOS help?
- Together with you, we determine your server's actual window of vulnerability: package status, patch time, restart of all workers.
- We secure logs and system state in a traceable way before anything is changed.
- We check for behavioural anomalies such as new PHP files, foreign processes and unusual outgoing connections.
- We document the result so that management, data protection officers and insurers can work with it.
Our PHP2Shell immediate help describes the process in detail.
Frequently asked questions
When were the PHP2Shell patches released?
The PHP project released the fixed versions on 21 October 2026 at 14:00 UTC, which is 16:00 German time. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
From which date should I keep server logs?
The trade press advises keeping logs from 20 October 2026 onward. Because media reports say a first attack attempt was already observed on 17 October, it is worth securing any older logs as well before log rotation deletes them.
Is CVE-2026-115560 as dangerous as the first two vulnerabilities?
According to the note of 23 October 2026, exploitation is possible only with an unusual session configuration. The workaround is session.upload_progress.enabled=0 until the next regular bugfix release is published.
Are there confirmed indicators of compromise for PHP2Shell?
No, as of 25 October 2026 no confirmed indicators of compromise have been published. Detection relies on behavioural analysis, such as unusual processes, new files and conspicuous connections.