In this guide (6)
A webshell is one of the most dangerous tools an attacker can install on your site — and one of the hardest to detect.
It's not a virus in the traditional sense of the word. It doesn't slow down the site, doesn't show messages, doesn't encrypt files. A webshell sits silently on the server, invisible to users and often to security plugins, waiting for the attacker to decide to use it.
This article explains what a webshell technically is, how it gets installed, how it's hidden, and what is architecturally needed to block it before it reaches the server.
What a webshell technically is
A webshell is a file — typically PHP, but also ASP, JSP or Python — uploaded to a website's server that allows the attacker to execute commands on the underlying operating system through the browser.
In practice: the attacker opens a browser, navigates to the URL of the installed webshell file (for example https://yoursite.com/uploads/image.php), and gets an interface from which they can execute commands on the server as if they had direct access to the command line. They can read files, modify them, exfiltrate data, install other tools, create administrator accounts, use the server as a relay to attack other systems.
The simplest possible webshell in PHP is literally one line:
<?php system($_GET['cmd']); ?>This file, if uploaded to the server and reachable via browser, allows any operating system command to be executed by passing it as a URL parameter. Real webshells are much more sophisticated — full interfaces with file management, database access, reverse shell, all obfuscated to avoid detection.
How a webshell is installed
A webshell does not install itself. It requires the attacker to have already found an entry point into the system. There are three most common vectors.
File upload without proper validation
The most frequent vector on WordPress is uploading files through forms or upload areas that do not correctly validate the content. A plugin that only checks the file extension — verifying that it's named .jpg instead of .php — can be tricked with a file that has a seemingly innocuous extension but contains PHP code in the body.
The most sophisticated technique is the polyglot file: a file that has valid magic bytes (the first bytes that identify the format — in the case of JPEG they start with FF D8 FF) but contains PHP code embedded in the rest of the content. The browser interprets it as an image, the server executes it as PHP if the configuration allows it.
A recent and documented case of compromise that leads to full control of the site is the PHP2Shell (CVE-2026-109618/109619) vulnerability: the dedicated guide explains who is at risk and what to do right away.
SQL injection with file write
If a SQL injection attack is successful and the database has write permissions on the filesystem, the attacker can use MySQL's SELECT INTO OUTFILE function to write a PHP file directly to the server. An upload form isn't even needed — a malicious SQL query that isn't blocked is enough.
Vulnerabilities in plugins or themes
Unpatched WordPress plugins with Remote Code Execution (RCE) or Local File Inclusion (LFI) allow the attacker to upload or execute arbitrary code on the server. Vulnerabilities of this kind are discovered and published regularly — and between the moment of publication and the moment the administrator updates the plugin, the site is exposed.
How it is hidden
A skilled attacker does not leave the webshell in an obvious location. The most common concealment techniques are those that make detection difficult even for those who know what to look for.
Code obfuscation
The webshell code is encoded in Base64, broken up into multiple variables, concatenated with string functions, or compressed — so that the file does not contain recognizable strings such as system, exec or passthru. An antivirus or scanner looking for these strings finds nothing.
Example of basic obfuscation:
<?php
$a = base64_decode('c3lzdGVt');
$a($_GET['c']);
?>The decoded code executes system($_GET['c']) — but none of the dangerous strings appear in plain text in the file.
Deceptive file extensions and names
The webshell is renamed with names that seem innocuous: config.php, cache.php, wp-options.php, thumb.php. In a WordPress installation with hundreds of PHP files spread across dozens of folders, one extra file is practically invisible without a systematic scan.
Falsified timestamps
Attackers modify the timestamp of the webshell file to make it look like a pre-existing file — the modification date appears identical to the other files in the same folder. Those who check the modification date to identify recently added files find no anomalies.
Iframes and injection into existing files
Instead of creating a new file, the attacker can inject the webshell code into already existing PHP files — modifying functions.php, index.php or any file already present. The resulting file is legitimate in structure but contains additional code hidden at the bottom or fragmented in the body.
Suspect your site has already been compromised?
In most cases a compromise stays invisible for months:
the site works, but it sends spam, steals data from forms or is used to attack other sites.
We check your site for free and tell you what we found:
Response within 24 hours. If it's urgent, call
0835 239514
Request a security check →
Why WordPress security plugins are not enough
Wordfence and similar tools scan files looking for known webshell signatures. This approach has structural limitations that are important to understand.
Signatures are updated after the discovery of new webshells — not before. A new or sufficiently obfuscated webshell doesn't match any signature in the database and is not detected. Wordfence free receives signature updates 30 days later than the premium version — a window during which new webshells go unidentified.
Moreover, scanning happens after the file is already on the server. The problem isn't detecting the webshell once it's installed — it's blocking it before it arrives. A periodic scan that finds the webshell three days after installation means three days of open access to the server.
The correct architectural solution is to block malicious file uploads at the moment of upload — not to scan the filesystem looking for what has already gotten through.
How to block a webshell before it reaches the server
Effective blocking requires analysis of the file's content at the moment of upload, not just its extension or name. The six checks that separate a secure upload system from a vulnerable one are the ones KeideaCMS applies natively to every uploaded file.
1. File name validation
Null bytes, double extensions (shell.php.jpg), control characters, and 80+ dangerous extensions blocked: not just .php, but also .phtml, .phar, .php5, .pht, .shtml and all the variants that PHP can execute.
2. PHP code detection in the content
Binary analysis of the file content looking for PHP tags (<?php, short tag <?, ASP tag <%) and dangerous functions (eval, system, exec, passthru, base64_decode) in files that shouldn't contain them. A .jpg file that contains <?php is blocked regardless of its extension.
3. Known webshell signatures
A database of signatures for the most widespread webshells: c99, r57, b374k, WSO, FilesMan, Alfa Shell, AnonymousFox, p0wny, weevely and 15+ others. The file is compared against these signatures before being accepted.
4. Shannon entropy analysis
Obfuscated code has statistically anomalous entropy compared to a legitimate file of the same type. Shannon entropy analysis — with a threshold at 7.2 on an 8.0 scale — identifies files with suspicious byte distribution, typical of compressed or encrypted code hidden in the content.
5. Base64 payload decoding
Base64 blocks embedded in the file content are searched for and recursively decoded. A payload obfuscated across multiple layers — Base64 inside Base64 inside an image file — is unmasked before the file is accepted.
6. Polyglot file detection
Verification that the file's magic bytes match the declared format and that the binary content doesn't contain PHP code embedded after the legitimate header. This is the most sophisticated check — and the one that blocks the hardest-to-detect attack technique.
These six checks are built into the core of KeideaCMS — they aren't an additional plugin that someone has to remember to update. KeideaCMS's complete security architecture, including the file scanning system, is documented here.
When a compromise happens again months later, the problem is rarely the single attack: it's the site's architecture that keeps exposing the same weak points. Cleaning up and putting the same system back online just means postponing the next incident. In those cases, rebuilding the site on different foundations costs less than years of emergency interventions.
What to do if you suspect a webshell is already installed
If the site has experienced unusual access, if you find PHP files in folders where they shouldn't be, if the server is consuming resources inexplicably, or if Google has flagged unusual content in indexed pages — the priority is containment, not diagnosis.
Immediate steps: isolate the site by taking it offline or restricting access by IP, make a complete backup of the current state (including the compromised site — needed for forensic analysis), and compare the filesystem with a backup from before the compromise, looking for added or modified files. Don't trust timestamps — use MD5 or SHA-256 hashes to compare files.
If the site handles personal data — and almost all business sites do — a compromise that allowed access to the database or files is a GDPR breach with an obligation to notify the Data Protection Authority within 72 hours. We've written an in-depth guide on WAF and structural protection that explains why prevention is the only effective response.
