What Is a Web Shell and How Does It Get on a Server?

A web shell is a small script that an attacker places on a web server so they can run commands on it through ordinary HTTP requests. If you are asking what is a web shell in practice, it is often a single line of PHP, ASP.NET or JSP sitting in a folder the server already executes. It runs with the web server account's permissions, survives patching, and looks like normal web traffic, which is why it is the most common foothold after a web application flaw.

What is a web shell?

A web shell is a server-side script that accepts input from a web request and executes it as a system command or code on the host. It gives an attacker remote control of the server through the same port and protocol the site already uses.

The October 2026 attacks on Nextcloud show how little code is involved. Shells recovered from servers hit through Collabora CVE-2026-110447 were one line long: they took a command from a URL parameter, ran it and printed the output. Nothing about that file needs a separate listener, a new open port or an installed service.

How does a web shell get onto a server?

A web shell gets onto a server through any flaw that lets an attacker write a file into a directory the web server executes. Command injection, insecure file uploads, path traversal file writes and stolen admin credentials are the usual routes.

The common entry points:

• Command injection. The attacker runs one command that writes the shell to disk. That is what happened with the Nextcloud Built-in CODE Server app: the injected command created shx*.php files inside the app's own folder.
• File upload flaws. An upload form that does not check file type or destination lets the attacker upload the script directly.
• Path traversal writes. A bug that writes attacker-controlled content to an attacker-chosen path drops the shell into the web root.
• Stolen admin access. Many content management systems let administrators install plugins or edit templates. With a stolen password, the attacker uses that feature as intended.

Once the first shell works, attackers often add more under different names. Nextcloud administrators found shx, shrf and Nx_ prefixes on affected servers, so hunting by one name pattern misses the rest.

Why do attackers use web shells?

Attackers use web shells because they turn a one-time exploit into persistent access that survives the patch. The vulnerability gets fixed, but the file stays and keeps answering requests until someone deletes it.

They also blend in. Requests go to the site's normal HTTPS port, often to a path inside a legitimate application folder, and the process tree shows the web server running a child command, which many monitoring tools do not flag. From there the attacker can:

• Read configuration files that hold database passwords and API keys.
• Browse whatever data the web server account can reach. On the Nextcloud servers, attackers searched for password manager databases and cryptocurrency wallet files.
• Download further tooling, open a reverse connection, or attempt privilege escalation to root.

How far they get depends on what that one account can read, which is the subject of why your web server account should not read your secrets.

What does a web shell look like on disk?

Most web shells are short scripts in the language the server already runs: PHP on Linux web stacks, ASPX on IIS, JSP on Java application servers. Some are one line; others are full file managers with a login page.

Signs worth checking:

• A script file that is not part of the application's signed or released file list.
• A recent modification time inside a folder that only changes during upgrades.
• Calls to functions that execute system commands, such as shell_exec or system in PHP, especially fed directly from request parameters.
• Encoded or compressed blobs that decode at runtime.

Not every shell lives on disk. Some frameworks allow code to be loaded straight into memory, which leaves no file to find. For that variant, see how to hunt for in-memory webshells that leave no file on disk.

How do you detect and remove a web shell?

You detect a web shell by comparing application files against a known-good list and by reviewing access logs for requests to unexpected scripts. You remove it by deleting the file, closing the entry point and checking for anything else it was used to plant.

A practical order:

1. Patch or remove the vulnerable component first, so a new shell cannot be written while you clean up.
2. Run the application's integrity check if it has one. Nextcloud reports unexpected files as EXTRA_FILE results; WordPress and many Linux packages can verify checksums.
3. Search access logs for requests to the suspicious files and for the requests that created them. The source addresses tell you when access started.
4. Delete the shells and look for persistence outside the web root: cron entries, new accounts, SSH keys, modified startup scripts.
5. Rotate every secret the web server account could read, then monitor for reuse.

For a Nextcloud server specifically, our guide on how to check for Nextcloud web shells applies these steps with the commands Nextcloud provides.

How do you prevent web shells?

You prevent web shells by keeping the web server account from writing to directories it executes, and by patching internet-facing applications quickly. If the account cannot write a script anywhere the server will run it, most file-drop attacks fail.

Concrete controls: make application code directories read-only to the web server user where the application allows it, block script execution in upload and data directories, keep file integrity monitoring on the web root, and alert on the web server process starting shells or download tools. Remove optional components you do not use, because an installed but unused app is still reachable code.