Most WordPress hacks do not end with the attacker stealing a password and logging in through wp-admin. That would be relatively easy to detect and stop. The more dangerous attacks end with the attacker planting a web shell — a small PHP file, hidden somewhere inside your WordPress installation, that gives them direct access to your server's operating system whenever they want it.
This is what the security community calls a WP2Shell attack: WordPress as the entry point, server access as the destination. If you run a WordPress site and have never thought about this, your site is almost certainly not protected against it.
What Is a Web Shell?
A web shell is a PHP script — sometimes just a few lines, sometimes hundreds — that accepts commands through an HTTP request and executes them on the server. It behaves like a remote terminal session, except it is accessed through a browser or an automated script, and it requires no SSH credentials, no VPN, and no login in the conventional sense.
From a planted web shell, an attacker can read any file the web server has access to, write or overwrite files anywhere on the server, execute system commands, connect outward to other servers, create new PHP backdoors in multiple locations, and — critically — return to the site indefinitely without needing the original vulnerability that got them in.
That last point is what makes web shells so dangerous. They are persistence mechanisms. The initial attack is the breach. The shell is what converts that breach into long-term, silent control.
How Attackers Get Into WordPress
There is no single method. The WordPress ecosystem is enormous — tens of thousands of plugins and themes, many of them with no active maintainer — and the attack surface grows with every outdated component you leave installed.
Vulnerable plugins and themes
This is the most common entry point by a significant margin. WordPress plugins regularly contain security vulnerabilities: arbitrary file upload flaws, SQL injection, remote code execution bugs, and authentication bypasses. When a researcher publishes a CVE for a popular plugin, automated scanners begin testing every exposed WordPress installation within hours. Sites running the vulnerable version get flagged; the exploit runs; a shell goes up.
You do not need to be targeted. These scans are indiscriminate and global. A plugin installed on a site in 2022 and forgotten is just as exposed as a plugin actively maintained by a negligent developer.
File upload vulnerabilities
WordPress allows content uploads by design — media libraries, attachment handling, plugin-extended upload forms. When those upload endpoints lack proper file type validation, an attacker can rename a PHP file as an image (.php.jpg, or sometimes just .php depending on server misconfiguration) and upload it. Once the file is on the server and accessible via URL, it can be executed as PHP. The shell is live.
Compromised admin credentials
If an attacker can log into WordPress as an administrator, they can install a plugin — and a plugin is just a ZIP file containing PHP code. Legitimate-looking plugin installations that carry shell code are a well-documented technique. Credentials obtained through phishing, credential stuffing from data breach dumps, or weak passwords all enable this path.
Outdated core files
WordPress core vulnerabilities are patched quickly, but only for sites that update. Sites on old versions of WordPress core have known, publicly documented vulnerabilities. Some of these allow unauthenticated remote code execution. They are trivial to exploit automatically.
What Happens After the Shell Is Planted
This is where site owners significantly underestimate the scope of the problem.
A planted shell is not just a way to deface your homepage or send spam from your domain — though both of those happen routinely. An attacker with server-level access can do all of the following, often without you noticing for weeks or months:
Silent data exfiltration
Your WordPress database contains the personal data, email addresses, and order histories of everyone who has ever used your site. With a shell, this data can be compressed, downloaded, and sold without leaving any visible trace on the public-facing site. Many breaches of this kind are only discovered when the data appears for sale, or when a customer's data is used fraudulently.
SEO poisoning
Attackers inject hidden links and pages into your site to redirect link authority to pharmaceutical, gambling, or adult content sites. These pages are often hidden from logged-in users and administrators, serving different content to Googlebot than to human visitors. Your rankings decline. Your domain's reputation suffers. Google may flag your site as harmful. This damage persists even after the injected content is removed, because Google's trust signals recover slowly.
Server resource abuse
Your hosting account may be used to run cryptocurrency mining operations, participate in distributed spam campaigns, or serve as a relay node for attacks against other servers. This can lead to your hosting account being suspended — which is often how site owners first discover that something went wrong.
Lateral movement
If your server hosts multiple sites — a common arrangement on shared hosting — a shell on one site can become the entry point for every other site on the same server. A compromise of a small, low-traffic WordPress installation can cascade to a high-value WooCommerce store on the same account.
Persistent backdoors
A skilled attacker does not leave one shell. They leave several, in multiple locations, sometimes encoding or obfuscating the code so that a file scanner cannot detect them. Cleaning up after a shell infection requires knowing what a clean WordPress installation looks like, having access to file integrity data from before the breach, and systematically checking every location where PHP can be executed. Missing even one file means the attacker still has access.
How to Recognise the Signs
Web shells are designed to be invisible to casual inspection. You will not see an obvious warning. But there are signals that something is wrong:
- Unexplained files in
/wp-content/uploads/— This directory is designed to hold media files, not PHP. Any.phpfile here is almost certainly malicious. - Server resource spikes with no corresponding traffic increase — Mining operations and spam campaigns run continuously and silently, consuming CPU and memory without any user-visible cause.
- Google Search Console security alerts — Google actively scans for malware and SEO spam injections and will flag your site. By the time the alert arrives, the infection has usually been in place for some time.
- Unexpected outbound connections in server logs — Shells frequently connect to attacker-controlled servers to receive instructions or exfiltrate data. This traffic appears in server-level network logs if you know to look.
- Modified
wp-config.phpor core file timestamps — WordPress core files should not change between updates. If core file modification timestamps do not align with known update events, they have been tampered with.
Most site owners discover none of these until they are told by their hosting provider that the account has been suspended, or until a customer reports that they have been redirected to a malicious site.
What Prevention Actually Requires
There is no single setting or plugin that prevents WP2Shell attacks. Prevention is a combination of active maintenance and hardening, applied consistently.
Every unpatched plugin is a potential entry point. Every plugin that has not been updated in two years may have known, unpatched vulnerabilities that the original developer will never fix. File permissions need to be set correctly so that PHP cannot be executed in upload directories. HTTP headers and WAF rules add additional layers that raise the cost of automated exploitation. And file integrity monitoring — tracking what files exist and when they were last modified — is the mechanism that catches an intrusion before it becomes a months-long silent compromise.
None of this happens automatically. It requires someone to care about it, to review it regularly, and to act when something changes. That is what WordPress maintenance actually is, underneath all the marketing language.
The Cost of Getting This Wrong
Removing a web shell is not complicated if you catch it early and have a clean backup from before the breach. It is extremely expensive if you do not. Forensic analysis of a months-old compromise, rebuilding SEO reputation, managing customer notifications under GDPR breach obligations, and dealing with hosting suspension are not quick fixes. For businesses that depend on their website for revenue, even a few days of downtime or reputational damage from a Google malware flag can cause real, lasting harm.
The sites that get quietly compromised and left that way — serving spam, leaking data, being used as attack infrastructure — are almost always sites that no one is actively maintaining.