PHP2Shell Exploitation: How to Check If Your Server Was Hit

Last updated 23 October 2026, 08:08 IST. This page covers detection. For the fixed versions and how to update, see my PHP security update page.

If you patched PHP on 21 October, or the day after, you closed the door. You haven't yet checked whether someone walked through it first. Amazon says its MadPot honeypots recorded a PHP2Shell exploitation attempt on 17 October, four days before the fix was public. That's why "we patched" isn't the end of this one.

PHP2Shell is the name being used for two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October. Below is the checklist I'd run on any PHP server that faces the internet: what to look at in logs, processes and files, what to do if you find something, and what to set if you can't patch yet. It's defensive only. There are no exploit details here.

What happened

On 21 October the PHP project shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two flaws that, in php.net's words, "can allow unauthenticated remote code execution". The PHP project scored both at 9.2 under CVSS 4.0, and that's the score NVD shows from php.net for each. NVD's own CVSS 3.1 scores are 9.8 for CVE-2026-109618 and 8.1 for CVE-2026-109619. You can paste the 4.0 vector into the CVSS vector parser to see what each part means.

Amazon Threat Intelligence says the 17 October attempt came from a commercial anonymization network while the bugs were still under embargo. On release day it saw several proof-of-concept exploits and more attempts against its sensors, and it reports broad exploitation attempts since the details went public. AWS also says it's unclear whether those attempts would have succeeded on real systems. Its advice is plain: investigate "from at least starting on October 17th".

Step 0: patch first

Checking a server that's still vulnerable is a waste of an afternoon. Get to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's patched package, and restart every PHP-FPM pool or Apache. php.net says Linux distributions and LTS vendors received the patches in advance, so a distro package can be fixed without showing those version numbers. My patch page has the details.

Who should worry most

php.net says the risk applies to "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed". It considers the risk highest for mod_php, where it has a demonstrated exploit that works before any application code runs. So a plain Apache box with mod_php and no framework in front of it isn't safer. If anything, it's the one to check first.

Set your window

Your window starts on 17 October (00:00 UTC is 05:30 IST) and ends at the moment the patched PHP was actually serving requests. That's when you restarted every worker, not when the package was installed. If you have several servers, write down the end time for each one.

Check 1: web server logs

AWS gives one concrete thing to search for: POST requests with the PHP_SESSION_UPLOAD_PROGRESS string in form uploads. On a normal site that field turns up rarely, if ever, and almost never on pages that don't take uploads.

On a typical Linux server, these read-only searches are a starting point. Adjust the paths to your setup, and use zgrep for rotated .gz logs:

