Signs of compromise

Has your PHP site been compromised?

An update closes the route PHP2Shell uses, but it does not undo anything that came through it. If your site ran a vulnerable PHP build while reachable from the internet, look for PHP files nobody added, altered core files, unknown admin accounts and PHP processes launching shells. Keep the evidence before you clean anything up.

Last reviewed against the NCSC, CISA and the FBI.

Should you check?

Check any server that was exposed before it was patched

If any of these describes one of your servers, work through this page for it.

  1. 1

    It faced the internet on a vulnerable build

    At any point before you installed PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or your supplier's fixed package. Staging copies and old microsites count too.

  2. 2

    It could not be patched straight away

    If a PHP system cannot be updated or switched off immediately, the NCSC asks for it to be examined for signs of compromise and backdoors before the upgrade or mitigation goes on.

  3. 3

    It runs PHP 8.1 or older

    The PHP project has released no fix for these branches, and CISA's advice is to take such systems offline. Unless a supplier has patched your package, treat the server as still exposed.

Why it matters now

CISA added both PHP2Shell flaws to its Known Exploited Vulnerabilities catalogue on 26 October 2026, and its entries call for forensic triage as well as the fix. The same day, France's CERT-FR reported attempts to exploit them against specific PHP deployments.

The NCSC's fifth priority action covers servers that cannot be fixed or switched off at once: examine them for compromise and backdoors before upgrading or mitigating, and bring in an NCSC-assured incident response provider if you are not confident doing it yourself. NCSC alert

The PHP2Shell timeline

What to look for

Signs a PHP site has been compromised

None of these proves a compromise on its own, and a server can be compromised without showing any of them. Treat each one as a reason to look closer.

3D intruder at a desk of monitors, for PHP files nobody put there

PHP files nobody put there

A web shell is a small script that lets an attacker run commands through the website. NSA guidance notes that web shells nearly always arrive as a new file in a folder the website can serve, or as code slipped into a file that already exists. A PHP file in a folder meant for images and documents needs an explanation.

3D clipboard under a magnifying glass, for spotting changed files

Changed core, theme or configuration files

Compare the site with a clean copy of exactly the same version. On WordPress, WordPress.org singles out .htaccess, index.php and theme files such as header.php, footer.php and functions.php as favourite targets, because code there runs on every page.

3D hooded figure holding masks, for administrator accounts no one created

Administrator accounts no one created

New users that nobody on your team set up, especially ones with full admin rights. WordPress.org lists unauthorised new users among the clear signs of a hacked site, and the same check applies to any PHP application with its own logins.

3D attacker at a laptop with alerts, for PHP processes starting shells

PHP processes starting shells or fetching tools

This is the behaviour CISA and the FBI both tell defenders to watch for: a PHP-FPM or web server worker launching a command shell, or downloading files with a tool such as curl or wget. NSA's guidance notes that benign web servers rarely launch such programs.

3D wireless signal with a padlock, for unusual network connections

Network connections the server never normally makes

A web server reaching out to machines inside your network, or to addresses on the internet it has no business with. NSA's web shell guidance treats unexpected network flows from a web server as a warning sign.

3D crowd gathered around one person, for warnings from outside

Warnings from outside

Search engines or antivirus tools flagging the site, your host disabling it, or someone reporting that your site is being used to attack others. WordPress.org names all of these as clear indicators.

Signs specific to PHP2Shell

The researchers who found the flaws suggest checking the period before you patched for:

  • multipart requests (the kind browsers send for file uploads) followed by memory limit errors or runs of HTTP 500 responses;
  • PHPSESSID cookies in responses that are unusually large or malformed;
  • PHP worker processes dying and restarting with no obvious cause.

The attack works below the application, so the application's own logs may say little. The web server and PHP logs are the place to look. Wiz Research disclosure

Sources: CISA alert, FBI notice I-102326-PSA, NSA web shell guidance and WordPress.org.

Where to look

Where web shells tend to hide

