How web shells end up on WordPress sites — and how to harden yours

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. The original post gave step-by-step instructions for planting a malicious shell on a WordPress site — that walkthrough has been removed entirely. This rewrite explains how attackers get shells onto sites so you can detect and stop them.

What is a web shell, and why do attackers want one?

A web shell is a malicious script (often PHP on WordPress hosts) that an attacker places on a compromised server. Once in place, it gives them a remote interface to run commands, browse files, and pivot to other sites on the same server. For defenders, a web shell on your server means the attacker already had a way in — the shell is the foothold, not the break-in.

How shells get onto WordPress sites

Attackers rarely start with the shell. They start with an opening, then use it to drop one. The common paths:

• Vulnerable plugins and themes. Outdated or abandoned plugins with file-upload or code-execution flaws are the single most common entry point. Attackers scan the internet for known-vulnerable versions automatically.
• Weak or reused admin credentials. Brute-forced or phished wp-admin logins give attackers the same file-editing powers the old post abused (Appearance → Editor, plugin uploads). Enforce strong passwords and MFA.
• Unrestricted file uploads. Forms or plugin features that accept uploads without strict type validation let attackers place executable scripts where the web server will run them.
• Compromised hosting neighbors. On shared hosting, a shell planted on one site can sometimes reach others — another reason to isolate sites and choose reputable hosting.
• Nulled/cracked themes and plugins frequently ship with backdoors pre-installed. Never use them.

Detection: signs of a shell in your logs and files

Catch the foothold early. Watch for:

• New or modified PHP files in uploads directories, theme/plugin folders, or odd locations (e.g., files with random names, or recently modified core files). File integrity monitoring (FIM) turns this into an automatic alert.
• Suspicious request patterns: POST requests to unfamiliar .php files, requests with encoded/obfuscated parameters, or repeated hits to a single odd URL.
• Unexpected outbound connections from the web server process — shells often "phone home" or download second-stage payloads.
• Admin activity anomalies: logins from unusual locations, new admin users you didn't create, or theme/plugin editor usage outside change windows.
• Server-side clues: processes spawned by the web server user, spikes in CPU at odd hours, or antivirus/malware scanner hits on the document root.

Hardening: make your site a hard target

• Update relentlessly: WordPress core, themes, and plugins — promptly, and remove anything unused or abandoned.
• Least privilege: file permissions that prevent the web server from writing where it shouldn't; disable the theme/plugin file editor; run PHP with functions like exec and shell_exec disabled where possible.
• Lock down uploads: restrict allowed file types, store uploads outside the web root or deny script execution in upload directories via server configuration.
• Strong authentication: MFA on all admin accounts, limit login attempts, and restrict wp-admin/wp-login access by IP where feasible.
• WAF + monitoring: a web application firewall to block known exploit patterns, plus centralized logging and FIM so tampering triggers an alert, not a surprise.
• Backups you can restore: tested, offline backups are your fastest recovery path if a shell is found — assume the whole install is untrusted and rebuild clean.

If you find a shell

Don't just delete the file — treat it as an active incident: take the site offline or isolate it, preserve logs, identify the entry point (outdated plugin? weak credentials?), rebuild from a known-clean backup or fresh install, rotate all credentials and secrets, and close the hole before going back online.