The Fake Plugin in Your wp-content: A Field Guide

In the site cleanups we perform at Kornet, one pattern shows up again and again: the infection the owner noticed (the spam redirect, the strange search results, the defaced page) traces back to a plugin directory the owner never installed. Not a vulnerable plugin. A fake one: a folder created by the attacker, wearing a plausible name, whose only job is to keep the attacker inside.

This guide explains why plugins are the disguise of choice, the five structural tells that give fakes away, and a five-minute check you can run on your own site today. You don't need to be able to read PHP to use any of it.

Why a plugin is the perfect disguise

Three properties make wp-content/plugins ideal camouflage:

• WordPress runs plugins automatically. Code inside an active plugin executes on every page load, with the site's full permissions. The attacker doesn't need to touch core files, which is exactly where owners and many scanners look first.
• Plugin folders are a crowd. A typical site accumulates 20-40 plugin directories with names like wp-optimizer-pro and seo-toolkit. One more plausible-sounding folder attracts no attention at all.
• Some plugins don't even appear in your dashboard. WordPress loads everything in wp-content/mu-plugins ("must-use" plugins) automatically, without listing it on the normal Plugins screen and without any way to deactivate it from the dashboard. Attackers know this; hiding there means even a plugin-list review misses them. Sucuri's research team has documented this technique in the wild repeatedly.

The five tells of a fake plugin

Real plugins and fake ones are built by different kinds of people under different constraints, and it shows in the structure, before you read a single line of code. These are the five signals we weigh in real cleanups:

1. The empty-shell layout

A legitimate plugin accumulates scaffolding: a readme.txt, license files, an assets or languages folder, translation files, years of version cruft. A fake plugin is almost always one to three PHP files sitting alone in a folder. The attacker wrote the minimum needed to keep a backdoor alive: nobody writes a changelog for their webshell.

2. A name that's almost right

Fake plugin names cluster in two families. The first is generic infrastructure: names like cache-manager, wp-security-core, or contact-form, words that sound so essential you'd never question them. The second is impersonation: the folder or the plugin header inside it claims to be a famous plugin. In one case Sucuri documented, a plugin sitting in a contact-form directory presented itself as Yoast SEO, complete with copied metadata. The tell: the real plugin is also installed, or the "famous" plugin's folder name doesn't match what that plugin actually uses.

3. Born yesterday

Plugin folders normally date from when you installed or updated them, and you roughly remember doing so. A fake plugin's folder often has a creation date that matches nothing in your history, typically the same date as the break-in, which is also often the date other infected files on the site changed. A folder that appeared last Tuesday, on a site you haven't touched in months, is a folder worth opening.

4. Code that doesn't match the label

You don't need to understand PHP to notice that a "slider" plugin has no images, templates, or stylesheets, just a wall of scrambled text. Long unreadable strings of letters and numbers (encoded payloads), text processed through layers of decoding functions, or references to logins and user creation inside a plugin that should have nothing to do with accounts: any mismatch between what the folder claims to be and what the files vaguely look like is a serious signal. In our cleanups, the payload inside fake plugins is most often a webshell (a remote control panel for your server), a hidden admin-user creator, or an injector that pushes spam or redirects into your pages.

5. The wrong basement: mu-plugins

Most sites' wp-content/mu-plugins folder is either absent or contains one or two files placed there by the hosting company. If yours contains PHP files you can't attribute to your host or to a plugin you knowingly installed, treat them as suspect until proven otherwise. Because WordPress gives you no dashboard control over this folder, checking it requires looking at the actual files over FTP or your host's file manager, which is exactly why attackers favor it.

What fake plugins are for: persistence

Here's the part that matters most if your site has already been cleaned once and got reinfected: the fake plugin is usually not the infection you can see. It's the reason the infection comes back.

The visible damage (spam pages, redirects, injected scripts) is what the attacker does with their access. The fake plugin is the access itself. Clean every infected page and leave the fake plugin in place, and the attacker reinfects the site at their convenience, often within days. This is the single most common story behind "I cleaned my site and it got hacked again."

The five-minute check

The catch: fakes are the symptom, not the disease

Finding and deleting a fake plugin is real progress, but it answers the wrong question. The right question is: how did it get there? A fake plugin means the attacker already had write access to your filesystem, through a vulnerable plugin, a stolen password, or an earlier infection that was never fully removed. A thorough response checks every file and the database, not just the plugins folder.

That full sweep is exactly what Kornet automates. Our scanner reads every file on the site and the WordPress database, flags what doesn't belong (including whole fake plugin directories, which it removes as a unit) and shows you a complete report of what it found and what it did. The scan is free; you only pay if we actually find malware.

Kornet Labs publishes field notes from real WordPress malware cleanups. Referenced research: Sucuri's write-ups on mu-plugins abuse and a Yoast-impersonating spam injector, case studies of individual specimens of the pattern described here.