What Is a Web Shell? How the Attack Works and Defenses

A web shell is a malicious script that an attacker uploads to a web server so they can run commands on it remotely through a browser or a simple HTTP request. Once planted, a web shell gives the attacker a persistent backdoor: a way to execute code, browse files, steal data, and pivot deeper into the network, all disguised as ordinary web traffic to the compromised site. Web shells are typically written in the server's own language, such as PHP, ASP.NET, or JSP, so they blend in with legitimate application files.

Understanding what a web shell is matters because it is one of the most common outcomes of a web server compromise. Attackers rarely stop at exploiting a vulnerability; they plant a web shell to keep access even after the original hole is patched. MITRE ATT&CK tracks this as a distinct technique, Server Software Component: Web Shell (T1505.003), reflecting how routinely it appears in real intrusions. The recent Magento StyleSmuggler zero-day (CVE-2026-75650), for example, was used to drop a PHP web shell on compromised online stores.

How does a web shell get onto a server?

Through almost any flaw that lets an attacker write a file or inject code into the web application. Common paths include unrestricted file-upload features, remote code execution vulnerabilities, SQL injection that can write files, and exposed admin panels with weak credentials. The attacker places a small script in a web-accessible directory, then simply requests its URL to run commands. Because the shell lives inside the normal web root and speaks HTTP, its traffic often looks like ordinary requests to the site, which is a large part of why web shells are effective.

Why are web shells so hard to detect?

Because they hide in plain sight. A web shell is often just a few lines added to an existing file or a new file with an innocuous name in a directory full of legitimate scripts, and it communicates over the same HTTP or HTTPS the site already uses. More advanced variants run entirely in memory to avoid leaving a file on disk. Detection usually depends on spotting anomalies: unexpected new or modified files in the web root, unusual process activity spawned by the web server, or outbound connections and request patterns that do not match normal application behavior.

How do you defend against and remove a web shell?

Prevent the initial write by patching web application vulnerabilities quickly, locking down file uploads, and enforcing least privilege on the web server account so it cannot write to code directories. Use file-integrity monitoring to catch new or changed files in the web root, and watch for the web server process spawning shells or making unexpected outbound connections. If you find a web shell, assume broader compromise: the attacker had code execution, so removing the file is not enough. Rotate credentials and keys, hunt for additional backdoors and persistence, and investigate how the shell was planted so the entry point is closed.

Frequently asked questions

Is a web shell the same as a backdoor? A web shell is a specific kind of backdoor that lives on a web server and is controlled over HTTP. All web shells are backdoors, but backdoors also include other persistence mechanisms like malicious services, scheduled tasks, or implanted binaries that do not rely on the web server.

What languages are web shells written in? Usually whatever the server already runs, so PHP, ASP.NET (C# or VB.NET), and JSP (Java) are the most common. Using the server's native language lets the shell execute without extra dependencies and blend in with legitimate files.

Does finding a web shell mean I was breached? Yes. A web shell does not appear on its own; its presence means an attacker achieved code execution or file write on the server. Finding one should trigger full incident response, not just deletion of the file.

Our read

A web shell is the quiet second act of most web server compromises: the exploit gets an attacker in, and the web shell keeps them in. Because it hides inside legitimate files and normal web traffic, the organizations that catch web shells early are the ones watching for change and anomaly, not just for known-bad signatures. The durable lesson is that finding a web shell means assuming compromise and hunting accordingly, and that the real fix is closing the write path in the first place. Verifying that your web server cannot be made to execute attacker code beats trusting that it will not.

Technique mapping per MITRE ATT&CK T1505.003; detection guidance per CISA; CVE reference per the National Vulnerability Database. Sources linked above.

Related: What is privilege escalation? and What is a software supply chain attack?.