Am I Already Compromised? Signs After PHP2Shell

In short: Whether a server was hacked via PHP2Shell cannot be read from a single feature. There are no published, confirmed indicators of compromise; detection relies on behavioral analysis. Typical signs are new PHP files, unknown cron jobs and unusual connections. First preserve the logs from 20 October onwards before you change anything.

Are there clear signs of a PHP2Shell attack?

No, and that is the honest answer. For many known vulnerabilities, vendors or security firms publish concrete traces: file names, checksums, IP addresses. For PHP2Shell, no such confirmed indicators of compromise exist so far.

What is known: according to media reports, a first attack attempt was observed on 17 October, four days before the patches of 21 October. Cloudflare reported further attempts. According to the BSI (German Federal Office for Information Security), confirmed successful attacks at scale were not known at first. Anyone who was reachable without protection between 17 October and their own patch should therefore check rather than hope.

For the assessment, the time period counts above all. Between the first observed attack attempt on 17 October and the patches on 21 October, there was no official update. Every publicly reachable PHP server was potentially attackable during that time. How long your server was exposed beyond that depends on when the update was installed and PHP restarted. The longer this period and the more sensitive the data, such as customer accounts, orders or applications, the more thorough the check should be.

Typical signs that a server has been hacked

After successful code execution, attackers usually try to establish a foothold and use the server. This produces signs that are not specific to PHP2Shell but count in any break-in check:

• New or modified PHP files, especially in upload, cache or image directories where no PHP files are normally located.
• Unknown cron jobs or scheduled tasks, for example for the web server user.
• Unusual outgoing connections to unknown addresses, high network load or mail sending that nobody initiated.
• New admin accounts in the CMS or shop, changed passwords, unknown SSH keys.
• Conspicuous load: persistently high CPU usage by unknown processes, often an indication of crypto mining.
• Visible consequences: redirects to foreign sites, spam pages in the Google index, warnings in the browser or in Search Console.

None of these signs proves a break-in on its own, and their absence does not prove the opposite. The overall picture is decisive.

First checks without destroying evidence

Before you delete or restart anything: preserve the logs. The trade press advises keeping server logs from 20 October onwards. Copy web server, PHP and system logs to a safe place outside the server.

After that, read-only checks help. Paths and user names differ by system:

# PHP files changed since 17 October
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls

# PHP files in upload directories (WordPress example)
find /var/www -path "*/uploads/*" -name "*.php" -ls

# cron jobs of the web server user and system-wide
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null

# active network connections with process
ss -tunp

# recent logins
last -n 30

Note: attackers can forge file timestamps. An unremarkable result from find is therefore no acquittal. How to analyse logs in a targeted way is described in Analysing web server logs after an attack; how to find backdoors, in Detecting and removing webshells.

What you should not do

• Just patch and carry on. A patch does not remove malware that has already been planted.
• Delete suspicious files immediately. That removes evidence of what happened and which data may be affected.
• Rebuild the server before backing up. The cause remains unclear, and a backdoor in the database or credentials survives the reinstallation.
• Restore old backups unchecked. A backup can also already contain the backdoor.
• Forget credentials. After code execution, database passwords, API keys and other credentials from configuration files may have leaked. Renew them after the cleanup, not before, so that an attacker who is still active does not read the new ones right away.

If the suspicion is confirmed

Then it is about more than technology. Check with your data protection officer whether a notification under the GDPR is necessary; the deadline is 72 hours from awareness, details at GDPR notification duty. Inform your cyber insurer early, if you have one, and clarify with a lawyer whether to file a report with the police. We give general notes on this, not legal advice.

How does PHP SOS help?

With our incident response, we work through a suspicion in a structured way:

• Preserve: Logs from 20 October onwards and, where necessary, an image of the system, before anything is changed.
• Investigate: Behavioral analysis of files, processes, connections and accounts; where needed, in a court-admissible manner with IT forensics.
• Clean up and close: Remove backdoors, update PHP, renew credentials, harden the server.
• Document until the incident is closed and documented, as a basis for data protection, insurance and management.

Frequently asked questions

Sources

• php.net: Security announcements
• BSI: German Federal Office for Information Security
• GDPR Art. 33: Notification to the supervisory authority
• OWASP Cheat Sheets