“Why would anyone hack us? We are a small business.” Almost every owner asks this after a break-in, and it is a fair question. You do not hold state secrets. Your site gets a few hundred visitors a week. It seems like a strange target.
The honest answer is that in most cases nobody chose you. Your site was found by software that checks millions of addresses for known weaknesses, and it had one. Understanding how that happens, in plain terms, makes it much easier to see which doors on your own site are open.
Most attacks are automated, not personal
Picture someone walking down every street in a city, trying every front door to see which ones open. That is roughly what attack bots do across the web, day and night, and at no real cost to the people running them.
These bots look for things like a particular plugin version with a known flaw, a login page that accepts unlimited password guesses, or a forgotten file left behind by an installer. When one finds a match, the attack itself is often automatic too. A human may never look at your site at all. They simply collect access to thousands of sites and then use them for spam, redirects, phishing pages or selling on.
This is why “we are too small to be a target” does not protect anyone. Being small often means fewer updates and less monitoring, which makes a site easier to get into, not harder.
The main ways in
1. A plugin or theme with a known hole
WordPress itself is maintained by a large team and gets security fixes regularly. The thousands of plugins and themes built on top of it are written by everyone from big companies to one person in their spare time. Most publicly reported WordPress vulnerabilities are found in these add-ons rather than in WordPress core.
When a flaw is discovered, the developer usually releases a fix and the details become public. From that moment, attackers know exactly what to look for, and every site still running the old version is exposed. The gap between “fix released” and “site updated” is where many hacks happen. Our explainer on how plugin vulnerabilities are found and patched covers that cycle in more detail.
The worst case is a plugin nobody maintains any more. No fix will ever arrive, so the hole stays open for good. If you suspect you have one, see our practical advice on abandoned plugins.
2. A password that was guessed, reused or stolen
Plenty of break-ins involve no clever code at all. The attacker simply signs in with valid login details.
- Guessed. Bots try common passwords against the WordPress login page over and over. Our post on stopping brute-force login attacks explains how to slow them down.
- Reused. If an administrator uses the same password on the website as on some other service that was breached, that password may already be on lists that attackers trade.
- Phished. A fake “your hosting account will be suspended” email leads to a page that looks like your host’s login screen. You type your details, and they now have them.
Two-step verification on WordPress, hosting and email accounts blocks most of these, because a password alone is no longer enough.
3. An infected computer that knew the passwords
Some malware on Windows and Mac computers looks specifically for saved passwords, including those stored in FTP programs and browsers. If a developer or office computer is infected, the website’s login details can be sent to an attacker without anyone typing them. The site is then changed through a perfectly legitimate connection, which makes it confusing to diagnose.
4. “Free” copies of paid plugins and themes
Downloading a premium theme or plugin from a site that gives it away for nothing is a common way to invite someone in. These copies often have extra code added that gives the distributor a hidden way into every site that installs them. We look at this in its own post on why nulled plugins and themes carry malware.
5. Too many people with too much access
Former staff, a freelancer from three years ago, an agency you stopped working with, a plugin vendor’s support login that was never removed. Every administrator account is another key to the building. If any one of those people has their own email or computer compromised, the attacker inherits their access to your site. Giving people only the role they need, as described in our guide to WordPress user roles, shrinks this risk a lot.
6. Forgotten copies and leftovers
Old installs are easy to forget and easy to attack. Common examples:
- A test copy of the site in a folder such as “old”, “new” or “dev” on the same hosting account.
- A staging site that was never updated after the main site went live.
- Plugins that were deactivated but never deleted. The code sits on the server regardless, and some of it can still be requested directly from a browser.
- Backup archives saved inside the public website folder, where anyone who guesses the name can download them, including the database password inside.
7. Neighbours on the same hosting account
Many small businesses keep several websites in one shared hosting account, often with a single login. If one of those sites is hacked, the attacker can often reach the files of all the others. Cleaning only the site that showed symptoms leaves the infection waiting next door.
8. Weak settings on the server
Some problems sit below WordPress. An old version of PHP that no longer gets security fixes, folders that any process on the server can write to, or a configuration file that can be read from the web all make an attacker’s job easier. None of these let someone in by themselves, but they make every other weakness worse.
9. Forms and features that trust visitors too much
Any place where a visitor can send data to your site is a possible way in if the code behind it is careless. A file upload field that accepts any type of file can be used to upload a script instead of a CV. A search box or contact form that passes text straight to the database can be abused with SQL injection. A comment or review field that displays whatever is typed can be used to plant scripts that run in other visitors’ browsers. This is more common in custom-built features than in popular, well-reviewed plugins.
10. A trusted supplier that was itself compromised
Occasionally the problem comes from somewhere you had good reason to trust. A plugin changes hands and the new owner adds something unpleasant, or an outside script you load for chat, reviews or analytics is altered at its source. These cases are rarer, but they explain why even a carefully run site needs monitoring as well as updates.
11. Your domain or DNS, rather than the site
If someone gets into the account where your domain is registered, they can point the domain at a server they control, or change where your email goes. The website itself is untouched, yet visitors see something else. This is why the registrar login deserves the same strong password and two-step protection as everything else.
How the routes combine
Real incidents usually involve more than one of these. A bot finds an outdated plugin, uses it to upload a small file, and that file then adds an administrator account and a second hidden file elsewhere in case the first is found. Or a reused password gets an attacker into the dashboard, and from there they install a plugin of their own.
The first weakness gets them in. What they do next is about staying in. That is why fixing only the visible damage so often fails, and why sites that are cleaned and then reinfected a week later are so common. If that is happening to you, our page on sites that keep getting hacked after cleaning explains what is usually missed.
What this means for your own site
You do not need to become a security specialist. Running through a few questions covers most of the routes above:
- Are WordPress, every plugin and every theme updated regularly, and is anyone actually checking?
- Is there any plugin or theme on the site that no longer gets updates, or that came from somewhere other than the official directory or the developer’s own site?
- Does every administrator have their own login, a unique password and two-step verification?
- Have you removed accounts for people who no longer work with you?
- Are there old copies of the site, staging installs or backup files sitting on the same hosting account?
- Do you know where your domain is registered, and who can log in to that account?
Any “no” or “not sure” is worth fixing before it becomes the way in.
Why it matters after a hack
If your site has already been broken into, knowing which route was used is not just curiosity. A cleanup that removes the malware but leaves the original weakness in place has only reset the clock. Finding the entry point usually means looking at file dates, server access logs and recent changes together, which is slow work, but it is the difference between a site that stays clean and one that does not. For a wider view of what recovery involves, see our guide to getting a hacked website repaired.
If you want to know how someone got into your site, our website hack investigation page explains how we trace the route and what you get at the end. It is the sensible starting point when a site has been hit more than once.
Next in this series: Nulled Plugins and Themes: Why They Carry Malware
