Does an admin account I did not create always mean I have been hacked?

Almost always, yes. There are innocent explanations, such as a developer, a host support agent or a plugin that creates a service account during setup, so check with anyone who has had access before you panic. But an administrator you cannot account for is the single clearest sign of a compromise, because it is what most attacks are trying to achieve. Treat it as a breach until you have positively identified who created it and why.

One of my plugins disappeared from the WordPress plugin directory. Is my site infected?

Not necessarily, but it is a reason to look properly. WordPress.org closes a plugin listing when it is under review, which can mean a licensing dispute, an abandoned plugin, or a live security incident. The plugin keeps running on your site either way, because closing the listing only stops new installs and updates. If the closure was a security incident, you are now running unpatched code with no update path, which is the worst of both situations.

My host's malware scanner says the site is clean. Can I trust that?

Only as far as what it actually checks. Most host scanners compare plugin and theme files against known-good copies and match against malware signatures. Two of the three major 2026 supply chain attacks never modified a plugin file at all: one poisoned a data feed the plugin loads from an external server, the other injected code through a compromised CDN script. A file comparison finds nothing in either case. A clean scan means no known bad files, not no compromise.

Do I need to rebuild the site or can it be cleaned?

Most sites can be cleaned, but cleaning is not the same as removing the visible symptom. A serious compromise leaves persistence: a hidden administrator, a webshell in a fake plugin folder, a scheduled task, a modified core file. If you remove the payload and miss any one of those, the site reinfects within days and it looks like the cleanup failed. The decision to rebuild usually comes down to whether the entry path can be established, not whether the malware can be deleted.

A WordPress Admin You Did Not Create: What It Means and What To Do

// AI SUMMARY

Quick answer: an administrator account you did not create is the clearest single sign that your site is already compromised, because creating one is what most WordPress attacks are trying to achieve. The three largest attacks of 2026 all did exactly that, and two of them did it without ever modifying a plugin file, which is why the host scanner said the site was clean. Check your plugin list against the named plugins below, check your Forminator version, then check your administrator accounts at the database level rather than in the dashboard.

Why this is suddenly everywhere

Attackers stopped trying to break into WordPress sites one at a time. They started buying or breaking into the things thousands of sites already trust, then letting the update system do the work. Three cases from 2026 make the pattern obvious.

BdThemes, August 2026. Seven popular Elementor addons load promotional content from a data feed hosted on their vendor’s server. Attackers got write access to that feed and poisoned it. When a logged-in administrator opened their own dashboard, the poisoned response ran in their browser, using their own session to create a hidden administrator account and install a webshell disguised as a plugin. WordPress.org closed all seven plugin listings on 7 and 8 August. Wordfence, which published the analysis, notes that no plugin source code was ever changed. BleepingComputer reported around 350,000 active installs across the affected plugins.

Checked again on 24 August, more than two weeks later, the WordPress.org directory still returns Element Pack Lite as closed, dated 8 August, “pending a full review”. BdThemes has shipped at least one release since, Element Pack Pro 9.8.14 on 19 August, and its public release notes do not mention the incident. So if you are waiting for your dashboard to tell you about this, it has not, and it may not.

Forminator, July 2026. A contact form plugin on roughly 600,000 sites turned out to accept file uploads from anyone at all, with no login required, in a way that allows running code on the server. It is tracked as CVE-2026-15748 and rated 9.8 out of 10. It was fixed in version 1.56.2 on 31 July. SecurityWeek reported that about half of all installs were still running a vulnerable version afterwards.

EssentialPlugin, April 2026. A developer sold a portfolio of more than twenty free plugins on Flippa. The buyer pushed what looked like a routine compatibility update containing a dormant backdoor, waited seven months, then switched it on. Patchstack documented the timeline. WordPress.org closed every one of those plugins permanently on 7 April.

None of these required you to do anything wrong. You installed a popular plugin from the official directory and kept it updated, which is exactly the advice everyone gives.

What to check today

