Updated After PHP2Shell: How to Check Whether You Were Compromised

Why you need to check

Some time passed between the appearance of working exploits and your update. A patch closes the door but does not remove someone who already got in. If the server faced the internet unpatched for even a day after October 21, 2026, you should run this check.

Step 1. Traces in web server logs

The attack looks like unusually large POST requests, often to nonexistent paths, sometimes with a 500 response.

awk '$6 ~ /POST/ && $10 > 100000' /var/log/nginx/access.log | tail -50
grep -c ' 500 ' /var/log/nginx/access.log

Compare the number of 500 responses with the normal level. A spike in the days before the update is a reason to look more closely.

Step 2. New and modified files

find /var/www -type f -newermt '2026-10-15' \( -name '*.php' -o -name '*.phar' \) -printf '%TY-%Tm-%Td %p\n' | sort
find /tmp /var/tmp /dev/shm -type f -name '*.php' 2>/dev/null

PHP files in temporary directories are almost always a bad sign. In the site directory, pay attention to files that are not in your repository.

Step 3. What is running and what is listening

ps -eo lstart,user,cmd --sort=start_time | tail -30
ss -tulpn | grep -vE ':(22|80|443|3306|6379)\b'

Look for processes run by the web server user that you did not start, and for ports that nothing should be listening on.

Step 4. Persistence points

crontab -l; sudo crontab -l
ls -la /etc/cron.d/ /etc/cron.*/
sudo grep -rn 'curl\|wget\|base64' /etc/cron* 2>/dev/null | head
systemctl list-units --type=service --state=running | tail -20
cat ~/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null

An unfamiliar key in authorized_keys means access is retained and a password change does not close it.

Step 5. If you find traces

The order of actions matters:

Take a disk image, or at least a copy of the logs. You will need them to understand what happened.
Do not clean the server one file at a time: after a full compromise, it is safer to build a new server and migrate the data after checking it.
Rotate everything that could have leaked: database passwords, API keys, payment system tokens, SSH keys, and control panel passwords.
Check whether mail was sent from the server. Compromised servers are often used for spam mailings.

If you find no traces

That is a good sign but not proof. Store logs on a separate server, set up alerts for new PHP files in site directories, and check that backups are being made and can be restored.

Frequently asked questions

Will an antivirus scan find a web shell after PHP2Shell?

Scanners such as ClamAV with a web shell ruleset find typical backdoors, but not all of them. An empty result proves nothing.

Should I reset my customers' passwords after a possible compromise?

If you have reason to believe the database leaked, yes, with a forced reset. Without signs of compromise, rotating the service keys is enough.

How long should I keep server logs?

At least 90 days. In an investigation, the first thing you lack is records from a week ago.