An attacker who gets in through PHP starts with the web server's own permissions, so the places the web server can write to come first.

  • Upload folders

    Anywhere visitors or editors can upload files, such as wp-content/uploads on WordPress. OWASP's advice is that upload folders should not be able to run scripts at all, which is why a PHP file there stands out.

    OWASP on unrestricted file upload

  • Cache and other writable folders

    Folders the web server is allowed to write to. On WordPress that includes much of wp-content, which WordPress expects the web server process to be able to change.

    WordPress hardening guide

  • Inside files that already exist

    A few lines added to index.php, a theme file or .htaccess are easy to miss and run on every request. Reinstalling over the top may not help either, because installers tend to overwrite existing files while an attacker's additions are often new ones.

    WordPress.org: my site was hacked

  • Temporary folders

    /tmp, /var/tmp and /dev/shm on Linux. CISA's incident guidance names these as places to collect stray scripts and programs from during an investigation.

    CISA AA20-245A

  • Behind an old date

    Attackers can change a file's timestamps so a new file looks as old as its neighbours. A search by date is a useful hint, but a short list is not proof that nothing changed.

    MITRE ATT&CK: Timestomp

Read-only first checks

These commands only read and list; they change nothing. Run the file checks on a copy of the site where you can, such as a restored snapshot or a downloaded archive, rather than on the live server. Process and connection lists exist only on the live server: capture them before you restart PHP or apply the update, and copy the output somewhere off the server. They are a first look, not an investigation. 

  • find /path/to/copy/wp-content/uploads -type f -iname "*.php"

    Lists PHP files inside a WordPress uploads folder. Change the path for other platforms' upload folders.

  • find /path/to/copy -type f -iname "*.php" -mtime -14

    Lists PHP files whose contents changed in the last 14 days. Raise the number to cover the whole time the server ran a vulnerable build.

  • wp core verify-checksums --include-root

    WordPress only, run with WP-CLI from the site folder. Compares core files with the checksums WordPress.org publishes for your version and warns about extra files in the root folder. It runs before WordPress itself loads.

  • ps axjf

    Live server only. Shows running processes as a tree. Look for a shell (sh, bash) or a download tool (curl, wget) sitting under a php-fpm, apache2 or httpd process.

  • ss -tnp

    Live server only. Lists open TCP connections with the process behind each one. Look for PHP or web server processes talking to addresses you do not recognise.

Command references: find, ps, ss and wp core verify-checksums.

3D secure vault, for preserving logs and a copy of the server

Before you clean

What to preserve before you clean anything

Without logs and a copy of the server, nobody can later say how the attacker got in, what they touched or whether they still have a way back. CISA's triage guidance for US federal agencies collects evidence before patching wherever possible, because patching can remove traces, and the NCSC advises investigating before systems are restored.

Keep this short. It is not a reason to delay the update: capture what you can quickly, then patch.

Logs

Web server access and error logs, PHP and PHP-FPM logs, and the system logs under /var/log. The FBI's PHP2Shell notice asks for web server and PHP logs to be kept, and CISA's incident guidance advises archiving /var/log. If your host holds logs you cannot reach, ask it to keep them.

A copy or image of the server

A full snapshot or disk image if your host or platform can make one; failing that, a complete copy of the site's files and a database export. WordPress.org advises one last snapshot before cleaning, even of an infected site.

What is running right now

The process list and open connections from the commands above, copied off the server. CISA's triage guidance puts volatile data first, because a restart, a patch or an early clean-up can make it disappear.

Suspicious files, copied rather than deleted

Take a copy of anything you find before it is removed, along with its location. Deleting the only copy throws away evidence of what the attacker was doing.

A written record

What you noticed, when (with the time zone), and every action taken since, by whom. Both WordPress.org and the NCSC recommend starting this log straight away.

Three things to avoid

  • Switching the server off. The NCSC notes that shutting a system down can lose evidence, while cutting its network connection can preserve it.
  • Visiting or probing the attacker's addresses. CISA counts touching attacker infrastructure among the common mistakes in incident handling.
  • Treating the symptom as the cure. Removing one web shell without finding how it arrived leaves the way in open.

Sources: NCSC, immediate activities after a disruptive attack, CISA BOD 26-04 triage guidance, CISA AA20-245A and FBI I-102326-PSA.

First steps

What to do before and after you patch

If you can patch today

  1. Capture the process list and open connections, copy the logs, and take a snapshot if your host allows it.
  2. Update PHP to a fixed release or your supplier's fixed package. How to update PHP
  3. Confirm the fixed version is the one actually serving pages. Check your PHP version
  4. Work through the signs above for the period before the update.

