PHP2Shell: your server is patched, but was it broken into?

Short answer

A patch closes the hole. It doesn't remove anything that got in before you patched (Kompas Tekno). So after updating, the question changes from "am I vulnerable?" to "was I hit?".

Nobody can answer that from outside. You need to check the logs, files, processes and accounts on your own server, going back to 17 October 2026, the date of the earliest known exploitation attempt (AWS). This page covers what to look for, which source says so, and what to do if you find something.

Not sure your server is patched yet? Start with Am I affected by PHP2Shell?. A distro package can show an old version number and still be patched, so check your distro's tracker rather than comparing version numbers.

Has anyone actually been hit?

What's certain: there have been many attempts. Amazon logged the first attempt in its honeypots on 17 October, four days before disclosure, and says PHP2Shell "is now seeing broad exploitation attempts in the wild". About the pre-disclosure attempts, Amazon says it's unclear whether any of them would have succeeded against real systems (AWS).

As for successful attacks, on 21 October watchTowr said it hadn't seen any yet, while expecting that not to last long (SecurityWeek). We haven't found a public source confirming that a specific site was breached through PHP2Shell.

In Indonesia, a Threads post from 23 October drew wide attention: its author checked their own server after PHP's announcement and found it already had a root compromise. The post doesn't say PHP2Shell was the cause. The lesson is the same either way: check, don't assume.

The full timeline and the myths going around are on PHP2Shell: myths vs facts.

Before you start: save the logs

Technology firm PXL, quoted by Kompas Tekno, says the first step is to save the server's access and error logs before they're deleted or the server is changed (Kompas Tekno). Huntress also advises preserving web server and PHP logs (Huntress). Copy the logs somewhere else before you clean anything up.

Step 1: look for attack requests

Amazon advises looking for POST requests with the PHP_SESSION_UPLOAD_PROGRESS string in form uploads, and reviewing web server logs for suspicious activity (AWS).

Note that the string sits in the form body, while the standard access log format only records the request line (method, path, protocol), not the request body (Apache docs). So a normal access log most likely won't contain it. Search logs that record request bodies, such as WAF logs, if you have them.

Amazon also published the IP addresses it saw in exploitation attempts (AWS):

Amazon says these include shared anonymization infrastructure and aren't exclusive to this activity, and advises investigating any sighting rather than blocking (AWS). So if one shows up in your logs, that's a reason to dig further, not proof of a break-in.

Example search on a VPS (adjust the log paths to your server):

grep -E '103\.216\.220\.92|31\.223\.184\.166|37\.19\.200\.5|134\.209\.159\.64|103\.114\.163\.188|95\.217\.98\.37' /var/log/nginx/access.log* /var/log/apache2/access.log*

For compressed logs (.gz), use zgrep with the same pattern.

Step 2: processes started by PHP

Amazon advises checking for unexpected process execution on web application servers (AWS). Huntress is more specific: watch for PHP workers launching shells, interpreters or download tools (Huntress).

On a VPS, list processes running as the web server user, with their parents:

ps -ef --forest | less       # look for shells, curl, wget, python or perl under php-fpm, apache2 or httpd
ps -u www-data -f            # replace www-data with your web server user (e.g. apache, nginx)

These only show processes running right now, not ones that have finished.

PHP's advisory describes the impact as code execution with the web worker's privileges (GHSA-6wmf). So also check what that user can read and change.

Step 3: new or changed files

• Amazon: check for unexpected file modification on web application servers (AWS).

• Huntress: look for webshells and new files in your web root (Huntress).

• PXL, quoted by Kompas Tekno: look for unfamiliar PHP files, especially in WordPress's wp-content/uploads folder, and files changed since 20 October 2026 (Kompas Tekno).

Example on a VPS (replace /var/www with your site folder). We use 17 October so that both the AWS and PXL windows are covered:

# files modified since 17 October 2026
find /var/www -type f -newermt '2026-10-17' -ls

# PHP files in the WordPress uploads folder (normally there are none)
find /var/www -path '*wp-content/uploads*' -name '*.php' -ls

The -newermt option compares a file's modification time with the date you give (find manual). The results will include files you changed yourself, for example during updates. Check each file you don't recognize.

Step 4: accounts, cron jobs and SSH keys

• Huntress: new cron jobs, scheduled tasks and accounts (Huntress).

• PXL, quoted by Kompas Tekno: unknown administrator accounts, scheduled tasks and new SSH keys (Kompas Tekno).

What you can check:

crontab -l -u www-data              # the web server user's cron
ls -la /etc/cron.d /var/spool/cron* # system cron
cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys

In your application, check the admin list. In WordPress: Users, filtered to the Administrator role.

Step 5: other signs

PXL also advises watching for sudden jumps in CPU use or outbound traffic from the server (Kompas Tekno). Your VPS provider's monitoring graphs can show such spikes since 17 October.

On shared hosting

On shared hosting you usually can't see processes or system logs. What you can still do yourself, through the file manager and your app's dashboard: look for PHP files in the uploads folder, files changed since 17 October, and unknown admins (Steps 3 and 4). For the rest, ask your host:

"Did the server my account is on receive requests from the IP addresses Amazon published for PHP2Shell (103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37) since 17 October 2026? Were there POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS, or PHP processes spawning shells, on my account? Please send me my account's access and error logs since 17 October."

If you find signs of compromise

1. Isolate the server and preserve the web server and PHP logs (Huntress).

2. Don't just delete the unfamiliar files. PXL says the system needs a thorough check and clean-up, passwords and access keys changed, and the site restored from a clean backup (Kompas Tekno). Attackers can plant hidden access to get back in even after the hole is patched (same source).

3. Look for backdoors. The UK NCSC advises assessing systems for evidence of compromise and looking for backdoors installed by an attacker. If you're not confident doing this yourself, get help from an incident response provider (NCSC).

4. Then make sure PHP is patched and every worker restarted: steps here.

If you find nothing

That's good news, but not a guarantee. PXL warns that PHP2Shell can be used to read sensitive data in memory without leaving new files or accounts (Kompas Tekno). Wiz researchers say that memory can contain passwords, authentication tokens, API keys and certificates (Wiz).

So, in Kompas Tekno's summary of PXL and Malwarebytes, operators who were still running vulnerable PHP after 20 October are advised to change database passwords, security keys and API keys (Kompas Tekno).

One more thing: the PHP team suggests keeping session.upload_progress.enabled=0 until the next regular release, because of a rare related flaw, CVE-2026-115560 (php.net). How to set it is on the am I affected page.

Want us to check and patch it?

We've checked and patched PHP hosts we run for clients (WordPress, WooCommerce and Moodle sites). For your server, we check the PHP version, SAPI and packages, then patch, upgrade or backport (PHP 7.4–8.1), restart the workers and look for signs of compromise: PHP or web server processes spawning shells, new files or webshells in the web root, and new cron jobs or accounts. On shared hosting, we switch the PHP version where the hosting panel allows it. Where it doesn't, the server's PHP belongs to your host, and we send your host the exact request. You get a written findings report the same day you request it. If the compromise check finds signs of trouble, we put them in the report and discuss next steps separately. For servers we patch ourselves, we report the final status as it is: checked and patched.

See the scope and request a check & patch →