Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
How attackers actually break into WordPress sites, what they do with the access, and why most owners discover the problem months after it started.
Most WordPress sites are hacked by a scanner rather than a person. It finds a known weakness, exploits it automatically, and moves to the next site on the list. Nobody decided your business was worth the effort.
A smaller number are targeted. Ecommerce stores holding payment data, sites in competitive niches, agencies with access to dozens of client sites. Those attacks are slower, quieter, and they hide the longest.
Either way, owners assume that if their site were compromised they would know. Usually they do not. The break-in and the discovery are separate events, and the gap between them is often measured in months. The site loads fine. Traffic holds. Scans come back clean.
This article covers how attackers get in, and why that gap exists at all.
WordPress runs a large share of the web, so it gets attacked more than anything else. That part is obvious and it is where most articles stop.
The more useful detail is where the weakness sits. WordPress core is not the problem. Patchstack tracked 11,334 new vulnerabilities across the WordPress ecosystem in 2025. Ninety one percent were in plugins and nine percent in themes. Six were in WordPress core itself, and all six were low priority.
That makes sense once you look at how a site is built. Core is maintained by a large team under heavy scrutiny. A plugin might be maintained by one developer who stopped answering emails two years ago. You installed it once to add a contact form and never thought about it again.
So the surface is the plugin layer. But knowing where they get in only explains half of it. What the attacker wants decides how the compromise behaves after that.
Automated attacks want cheap resources. Traffic they can redirect. A server they can send spam from. Pages they can inject links into. Your site is inventory, not a target. These attacks tend to show themselves eventually, because using the resource is the whole point. Spam posts appear. Visitors get redirected. Something breaks and somebody notices.
Targeted attacks want access, data, or damage. An ecommerce store has customer records and payment flows. An agency account has keys to every client site it manages. A competitor or a former developer may want nothing more than leverage. Here the attacker gains nothing by being visible, so they stay quiet.
That difference is the whole reason discovery takes months. The attacks that hide are the ones with a reason to hide.
In our own work the mix is fairly consistent. What comes to us most often is plugin vulnerabilities, SEO spam, casino and gambling posts, redirect malware, fake Cloudflare verification pages, stolen admin access, nulled themes, and hosting level compromise.
Owners describe it differently. Google is showing a dangerous site warning. Visitors cannot load the site. Plugins are installing on their own. Blog posts about casinos are publishing under their name.
In almost every one of those cases, nobody was singled out. A scanner found a known weakness and took it. The genuinely targeted jobs are the rare ones.
Every item in that list is a symptom. Not one of them is an entry point.
The distinction gets lost constantly, and it is the main reason cleaned sites come back infected. A symptom tells you what the attacker is doing with your site. The entry point tells you how they earned the right to do it. Remove the first without finding the second and nothing has actually been fixed.
These fall into two groups, and that split matters more than the list itself. Three of them live inside your WordPress install. Three of them have nothing to do with WordPress at all, which is why a WordPress security plugin never sees them coming.
This is the most common entry point by a wide margin, and it is almost always automated.
When a vulnerability is disclosed publicly, the details become available to everyone at the same time. Attackers write a script that checks for the affected version and run it against large lists of sites. Nobody reviewed your business first. The scanner asked one question, your site answered yes, and the exploit ran.
The plugin does not have to be obscure. A contact form, an image slider, a page builder addon, a backup tool. Anything installed once and left alone. In many cases the plugin is not even in active use anymore, just deactivated and still sitting in the folder where its code can still be reached.
WordPress core itself is rarely the way in. It gets audited constantly and patched quickly. When we find a site running an old core version, it is usually a sign of general neglect rather than the door that was actually used.
One thing worth saying plainly. On many jobs the exact plugin cannot be named with certainty after the fact, because server access logs had already rotated by the time anyone called us. That is not a failure of investigation. It is what happens when a compromise sits long enough, and it is a good argument for preserving evidence early rather than cleaning first.
This is the only entry point on the list that the site owner installs themselves.
A nulled plugin is a paid product with its licence check stripped out, given away for free. The licence check is not the only thing that gets modified. Whoever removed it had full access to the code and no reason to stop there.
There is no exploit involved and no scanner needed. The backdoor arrives with the download, works from the first day, and sits inside a file the owner believes is legitimate because they chose to install it.
Cost is usually the reason. A premium theme costs sixty dollars and the free version is one search away. That saving is what the whole business ends up paying for.
Most small business sites carry some custom work. A theme built by a freelancer, a booking form somebody wrote by hand, a snippet dropped into the theme files to fix something years ago.
None of it has a version number. There is no vulnerability database entry, no update notification, and no security plugin checking it, because nobody outside your site has ever seen this code. The developer who wrote it moved on and cannot be reached.
What we find in it is usually simple. Form input passed straight into a database query. A file upload that never checks what it is receiving. Database or API credentials written directly into a file that sits in a public folder.
The warning sign is ownership. If nobody at the company can say who wrote a piece of code or when, nobody is maintaining it either.
Everything above is code running inside your site. The next three never touch it. In these cases the attacker holds legitimate access, or reaches your files from somewhere your WordPress install cannot see.
Here the attacker does not exploit anything. They log in.
There are several ways they get there:
A password reused from an unrelated service that was breached
Automated guessing against the login page or XML-RPC, which is still running on most sites and accepts unlimited attempts by design
A developer or ex-employee whose administrator account was never removed
Malware on a team member's computer that harvests saved passwords and active sessions
Access keys for connected services, such as a payment gateway, email marketing tool, or CRM, which often carry more permission than anyone remembers granting
This is the hardest group to catch, because nothing was broken. There is no damaged file to find and no exploit in the logs. A valid login looks exactly like a valid login.
One useful tell is a site installing plugins by itself. When new plugins appear that nobody on the team added, that is usually not a code exploit doing the work. That is somebody using real administrator access, because installing a plugin is the fastest way to load whatever code they want onto the site.
Sometimes the site was never the weak point at all.
On shared hosting, many sites live on the same server. If file permissions are loose, a compromise on a neighbouring account can reach across into yours. Stolen FTP, SFTP, or control panel credentials do the same thing from a different direction, and none of them pass through WordPress at all. Neither does a server left misconfigured, with directories readable that should not be or backup files sitting somewhere a browser can reach them.
The tell here is scope. If several unrelated sites under the same hosting account are infected at the same time, with the same files, the problem is at the server level and cleaning one site will not fix anything.
Host quality matters more than most owners expect. Account isolation, file permission defaults, and how quickly a host responds to a report all change how far a compromise can travel. It is worth weighing security alongside price and speed when choosing where a business site lives.
This one is invisible because the owner does not think of it as their website.
A staging copy from a redesign two years ago. A subdomain nobody retired. A folder called old that was meant to be temporary. These run whatever version of WordPress was current when they were created, receive no updates, and appear in no monitoring. To a scanner they look exactly like any other site.
It is not only WordPress either. An abandoned database tool, a second CMS in a subfolder, a script installed once for a campaign. Anything that answers a request on your domain is part of your attack surface, whether or not anyone remembers it exists.
Once an attacker has file access through one of these, your main site is simply another folder on the same account.
Occasionally the code was trustworthy when it was installed and stopped being trustworthy later. A plugin gets sold to a new owner who adds something to it. A developer account gets taken over and a malicious update ships to everyone. A third-party script loaded from someone else's server changes without warning.
This is rare, and it is the only case on this page where the owner did everything right and still got hit. It is worth knowing about, but it is not where we would start looking.
Every symptom named earlier can be produced through any of these six doors. Casino spam does not tell you whether a plugin was exploited or someone simply logged in. Neither does a redirect, and neither does a Google warning.
That is why removing the visible damage first is a mistake. It closes the case before anyone has established how the site was opened.
Open any WordPress security guide and you will find the same instruction near the top. Keep everything updated.
That advice deserves respect. For most of WordPress history, it was one of the highest value things a site owner could do. Attackers relied heavily on old versions of popular plugins. Patches shipped, sites that applied them closed the known vulnerability, and sites that ignored them remained exposed. Diligence genuinely worked, and telling people to update was honest advice.
It is not enough anymore, and the numbers explain why better than any argument.
Patchstack tracked 11,334 new vulnerabilities in the WordPress ecosystem in 2025, a 42 percent increase from the year before. That volume alone is difficult for any site owner to keep up with. But the figure that changes the advice is a different one.
Forty six percent of those vulnerabilities did not receive a fix from the developer in time for public disclosure.
Read that slowly. Nearly half were announced publicly while the affected software was still vulnerable. The details were out, attackers could act on them, and in those cases there was no update to install because the update did not exist.
The reason is usually not negligence. Many WordPress plugins are free and generate little or no direct revenue. A developer may have paying work elsewhere, may have abandoned the project, or may simply stop maintaining it. A security fix is unpaid work on software that may earn the developer nothing, and sometimes that work never gets done.
Timing makes the problem harder still. Patchstack measured a weighted median of five hours between disclosure and the first observed exploitation attempt, with roughly half of high impact vulnerabilities exploited within a day. If the patch arrives after disclosure and you apply it the following morning, you are already late.
So the honest version of the advice is narrower than the one everyone repeats.
Updating is necessary, but it is not a complete defence. It is hygiene. It closes the doors that have already been identified and patched. It does nothing about the doors that have not been closed yet.
That is uncomfortable because it removes the reassuring idea that a careful owner cannot be hacked.
A careful owner can be hacked.
What careful owners actually control is different. Not whether something gets in, but how long it goes unnoticed, and how much is still recoverable once it is found.
The day a site is compromised and the day anyone finds out are two different dates. On most sites we investigate, they are months apart.
The attacker has no reason to close it. Access is the valuable part, and using it loudly is what gets it taken away. Monarx found uploader scripts nearly doubled through 2025, meaning what attackers plant is a way back in rather than a payload. Access gets sold, or held until a campaign needs somewhere to sit.
So the visible event is the last step, not the first. Spam posts appearing on Tuesday feel like they started on Tuesday. They almost never did.
On a client site this year, casino posts published in July 2026 while the rogue administrator records in the database dated to March 2025. Sixteen months. That proves the site carried a compromise for that long, not that anyone was working inside it the whole time.
The practical cost is backups. Retention windows run thirty to ninety days, so every copy that owner held was made after the attacker was already inside. We reconstructed the full timeline in our malware removal case study.
None of which explains why nothing caught it.
Owners take this part personally. They paid for a security plugin, ran it, and it said the site was fine. The plugin was not lying.
It answered a narrower question than most people assume. A scanner compares your files against a record of known malicious code, and cannot recognise what is not on that list yet.
Malware stays off it three ways. Code written for a single campaign has no signature. Some payloads unregister themselves from the plugin list while still running. The most effective technique is deciding who sees what. Monarx found the dominant families, including Japanese SEO and Parrot TDS, serve spam to search crawlers, redirects to real visitors, and clean pages to scanners and owners.
So the site genuinely is clean, for you. You are not the audience.
Scanners are still worth paying for, because most compromises are ordinary. We run MalCare on cleanup jobs. On the site described earlier it flagged seven infected files across four folders, hours of work by hand. It did not find the backdoor. That file had removed itself from the plugin list and only ran for logged out desktop visitors, so there was nothing to compare it against. We found it in the page source as an anonymous visitor, after the cleanup, with the redirect still happening.
A plugin catches what has been seen before. A person catches what renamed itself. The second is what a security audit is for, and it is worth doing while the evidence is confusing rather than obvious.
A site gets cleaned. Spam posts deleted, bad files gone, everything looks normal. Four days later it is back.
Owners read this as bad luck or a second attack. It is almost never either. It is the same attacker, who never left.
Three things explain most reinfections. The entry point was never found, so the vulnerable plugin or stolen password still works. Something was left behind deliberately, because attackers plant more than one way back in and missing one makes the rest irrelevant. Or the code is not in a file you can delete. Monarx found attackers increasingly inject into legitimate core and theme files rather than adding new ones, and the Lock360 family runs in server memory, rewriting index.php and .htaccess the moment they are restored.
That last one is why a cleanup can undo itself within minutes with nobody having done anything wrong.
A cleanup that removed what you could see and never established how the attacker arrived is not finished. It is paused. We walked through one in our malware removal case study.
The gap closes when someone looks at the site with intent, and the first move is the one almost everyone gets backwards.
Stop cleaning. The information that tells you when a compromise started is what a cleanup destroys. File dates go when files are replaced, database records go when accounts are removed, and server logs rotate within a week or two. Take a full copy of the site and database as they are now, infected, and leave it untouched.
Then four questions.
Who has administrator access, and when was each account created?
What is the oldest file modification date you cannot explain?
Does any backup you hold predate the earliest thing you found?
Has anyone opened the site logged out, on a desktop, from a different network?
We wrote those up in full in investigate before you clean, including what to save and how to read the dates.
None of this cleans anything. It establishes what you are dealing with, which decides whether the cleanup is an afternoon or a rebuild.
Every compromise has two dates. The day someone got in, and the day someone found out. Most of this article has been about the distance between them.
That distance is not a measure of how careless the owner was. Nearly half of the vulnerabilities disclosed last year had no fix available when they became public, and the malware families doing the most damage are built specifically to show clean pages to the person checking. Being attentive does not exempt anyone from either of those.
What attention does change is the second date. A site checked properly once a quarter, with someone actually looking at accounts, file dates, and how the site behaves for a logged out visitor, has a gap measured in weeks. A site nobody examines until something visible breaks has a gap measured in months, and by then the backups are compromised too.
A site that looks fine is not evidence that it is fine. It is only evidence that nobody has looked yet.
If you are reading this because something already looks wrong, take the copy first, then work through the four questions. And if the answers do not add up, we can take a look.
No. WordPress is attacked more because it runs more of the web and because anyone can install third party code on it. Closed platforms limit that risk by limiting what you can install. The trade is control. WordPress core itself had only six disclosed vulnerabilities in 2025, all low priority.
Yes. Forty six percent of the vulnerabilities disclosed in 2025 had no fix available from the developer at the time they were made public, so there was nothing to update to. Updates also do nothing against stolen passwords, server level access, or code a previous developer wrote for you.
Some signs are obvious, such as spam posts, redirects, or a browser warning. Many are not. Open your site logged out, on a desktop, from a different network, and check your administrator accounts and their creation dates. Our investigation guide covers what to look for and in what order.
Usually yes, and often before the owner notices anything else. Injected spam pages, cloaked content served to crawlers, and blacklisting all affect visibility. Recovery is possible but rankings rarely return immediately after cleanup.
Only if the backup predates the compromise. Most hosts keep thirty to ninety days of backups, and many compromises are older than that, which means every copy you hold already contains the backdoor. Check the earliest suspicious date first. How to work out which backups are safe.
It reduces the risk and catches most ordinary infections quickly, which is worth paying for. It cannot recognise code it has never seen, and it cannot see malware that serves clean pages to scanners while redirecting real visitors. Treat it as detection, not as a guarantee.
It depends on how long the compromise has been running and whether the entry point is known. A recent, single payload infection is straightforward. A site with a long dwell time, multiple backdoors, and no usable backup is a different job.
Yes, and usually not on purpose. Most compromises come from automated scanning that finds a known weakness and exploits it without anyone reviewing the site first. Being small does not make a site less findable. It usually only means nobody is watching it.
SEO & Website Security Specialist at AppDeel
Azizul Hakim is an SEO and website security specialist at AppDeel, the agency he founded and where he still handles client work himself. For more than ten years he has helped business owners and eCommerce brands get found in search and keep their websites secure.
Read more posts by Md Azizul Hakim →A breakdown of the fake Cloudflare verification scam hitting WordPress sites — how it hides from site owners, why security scanners miss it, and how we remove it.
How to remove malware from a WordPress site: hidden backdoors, database spam, rogue admin accounts, and a fake Cloudflare verification page.
Ten design mistakes that quietly lose you customers, what causes each one, and how to fix it without a rebuild.
Trust advice was written for checkouts. What actually builds trust when your site takes enquiries, not payments.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