Work through these in order. It takes about ten minutes.

1. Look for these plugin names in your plugins list.

Plugin	Note
Element Pack Addons for Elementor	100,000+ installs, the largest of the group
Prime Slider Addons for Elementor	Where the underlying flaw was introduced first
Ultimate Post Kit
Ultimate Store Kit
Pixel Gallery Addons for Elementor
Live Copy Paste
Smart Admin Assistant

If any of these are installed, deactivate it now and treat the site as compromised until you have checked the rest of this list. Deactivating is not a fix, but it stops the poisoned feed loading on your next dashboard visit.

2. Check your Forminator version. Anything at or below 1.56.1 needs updating to 1.56.2 or later immediately. This one has a clean fix, so it is the easiest win on the page.

3. Check your administrator accounts, but not in the dashboard. This is the part people get wrong. The BdThemes payload alters the query that builds the user list, so the account it creates does not appear in Users. Looking at the Users screen and seeing nothing unusual proves nothing.

If you have command line access, this asks the database directly rather than the admin screen:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Compare every row against people you can actually name. The BdThemes accounts follow a predictable pattern: bd_ followed by six characters. Also look for a file named emer-run.php anywhere under your plugins directory.

4. Check when your plugins last updated. A plugin that has not had an update in months, on a site where everything else updates automatically, is worth looking up. If its WordPress.org page returns “this plugin has been closed”, you are running unmaintained code with no patch route.

Why the scanner said clean

We wrote up a plumbing client whose site was serving a fake Cloudflare screen to real visitors while the host’s own scanner reported no infection. That was not a broken scanner. It was a scanner doing what scanners do.

Host scanners work by comparing your plugin and theme files against known-good copies and matching file contents against a list of known malware signatures. Both are reasonable checks. Neither catches an attack where the plugin files are untouched and the malicious content arrives at runtime from somewhere else, which describes BdThemes exactly. On that plumbing site, one of the hostile plugins was pulling changing JavaScript from an external data source and running the result in visitors’ browsers, so there was no fixed malicious string sitting in a file to match against.

That is the honest limitation. A clean scan tells you there are no known bad files. It does not tell you there is no compromise, and on this class of attack the two are very different statements.

If you find something

Do not just delete the plugin and move on. Every one of these attacks installs a way back in, and removing the payload while leaving the persistence is why cleanups appear to fail a week later. At minimum you are looking for the hidden administrator, the webshell, any scheduled task added around the same time, and anything unexpected in the must-use plugins folder.

Change every administrator password and force all sessions to log out, because an attacker holding a valid session cookie does not care that you changed the password. Rotate your database credentials and any API keys stored in the site. Then check whether Google has flagged the domain in Search Console, since a blacklisting outlasts the cleanup by days and quietly takes your enquiries with it.

And keep the evidence. The instinct is to wipe everything, which feels decisive and destroys the only record of how they got in. On the case study above, we could establish the delivery and persistence mechanisms but never conclusively established the original entry path, and we said so rather than inventing one. If you cannot say how they got in, you cannot say it will not happen again.

What actually reduces the risk

You cannot audit a vendor’s storage bucket, and no amount of care would have saved you from any of the three attacks above. What you can change is how much surface you are exposing and how fast you would notice.

Fewer plugins is the single biggest lever, and Elementor addon packs are the worst offenders because one install brings in dozens of widgets you will never use. Every plugin is a separate company whose security practices you are trusting, and, as EssentialPlugin showed, a company that can be sold to someone else without you being told.

Beyond that: logging that records plugin changes, administrator changes and logins, stored somewhere the attacker cannot reach; file integrity monitoring that runs independently of your host; and a real backup you have actually restored from at least once. Two of these three attacks were caught by researchers within hours or days. The sites that suffered were the ones with nobody watching in between.

If your site runs on WordPress and none of that is in place, that is the gap worth closing, whether we do it or somebody else does. If you would rather not have the surface at all, we build on a different stack for exactly this reason.