If you cannot patch straight away

  1. Decide whether to restrict access or take the site offline, as the NCSC's fourth action suggests. Should I take my website offline?
  2. Apply the PHP project's interim settings, knowing they are partial. The interim settings
  3. Before the upgrade or mitigation, check the server for compromise and backdoors, with an assured provider if you need one (the NCSC's fifth action).

After patching

  1. Look again for unexpected files and accounts. The update removed neither.
  2. If anything is found, rebuild from a known-clean source: a backup from before the compromise, or a fresh copy of the same software version. WordPress.org suggests replacing wp-admin and wp-includes this way.
  3. Once the site is clean, change every password and key: hosting panel, SFTP, database and admin logins. On WordPress, new secret keys in wp-config.php sign everyone out.
  4. Check your reporting duties. A personal data breach likely to put people at risk goes to the ICO within 72 hours of becoming aware of it. You can also report the incident to the NCSC, though that does not meet any legal duty.
  5. Keep watching for the same signs. Part of any investigation is establishing whether the attacker still has access.

Get help

When to bring in an incident response provider

If you find signs of compromise, or are not confident looking for them, the NCSC's advice is to use an assured Cyber Incident Response provider. Call one before the clean-up starts, while the evidence is still there.

3D lifebuoy held out from above, for the NCSC's assured providers

The NCSC's list of assured providers

The NCSC's Cyber Incident Response scheme assures providers at two levels, Standard and Enhanced. Providers assured at Enhanced can also take on Standard-level work.

Find an assured provider on ncsc.gov.uk
3D team beneath a trophy, for incident response help

CyPro incident response

CyPro's cyber incident response service is one option. CyPro Ltd operates this site.

CyPro cyber incident response
3D cloud server with a shield, for help from your hosting provider

Your host

On shared or managed hosting, tell your host early. A compromise can reach beyond one site on shared servers, and the host may hold logs and snapshots you cannot see.

3D magnifying glass with a 24/7 badge, for monitoring once you are clean

Monitoring once you are clean

The process and network signs on this page are worth watching continuously, not just once. A 24/7 security operations centre service is one route, for example 24-7soc.com.

24-7soc.com

Quick answers

Compromise questions, answered

How do I know if my PHP site has been hacked?

Look for PHP files nobody put there, especially in upload, cache or temporary folders; core or theme files that differ from a clean copy; admin accounts no one created; PHP processes starting shells or downloading tools; and connections the server never normally makes. No single sign proves a compromise, and finding none does not prove the server is clean.

I have already patched PHP. Do I still need to check?

Yes, if the server was reachable from the internet before the update. The update stops new attacks through PHP2Shell, but it does not remove a web shell or an account an attacker added earlier. CISA's catalogue entries for both flaws call for forensic triage as well as the fix.

What is a PHP web shell?

A script or snippet of code planted on a web server that lets an attacker run commands, or pull out data, simply by sending requests to the website. Because it sits among the site's real files and talks over normal web traffic, it can be hard to tell apart from legitimate code.

Should I delete a suspicious file as soon as I find it?

Copy it first and note where it was. Then work out how it got there. CISA lists fixing only the symptoms, rather than the root cause, among the common mistakes in incident handling: if the way in is still open, the attacker can put the file straight back.

Do I have to report a compromised website?

If personal data was involved, possibly. Under UK GDPR, a personal data breach that is likely to put people's rights and freedoms at risk must be reported to the ICO without undue delay and within 72 hours of becoming aware of it. Separately, the NCSC accepts reports of cyber incidents, but reporting to the NCSC does not meet any legal reporting duty.

Can I just restore yesterday's backup?

Only if you are confident the backup was taken before the compromise; a backup made afterwards may carry the backdoor with it. The NCSC's incident guidance asks whether backups are intact and uncompromised before relying on them. Make sure the server is running a fixed PHP release before the restored site goes back online.

3D rocket illustration above the call to find every exposed PHP server

Know your exposure

Find every PHP server you run

Patching the server you know about is the easy part. A vulnerability scan finds the forgotten staging site, the old microsite and the appliance with PHP inside, then tells you which ones are still exposed.

Find Every Exposed PHP Server Book a Free Consultation