PHP2Shell attacks started before the fix. Check your logs back to 17 October

If you updated PHP on Wednesday night, well done. But don't close the laptop just yet. Amazon says it saw someone trying the PHP2Shell flaws on 17 October, four days before the fix came out. So "patched" tells you you're safe now. It doesn't tell you nobody got in last week.

This is my third post on PHP2Shell this week, so I'll keep it short and practical.

What's new since Wednesday

The fixed versions are out. The PHP team's release notes on php.net list them: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your PHP is from your Linux distribution, the number will look different, because distributions copy fixes into their own builds. More on that below.

Attacks began before anyone could patch. Amazon's threat intelligence team published a write-up on 21 October. Its decoy servers picked up an attempt on 17 October, and more from 2am UTC on the day of the release, about twelve hours before the fix. Its advice is blunt: "Start investigations from the earliest known exploitation, not from the disclosure date."

The tricky part has been cracked. VulnCheck says it has a working exploit for PHP 8.4.10 to 8.4.26 on normal x86 servers, with ASLR switched on (a standard protection that makes memory attacks harder) and errors hidden, as recommended for live sites. The Register reports that VulnCheck has only given it to its own customers. But Amazon says more exploits appeared within hours of the fix, and were tried on its decoy servers almost straight away.

A correction to my own advice

On Wednesday I passed on some stopgap settings to buy time until the fix came out. PHP has now published its own list, and it says these measures "do not make an installation safe". VulnCheck says the main setting, session.upload_progress.enabled=0, blocks the known attack route "but not other variants".

So if you turned those settings on and stopped there, you're not finished. The only real fix is the update.

Does it affect you?

If your site runs on PHP and it wasn't updated by the end of 21 October, assume yes. PHP says the risk is highest for mod_php, where PHP runs inside Apache, because an attack can work before any of your site's own code runs.

If you're on shared hosting or managed WordPress, your host should have updated PHP for you. It's still worth a quick ticket asking when it was done.

Check you're actually patched

On Debian, the security tracker lists the fixed packages as 8.4.27-1~deb13u1 for Debian 13 and 8.2.35-1~deb12u1 for Debian 12. On Ubuntu, the CVE page lists fixes for every supported release, including 8.3.6-0ubuntu0.24.04.13 for 24.04 and 8.1.2-1ubuntu2.28 for 22.04. Older Ubuntu releases have fixes through Ubuntu Pro.

This shows what's installed:

dpkg -l | grep php

Then make sure the running PHP is the new one. Restart PHP-FPM (for example sudo systemctl restart php8.4-fpm), or Apache if PHP runs inside it. An updated package does nothing while the old version is still in memory.

On an unsupported version such as 7.4 or 8.0, without Ubuntu Pro or similar, there's no packaged fix. The realistic answer is moving to a supported version, quickly.

Check whether anyone tried

Amazon says the attacks it saw used PHP's upload progress feature. Its advice is to look for POST requests containing PHP_SESSION_UPLOAD_PROGRESS. Most web server logs don't record request bodies, so you may only find that in a firewall or WAF log.

What your normal logs can show you is the scanners. VulnCheck lists user agents seen in attacks, which start with php2shell-scan, php2shell-verify or include php2shell-poc. On a typical Apache or nginx server:

sudo grep -ri "php2shell" /var/log/apache2/ /var/log/nginx/

VulnCheck points out those names are "trivial to change", so finding nothing doesn't prove much.

Next, list PHP files in your website folders changed since 17 October:

find /var/www -name "*.php" -newermt 2026-10-17

Plugin and theme updates will show up. You're looking for anything you can't explain, especially in an uploads folder. VulnCheck also saw an attack try to slip code containing the word PWNED:: into PHP's session files, and suggests searching session folders. On Debian and Ubuntu those usually live in /var/lib/php/sessions:

sudo grep -rl "PWNED" /var/lib/php/sessions/

Amazon also says to check for "unexpected process execution or file modification". If top shows something you don't recognise running as your web server's user (usually www-data), take it seriously.

If you find something

Don't just delete the file and carry on. Take a copy of the site and the logs as they are, change your hosting, database and admin passwords, and get it looked at properly. One planted file is often a sign of others.

The bigger point

Amazon makes a point worth remembering. For flaws like this, it says to "measure patch and mitigation timelines in hours." That's hard for a small business with no one watching the servers. If you've found something in your logs and you'd rather not deal with it yourself, that's what my breach first response is for. I'll contain it, find out what happened, clean up and write down what I did.