wp2shell: How WordPress Compromises Turn Into Persistent Web Shells (And How to Stop It)

What "wp2shell" Actually Means

WordPress powers a huge share of the internet, and its plugin and theme ecosystem gives it an unusually large amount of code that was never audited to the same standard as WordPress core. That combination makes it one of the most common targets pentesters and real-world attackers alike test against - and the WordPress-specific playbook for it has enough shared shape that practitioners refer to the "get a shell on a WordPress box" step informally as wp2shell.

It describes an outcome, not a single script: whatever got the attacker their first foothold - a leaked admin password, a vulnerable plugin, an exposed upload form - the next move is almost always the same. Write a small PHP file to a web-accessible path, then use that file as a durable command-execution channel that doesn't depend on the original vulnerability still being exploitable. Once that file exists, the attacker's persistence is now decoupled from the bug that got them in - patching the original vulnerability does nothing if the shell is still sitting on disk.

The Three Chokepoints Every Path Runs Through

Notice that every row above collapses into the same two underlying failures: PHP is allowed to execute somewhere it shouldn't (uploads, media, cache directories), or something with file-write capability is trusted more than it should be (the editor, the plugin installer, an upload form). Close those two chokepoints and most of the table above stops working even if the initial vulnerability or credential compromise still happens.

The Editor: A Shell By Design, Not By Bug

The most direct route doesn't require a vulnerability at all. WordPress core ships with Appearance → Theme File Editor and Plugins → Plugin File Editor, which let any account with the edit_themes or edit_plugins capability (administrator by default) open and save arbitrary PHP files that live under the web root and execute on every request. This is a documented, intended feature - which is exactly why it's the first thing a pentester checks, and the first thing an attacker abuses the moment they get an admin session through any other means (phishing, credential stuffing, session fixation, a completely unrelated vulnerability).

Because it's a built-in feature rather than a bug, it has no CVE and no patch. The only fix is to turn it off.

Turning it off

Add the following to wp-config.php, above the line that reads /* That's all, stop editing! */:

Upload Endpoints: The Path Attackers Don't Need Credentials For

Plugins routinely add their own upload functionality - profile pictures, support-ticket attachments, import/export tooling, form builders. When that code validates a file by its declared MIME type or its extension string alone (rather than its actual content), an attacker can rename a PHP payload with an image extension, or append a null byte / double extension trick, and get code executed the moment the file is requested directly.

This is the highest-value target for an unauthenticated attacker because it skips the credential problem entirely. It's also the finding class continuous attack-surface monitoring is built to catch early: a new plugin version that reintroduces a fixed upload flaw, or a newly-installed plugin nobody vetted, shows up as new attack surface the moment it's exposed rather than at the next annual test.

What actually stops it

• Disable PHP execution in wp-content/uploads/ - an .htaccess rule (Apache) or a location block (nginx) that refuses to execute any script in that directory turns a successful upload into an inert file, regardless of what plugin let it through.
• Validate content, not extension - server-side MIME sniffing against the actual file bytes, not the client-supplied Content-Type header or filename.
• Store uploads outside the web root where feasible, and serve them through a script that enforces access control rather than direct static file serving.
• Keep plugins current and minimal - every installed plugin is attack surface whether or not it's actively used; deactivated-but-installed plugins are still readable, and sometimes still routable.

The Install Path: Once You Have Admin, Nothing Stops a "Plugin"

If an attacker reaches valid administrator credentials - through credential stuffing against reused passwords, a successful XML-RPC brute force, or simple phishing of a site owner - the plugin and theme installer accepts any zip file that looks superficially like a plugin. Nothing in core inspects the contents for a web shell disguised as a helper script, a cache-warmer, or a "license validator." This is why credential hygiene for WordPress admin accounts carries disproportionate weight: it isn't just account takeover, it's a direct path to full remote code execution the moment it succeeds.

xmlrpc.php deserves specific attention here. Its system.multicall method allows dozens or hundreds of username/password combinations to be tested in a single HTTP request, which defeats simplistic rate-limiting that only counts requests rather than authentication attempts within them. Unless a site has a specific, active need for XML-RPC (many pingback and remote-publishing integrations that once required it are legacy), disabling it removes a brute-force amplifier with no functional cost.

Detecting a Shell That's Already There

Because the point of a web shell is to persist past the vulnerability that created it, detection can't rely on "the bug is patched now, so we're fine." A hardening pass should always be paired with a look at what might already be sitting on disk.

• Diff against a known-good baseline. WordPress core and any plugin/theme from the official repository can be re-downloaded and compared file-for-file against what's actually deployed. Anything extra, or anything modified inside a vendor-supplied file, is a lead.
• Flag PHP where PHP shouldn't be. Any .php file inside wp-content/uploads/ is inherently suspicious - that directory should only ever hold media.
• Look for the usual shell signatures - eval(), base64_decode(), gzinflate(), and system()/shell_exec()/passthru() chained together, especially in files with generic or copied-legitimate-looking names.
• Check modification timestamps for files touched outside a known deployment or update window.
• Audit admin accounts and application passwords for anything that wasn't provisioned by your team - a shell is often paired with a freshly-created backdoor admin account as a fallback.
• Review outbound connections from the web server process; many shells phone home or are used to stage further tooling.

If any of the above turns something up, treat it as an active incident rather than a cleanup task: rotate every credential the compromised environment could reach, not just WordPress admin passwords, and assume the attacker had read access to wp-config.php - meaning the database credentials in it should be considered exposed.

The Hardening Checklist

For an environment running WordPress in production, the honest test isn't whether a scanner flags an outdated plugin version - it's whether a tester with no prior access can find a live path from the public internet to a shell on your server, the same way a real attacker would. That's what a manual web application penetration test is built to answer, and what continuous attack surface monitoring is built to keep answering as plugins, themes, and admin accounts change between engagements.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

Lorikeet Security helps modern engineering teams ship safer software. Our work spans web applications, APIs, cloud infrastructure, and AI-generated codebases — and everything we publish here comes from patterns we see in real client engagements.

Practical security, written by practitioners.