In short: A webshell is a small file through which a stranger can remote-control your server. Anyone who has found one is very likely affected and should get in touch immediately. Do not delete it, do not open it, secure it first. We clarify remotely how it got onto the server and whether there is further access, and we clean up the server.
Do not delete anything and do not rebuild anything right now. The webshell itself also stays in place for now so that it can be secured. Affected? Call us or write to us on WhatsApp, or report the find via Report an emergency.
You Found a Webshell: What Does That Mean?
A webshell is a PHP script (or a script in another server language) that accepts commands from outside. With it, attackers can read files, download data, load further malicious code and reach other systems. The file is therefore rarely the goal of the attack. It is the backdoor that an intruder leaves so that he can come back.
That has two consequences. First: someone already had write access to your server or could run code. Second: the file you found is probably not the only one. On top of that comes what is often not known: since when has it been there, and what was done with it in the meantime?
How to Recognize a Webshell
- a PHP file in a folder where none should be, such as uploads, cache, images or temporary directories
- file names that look like system files but do not belong to your software, or names with a double extension
- unreadable code with long character strings, encoding and functions for executing commands, see Recognizing obfuscated PHP code
- a modification date that does not match your updates
- requests to this file in the logs, often from foreign addresses and with POST requests
- web server processes that start a shell, as described in Warning sign: the web server starts a shell
How to interpret finds correctly is covered in PHP files in the upload folder and in detail in Recognizing and removing webshells.
What to Do Right Now
- Do not open the file and do not execute it. No tests in the browser.
- Do not delete it and do not move it. Change neither the content nor the timestamp.
- Note down: full path, file name, time of discovery, who found it and with what.
- Secure the file and its metadata: A copy with owner, permissions and timestamps. Read-only commands are enough, for example:
bash
stat /pfad/zur/datei.php
sha256sum /pfad/zur/datei.php
- Keep the logs: Do not let access and error logs of the web server and PHP be overwritten. Trade press advises keeping server logs from 20 October 2026 onward.
- Isolate the server if necessary: If you suspect that data is leaking, take the site offline. How to preserve evidence while doing so is described in Secure evidence before you reinstall.
- Inform us before passwords are changed or files are cleaned up.
How Does PHP SOS Help?
- Assess the situation: What was found, where, when and by whom? Which systems are on the same server?
- Secure and close: We secure the find, files, database and logs, and block access that looks suspicious.
- Check and clean up: We look for further webshells, changed core files, hidden cron jobs, foreign admin accounts and unknown SSH keys, and remove them. The approach corresponds to the service Removing malware and webshells.
- Harden and report: We name the probable entry point, close it and secure the server. You receive documentation with findings and a timeline.
How Did the Webshell Get onto the Server?
Typical routes are outdated plugins or extensions, insecure file uploads, stolen credentials and vulnerabilities in the server's software. Since the publication of PHP2Shell, another possibility has been added: PHP without the fixes from 8.5.12, 8.4.27, 8.3.36 or 8.2.35 can be abused remotely to execute code. There are no confirmed indicators of compromise for it; detection relies on behavior. Whether the entry in your case was via PHP2Shell or another route can only be derived from the traces, and we mark what is proven and what is assumption. How logs help is shown in Analyzing web server logs.
A patch does not remove an existing webshell. Protection against future finds belongs to it as well: Prohibiting PHP execution in upload folders prevents many cases. Also keep in mind the limits of malware scanners: a scan with no findings is not an all-clear signal.
If you need to know exactly what happened, for example for insurers or authorities, IT forensics may make sense.
And If the Webshell Comes Back After Deletion?
This happens often and usually has two causes. Either there is at least one further backdoor that recreates the find, or the entry point is still open and the attacker simply comes back. Neither can be solved by deleting repeatedly. That is why we look for the full set of changes: new and changed files, entries in the database and configuration, scheduled tasks, accounts. A list of recently changed files is a sensible start, but does not replace the check by specialists.
What You Should Send Us
- path and name of the file, preferably as a copy with timestamps (we agree the way of handing it over)
- excerpts from the access logs around this file, if you have access
- type of server, host, PHP version and operating mode, if known
- which websites and applications run on the server
- when updates, uploads or changes last took place
Why PHP SOS
We work Made in Germany and, together with our partner network of cyber professionals, have specialized in IT security for over 25 years. One contact leads you through the incident. We work remotely with no travel across Germany and Europe, document every step and make no promises that nobody can keep. We stay with you until the incident is closed and documented.
Affected? Call Us. We Help.
A webshell that has been found is a warning sign that you should take seriously. Get in touch now, by phone or WhatsApp, and we take over from the first message. Report an emergency now
Frequently asked questions
I found a webshell. May I simply delete the file?
Please not as the first step. The file shows when and with what the attacker came in. Secure it first, including timestamps and owner, and then it is removed in a targeted way. Anyone who only deletes usually leaves further access behind.
Should I open the suspicious file in the browser to see what it does?
No. Opening it can run the malicious code and blur further traces. Examine the file read-only and preferably on a copy.
Is a malware scanner enough to find all webshells?
Not reliably. Scanners detect known patterns, but obfuscated or newly built webshells escape them. A clean scan does not prove that nothing is left.
How do I know how long the webshell has been on the server?
Clues come from the modification date, access and error logs, and comparisons with other new files. Timestamps can be forged, though. That is why we assess several sources and mark what is proven and what is assumption.
Do I have to report the find?
As soon as personal data may be affected, a notification to the supervisory authority may be required. Data protection officers or lawyers advise on that; we supply the technical facts.