• grep -c "PHP_SESSION_UPLOAD_PROGRESS" /var/log/nginx/*.log /var/log/apache2/*.log
• grep -E "\"POST " /var/log/nginx/access.log | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn | head -50

There's a catch. Most access logs only record the URL, status and size, not the request body, so the upload-progress field won't show up there. You'll find it in a WAF log, a reverse proxy or load balancer that records request bodies, or an application log that saves form fields. Check whichever of those you have.

In the access log itself, look for:

• POSTs to pages that never take uploads, like the homepage, login or a static path
• Bursts of large POSTs from one address in a short time
• POSTs that ended in a 500, 502 or 504

Then check the PHP-FPM error log (often /var/log/php*-fpm.log) and the web server error log for the same period. Look for worker crashes ("exited on signal"), segmentation faults and "Allowed memory size" fatal errors. A cluster of these lining up with odd POSTs is worth a closer look.

Check 2: the AWS IP list

AWS published six addresses it saw in this activity:

• 103.216.220.92 (17 Oct)
• 31.223.184.166 (21 Oct)
• 37.19.200.5 (21 Oct)
• 134.209.159.64 (21 Oct)
• 103.114.163.188 (21 Oct)
• 95.217.98.37 (21 Oct)

Search your access logs, WAF logs and firewall logs for them. Read AWS's caveat before you act on a hit, though. AWS says these "include shared anonymization infrastructure and are not exclusive to this threat activity", and that you should "investigate any observations involving these addresses as opposed to blocking". A hit means look closer at what that address did on your site. It doesn't prove you were breached. And not finding them proves nothing, because other actors used other infrastructure.

Check 3: processes

PHP being exploited usually shows up as the web user doing things it never normally does. Check what's running as www-data, apache, nginx or nobody:

• ps -eo user,pid,ppid,lstart,cmd --forest and look under the PHP-FPM or Apache processes for shells, curl, wget, python, perl or anything you don't recognise
• ss -tpn for outbound connections owned by the web user to addresses you can't explain
• crontab -l -u www-data (and the other web users) plus /etc/cron* for new entries
• /etc/passwd and your sudoers files for accounts or changes you didn't make

My Linux process management guide covers reading process trees and finding what owns a connection.

Check 4: files

Look for PHP files that are new or changed since 17 October, especially in places that should only hold uploads or cache:

• find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
• find /var/www -type f -user www-data -newermt "2026-10-17" -ls, for files the web user created (swap in your web root and user)
• Any .php file inside an uploads, images or cache folder is suspect on its own

Deploys also change files, so compare against your git repo or a known-good backup rather than eyeballing. Nextron Research said on X that after successful exploitation it expects "webshell drops, reverse shells, suspicious child processes, new user accounts". Checks 3 and 4 are aimed at exactly those. If the web user can write to your code folders at all, my file permissions guide explains how to fix that.

If you find something

1. Isolate it. Take the server out of the load balancer or block inbound traffic, but leave it powered on.
2. Preserve evidence before you clean. Copy the logs off the box, and take a disk snapshot (and a memory capture if you can) first. My memory forensics and IR pipeline article covers the deeper path.
3. Rotate every secret the app could read. That includes database passwords, API keys, .env files, cloud keys, mail credentials and payment provider keys. Do it from a clean machine.
4. Rebuild, don't clean. If you've confirmed a webshell or an unknown process, rebuild the server from a known-good image on patched PHP and redeploy your code from git. Deleting one file leaves whatever else was dropped.
5. Tell your hosting provider, and anyone else your incident process says to, including customers if personal data was on the box.

Can't patch today?

php.net lists interim settings and is blunt that they "reduce exposure to specific attack paths but do not make an installation safe". AWS adds that upgrading is the only complete fix. With that warning, here's what php.net lists:

• For CVE-2026-109619: set session.upload_progress.enabled=0 and restart every worker. Set it in php.ini, an FPM pool or server configuration that applies before request parsing. php.net says not to rely on ini_set() or FPM .user.ini files.
• On PHP 8.5: also set fatal_error_backtraces=0 and restart every worker.
• For CVE-2026-109618: set a low post_max_size. php.net suggests 8M if the app doesn't take uploads and 32M if it does, with upload_max_filesize kept below it. It also suggests setting memory_limit=-1 in a way apps can't override, together with a container or cgroup memory limit as the real cap. php.net warns not to substitute RLIMIT_AS or RLIMIT_DATA, because those can trigger the vulnerable failure. Read the full advisory before changing memory settings.

AWS also suggests considering blocking multipart file uploads where you can't patch yet, once you've checked what that does to your app. A WAF can reduce exposure, but it doesn't replace the upgrade.

Shared hosting

On most shared plans you can't see system logs or other users' processes, so do what you can:

• Ask your host which PHP version your site runs, and when it was patched and restarted
• Download your access logs from the control panel and run Check 1 and Check 2 on them
• Compare your site files against a backup from before 17 October, looking for new .php files, especially in upload folders
• Change your database, admin and FTP or SSH passwords if anything looks off

FAQ

Is PHP 8.1 or older fixed? Not by the PHP project. php.net says 8.1 and older no longer get updates. It did publish minimal source backports for 7.4, 8.0 and 8.1 for people who build from source, and says to ask your LTS vendor or upgrade.

Will a WAF protect me? It can reduce exposure while you patch, and AWS has published a WAF post for this. But AWS says upgrading is the only complete remediation.

I'm on PHP 8.2. Anything else to know? Security support for 8.2 ends on 31 December 2026, so plan your move to a newer branch now.

I patched on the 21st. Can I skip this? No. AWS saw an attempt on the 17th, so check back to then.

More incident response guides are on the incident response tag page.

Sources

• AWS Security Blog, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot: https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• php.net security advisory, 21 October 2026: https://www.php.net/archive/2026.php
• NVD, CVE-2026-109618: https://nvd.nist.gov/vuln/detail/CVE-2026-109618
• NVD, CVE-2026-109619: https://nvd.nist.gov/vuln/detail/CVE-2026-109619
• GitHub advisories: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w and https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• Nextron Research on X: https://x.com/nextronresearch/status/2113279112567497142
• PHP supported versions: https://www.php.net/supported-versions.php