# Detecting and removing webshells

> Detect webshells after PHP2Shell: find suspicious PHP files, processes and connections, preserve evidence and have backdoors removed properly.

Source: https://phpsos.de/en/ratgeber/webshell-erkennen/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**In short:** You can detect a webshell by new or modified PHP files in unusual places, by foreign processes of the web server user and by unusual connections. Preserve evidence before you delete anything, and restore the code from a clean source. A patch alone does not remove a backdoor.

## Why webshells matter after PHP2Shell

The vulnerabilities CVE-2026-109618 and CVE-2026-109619 in PHP itself allow remote code execution without authentication. An obvious goal after a successful attack is a permanent backdoor, that is, a webshell. It remains even if PHP has been updated in the meantime.

According to media reports, a first attack attempt was observed as early as 17 October 2026, and the patches followed on 21 October. Anyone who was vulnerable during this period should look specifically. No confirmed indicators of compromise have been published so far. The search therefore relies on behavioural anomalies, not on a ready-made list.

> **Act now:**
> If you find a webshell on a server holding customer data: do not delete anything in haste. First preserve evidence, then isolate the server and plan the further handling.

## How to detect a webshell: checking files

Most webshells are PHP files in the web directory. Conspicuous are files that were created or changed after 17 October, PHP files in upload and cache folders, and files with obfuscated code. The following commands change nothing; they only list:

```bash
# PHP files modified since 17 Oct 2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls

# PHP files in upload, cache or tmp folders
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls

# Typical obfuscation: eval combined with decoding
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"

# Unusually long lines often point to packed code
grep -rlE ".{3000,}" /var/www --include="*.php"
```

Hits are indications, not proof. Some plugins legitimately use encoded code. Compare suspicious files with the vendor's original package. The most reliable method is a comparison against checksums or a version control system such as Git:

```bash
# Deviations from the last known state in the Git repository
git -C /var/www/projekt status --porcelain
```

A timestamp can be forged. Do not rely on a file's modification date alone.

### Which characteristics make a file suspicious

| Characteristic | Why it stands out |
|---|---|
| PHP file in an upload or images folder | Only media should be stored there |
| Double extension such as `.jpg.php` or `.php.png` | Disguise as a harmless file |
| Very long lines without line breaks | Typical of packed or encrypted code |
| File name similar to a core file but not in the original package | Camouflage in a familiar environment |
| Owner or permissions differ from neighbouring files | File was created by another route |

The more characteristics coincide, the higher the likelihood of a find. Open suspicious files only as text, never through the browser, because a request via the website would execute the code.

## Checking processes, connections and cron jobs

An active webshell often leaves traces outside the file system. The web server user, such as `www-data`, `apache` or `nginx`, does not normally start shells, network tools or compilers.

```bash
# Processes of the typical web server users
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"

# Open network connections with the associated process
sudo ss -tunap | grep -E "php|www-data|apache|nginx"

# Scheduled tasks of the web server user
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
```

Conspicuous are permanent outgoing connections to unknown destinations, processes with cryptic names and cron jobs that download files from the internet. Also check the access logs for requests to files that did not exist before. How to do this is described in the guide [Analysing web server logs after an attack](https://phpsos.de/en/ratgeber/logfiles-auswerten/).

## Preserve evidence before you remove anything

Anyone who deletes first loses the answers to the most important questions: how did the attacker get in, what did they see, which data is affected? You need these answers for a possible GDPR notification, for insurers and for deciding whether other systems are at risk.

A sensible order:

1. Document the state: process list, network connections, logged-in users.
2. Copy suspicious files and logs with a checksum, without opening or executing them.
3. If possible, create an image of the system or a snapshot of the virtual machine.
4. Take the server off the network or restrict access heavily.

For systems with sensitive data or a possible legal dispute, the backup should be made in a forensically sound way. Background on this is under [IT forensics after a web server attack](https://phpsos.de/en/leistungen/it-forensik/).

## Removing webshells properly

Deleting a single file is rarely the end. Attackers often create several points of access: further files in hidden places, entries in configuration files such as `.htaccess` or `.user.ini`, new admin accounts in the application, or cron jobs. A reliable cleanup follows these steps:

- Bring PHP to a fixed version (8.5.12, 8.4.27, 8.3.36, 8.2.35 or a confirmed backport) and restart all PHP processes.
- Rebuild the application code from a clean source instead of repairing individual files.
- Carry over only checked content such as uploads and the database, and search there specifically for planted code.
- Change all credentials: database, SSH, FTP, admin accounts, API keys.
- Limit the web server's write permissions to the necessary minimum and prevent PHP execution in upload folders.

WordPress has its own typical hiding places, which the guide [Finding backdoors in WordPress](https://phpsos.de/en/ratgeber/backdoor-wordpress-finden/) describes. Afterwards the website should be monitored more closely for a while to notice renewed access early.

## How does PHP SOS help?

- We secure logs, files and system state in a traceable way before anything is changed.
- We search for backdoors in files, database, cron jobs and configuration, and classify what we find.
- We rebuild the application from a clean source, change credentials and harden the server.
- We document the incident until it is closed, as a basis for notifications and insurers.

The process of a cleanup is described in the service [Having malware and webshells removed](https://phpsos.de/en/leistungen/malware-entfernung/).


## Frequently asked questions

**What is a webshell?**  
A webshell is a planted file, usually PHP, through which attackers can control the server remotely. It often disguises itself as a harmless file with an inconspicuous name and stays active even after an update.

**Does an antivirus scanner find every webshell?**  
No. Scanners detect known patterns; new or heavily obfuscated variants slip through. For PHP2Shell, moreover, there are no published, confirmed indicators of compromise, so behavioural analysis matters more than a signature list.

**Is it enough to delete the file I found?**  
Usually not. Attackers often create several points of access, such as further files, cron jobs or new admin accounts. Without a root-cause analysis and a change of all credentials, renewed access is likely.

**Do I have to report anything after finding a webshell?**  
If personal data may be affected, a reporting duty under the GDPR may apply, as a rule within 72 hours. Clarify this with your data protection officer or a lawyer; this is not legal advice.

## Sources

- [php.net: security announcements](https://www.php.net/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI: German Federal Office for Information Security](https://www.bsi.bund.de/)
- [GDPR Art. 33: notification to the supervisory authority](https://dsgvo-gesetz.de/art-33-dsgvo/)