Did PHP2Shell Hit Your Server? How to Check for Compromise After Patching

Patching PHP closes the door, but it says nothing about whether someone walked through it earlier. Security reports indicate exploitation attempts against these flaws began before the public announcement on 21 October, so any server that stayed unpatched for days deserves a sweep. A caution first: we are not aware of a reliable list of indicators, so what follows is based on how the bugs work and on ordinary signs of a compromised web server, not on a known signature. Treat a clean result as encouraging, not proof. Background on the flaws is in our overview of PHP2Shell, CVE-2026-109618 and CVE-2026-109619.

Preserve evidence before cleaning

Take a snapshot or backup of the server before you remove anything, and copy the logs somewhere safe. Cleaning first destroys the timeline you need to work out what happened.

Look for crashes and memory errors

Both bugs involve memory handling, so failed exploitation attempts often leave crashes behind. Bursts of worker crashes or memory-limit fatals around the exposure window are worth reading closely:

grep -h "exited on signal" /var/log/php-fpm/*.log | tail -30
grep -h "exit signal Segmentation" /var/log/apache2/error.log /usr/local/apache/logs/error_log 2>/dev/null | tail -30
grep -c "Allowed memory size" /home/*/logs/*error* 2>/dev/null | sort -t: -k2 -rn | head

A handful of crashes is normal. A sudden spike, especially clustered in a short period, deserves attention.

Find new PHP files

Webshells are usually plain PHP files placed somewhere writable. Look for PHP created since just before the earliest reported attempts:

find /home /var/www -type f -name "*.php" -newermt "2026-10-17" -printf '%TY-%Tm-%Td %p\n' | sort -r | head -50
find /home /var/www -path "*/uploads/*" -name "*.php" 2>/dev/null

Many results will be legitimate updates, so read what is unfamiliar rather than deleting by pattern. Our guide to finding malware on a hacked WordPress site shows how to search for obfuscated code.

Check processes, connections and scheduled jobs

ps aux --sort=-%cpu | head -15
ss -tunp | grep ESTAB | head -30
for u in $(ls /home); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Look for processes you cannot explain running as web users, unexpected outbound connections, and cron entries that download or run files. Also check for new user accounts and new SSH keys in authorized_keys.

Assume secrets may have been exposed

Reports describe the ability to read PHP worker memory, which can hold database passwords and API keys. If you have any reason to suspect exposure, rotate database credentials, application keys, mail passwords and tokens, and update the configuration files that use them. This is cheap insurance compared with a breach.

If you find something

Isolate the account or server, keep the evidence, and find the entry point before cleaning, otherwise the attacker returns. Our guide on finding a spammer on a cPanel Exim server helps if the server is sending mail.

For a suspected compromise, contact us. Our emergency server support engineers can contain it, remove what was left behind and close the way in.