WordPress Security: How Sites Actually Get Hacked

Almost nobody targets a small business website. That is the first thing worth understanding, because it changes what security actually means in practice.

The overwhelming majority of WordPress compromises are automated. Bots crawl the web constantly, testing every site they find against a list of known vulnerabilities in specific plugin and theme versions. Your site is not chosen — it is simply found running something with a published hole in it.

Which is good news, because automated attacks are defeated by unglamorous maintenance rather than by expensive tooling.

How sites actually get compromised

Outdated plugins and themes. This is the leading cause by a wide margin. When a vulnerability is disclosed and patched, the disclosure itself tells attackers exactly what to look for. Sites still running the old version become targets within days. The window between a patch being released and a site applying it is where most hacks happen.

Nulled plugins and themes. Pirated copies of premium software, distributed free. I will come back to this, because it deserves its own section.

Weak or reused admin passwords. Automated login attempts run against every WordPress site continuously. A password reused from a service that suffered a breach is not a guess — it is a lookup.

Abandoned installs. The staging copy nobody deleted, the old subdomain from a previous agency, the test site at /new/. These stop being updated the day they stop being used, and they sit on the same hosting account as the live site.

Shared hosting cross-contamination. On cheap shared plans, a compromise on a neighbouring account can sometimes reach yours. This is uncommon on reputable hosts and genuinely does happen on the cheapest tiers.

Nulled plugins deserve a specific warning

A nulled plugin is a paid plugin with its licence check removed, offered as a free download. The pitch is that you get premium software without the subscription.

What you actually get is software modified by someone whose business model is distributing modified software. Backdoors in nulled plugins are not a theoretical risk — they are the point of the exercise. The licence check is removed and something else is frequently added, often obfuscated well enough that it survives a casual look at the files.

The second problem is structural even when a particular copy happens to be clean: a nulled plugin cannot receive security updates. It has no valid licence, so when a vulnerability is disclosed in that plugin, every nulled installation stays exposed permanently. You are frozen on a version whose weaknesses are now public.

I have had to migrate client sites off nulled premium plugins, rebuilding the functionality natively so the site could be updated safely again. It is real work, and it is always more expensive than the subscription would have been. If a plugin is worth using, it is worth licensing.

The eight things that prevent most of it

• Update core, plugins and themes on a schedule. Weekly is fine for most sites. This one habit prevents more compromises than everything else on this list combined.
• Delete what you do not use. A deactivated plugin still has files on disk and can still be exploited. Deactivating is not removing.
• Use licensed software only. No nulled plugins or themes, ever, for the reasons above.
• Enforce strong, unique passwords and enable two-factor authentication on every administrator account.
• Remove the accounts nobody uses. The former developer, the agency that finished eighteen months ago, the contractor who built one page. Every dormant admin account is a live entry point.
• Give people the role they need. Someone who writes blog posts is an Editor, not an Administrator.
• Keep off-site backups you have actually tested. A backup stored only on the same server as the site is not a backup. Restore one to a staging environment occasionally, so you find out it works before you need it.
• Run a reputable security plugin for firewalling and login rate limiting — but treat it as a supplement to updates, never a substitute. A firewall in front of an unpatched plugin is a locked door in an open wall.

If you are already compromised

Signs worth acting on: unfamiliar admin users, spam pages appearing in Google that you never published, redirects that only fire for mobile or search traffic, a browser warning, or a sudden unexplained traffic collapse.

What to do, in order:

• Take the site offline or into maintenance mode to stop harm to visitors.
• Change every password — WordPress admins, hosting, FTP, database — and rotate any API keys.
• Restore from a known-clean backup taken before the compromise, if you have one.
• If you do not, get a professional clean-up. Malware is routinely spread across multiple files, the database, and scheduled tasks. Deleting the one file you found does not resolve it.
• Update everything, then remove anything you cannot account for.
• Check Search Console for Security Issues and request a review once the site is genuinely clean.

The reinfection rate on sites that were cleaned but never patched is high, because the original entry point is still open. Cleaning is not the fix — closing the hole is.

What this has to do with everything else

A hacked site loses rankings, and the recovery is slow even after the cleanup. Google can flag it, browsers warn visitors away, and injected spam pages can persist in the index for weeks. It is one of the fastest ways to undo a year of SEO work.

It is also the part of the WordPress trade-off people underestimate when choosing a platform. WordPress gives you control that hosted builders do not, and that control includes responsibility for maintenance — a point I made in WordPress vs. website builders. Managed properly it is a non-issue. Ignored for two years, it is how sites get hacked.