How Hackers Actually Get Into WordPress Sites in 2026

When most people picture a website being hacked, they imagine someone in a hoodie typing furiously at a terminal. The reality is far less dramatic and far more common. WordPress sites get compromised every day by automated scanners that crawl the public web, probe thousands of sites at once, and walk in through doors that were left open. The attacker is usually a script, not a person, and the goal is rarely you specifically. It is whoever happens to be running the software they know how to exploit.

Understanding the real entry points matters because the same handful of mistakes account for the overwhelming majority of WordPress breaches. Fix them and you become a much harder target. Ignore them and you are running on luck.

1. Vulnerable plugins

Plugins are the number one cause of WordPress compromises. The plugin ecosystem is enormous, and the quality of code is uneven. A plugin that was perfectly safe two years ago can have a critical vulnerability published next week, and if you have not updated it, you are exposed the moment that advisory goes public.

The pattern usually goes like this. A researcher or a black hat discovers a flaw in a popular plugin, often something like an unauthenticated file upload or an SQL injection. The flaw gets disclosed. Within hours, automated scanners are sweeping the internet looking for sites running the vulnerable version. Sites that have not patched are compromised in bulk.

A recent audit we ran on a Sydney agency site revealed a file manager plugin that had been left installed and active for over a year, despite the plugin family having a long history of remote code execution vulnerabilities. The attacker did not need to do anything clever. The plugin handed them write access to the entire site.

2. Weak or reused admin credentials

Brute force attacks against the WordPress login page are constant. Bots will try thousands of common username and password combinations per hour, drawing from breach databases that contain hundreds of millions of leaked credentials. If your admin uses a username like admin, your business name, or your first name, and a password that has appeared in any past breach anywhere on the internet, you are already on the list.

The fix is not complicated. Use unique, long passwords. Use a password manager. Use two factor authentication on every admin account. Limit login attempts. Rename your default admin user away from anything guessable. These steps are boring and they stop most automated attacks cold.

3. Outdated WordPress core

WordPress core itself is generally well maintained, with security releases pushed out quickly. The risk is not that core is full of holes. The risk is that some site owners disable automatic updates and then forget to apply the manual ones. Running a WordPress version that is a year or two out of date means running with publicly documented vulnerabilities that any scanner can detect.

WordPress will tell you when an update is available. Apply it. If you are worried about plugin compatibility, apply it on a staging copy first. Do not leave it.

4. Compromised themes

Themes are also code, and they have the same risks as plugins. The bigger problem is pirated themes downloaded from sketchy sites. A free copy of a premium theme from a torrent site is almost always laced with backdoors, hidden links, or worse. The savings on a hundred dollar theme can cost thousands in cleanup.

Stick to themes from the official WordPress repository or from reputable vendors with active support and regular updates. Pay for what you use. It is much cheaper than the alternative.

5. Exposed configuration and backup files

A surprising number of WordPress sites leak sensitive files that should never have been on the public web. Backup archives sitting in the document root, .sql dumps, .env files, and old copies of wp-config.php named something like wp-config.bak. Once an attacker downloads one of these, they have database credentials, secret keys, or both.

Audit your document root. Anything that is not part of WordPress should not be there. Move backups off the server. Delete old developer files. Block direct access to common sensitive filenames at the server level.

6. Cross site contamination on shared hosting

On cheap shared hosting, multiple WordPress sites can live on the same account or even the same disk. If one of them gets compromised, the attacker often has the ability to pivot to the others, dropping the same malware across every site in the bucket. This is a common pattern with agencies that run twenty or thirty client sites on a single shared plan.

Isolate sites. Use proper managed WordPress hosting where each site sits in its own container. Audit any other site sharing your environment with the same scrutiny as your own.

7. XML-RPC and REST API abuse

WordPress exposes two main programmatic interfaces, xmlrpc.php and the REST API. Both are legitimate, both can be useful, and both have been used as attack vectors. XML-RPC in particular has historically been abused for amplified brute force attacks, where a single request can attempt many password guesses at once.

If you do not use XML-RPC, disable it. If you do not need unauthenticated REST API access to certain endpoints, restrict it. Most modern hosts and security plugins make this straightforward.

8. Stolen sessions and cookies

An attacker does not always need your password. If they can capture a session cookie, for example through a man in the middle on an insecure connection, they can impersonate you for as long as that session is valid. Logging in over public wifi without a VPN, or running a site without proper HTTPS everywhere, makes this much easier.

Always use HTTPS. Force it sitewide. Set secure cookie flags. Log out when you are done. Rotate WordPress salts and keys periodically so existing sessions get invalidated.

9. Social engineering of staff and contractors

Some compromises do not need a software flaw at all. A phishing email asking a staff member to log in to a fake admin page, a fake invoice email tricking a developer into running a hostile shell command, a contractor who reuses the same password everywhere and then has it leaked from somewhere else. People are part of the attack surface.

Train staff. Use a password manager across the team. Enforce two factor authentication. Limit the number of accounts with administrator level access. Remove accounts the moment someone leaves the project.

10. Forgotten and abandoned sites

Plenty of WordPress sites get launched for a campaign, an event, or a side project, and then forgotten. They keep running on the same hosting, with the same credentials, slowly drifting out of date. A year later they are a perfect target. The owner has stopped checking, but Google and the bots have not.

If you no longer need a WordPress site, take it down properly. Export the content, decommission the install, free the domain, archive the database. Do not leave abandoned installations on the public internet.

How to actually defend against all of this

The defences are not exotic. Keep everything updated. Use strong unique passwords plus two factor authentication. Run a serious security plugin like Wordfence and pay attention to what it tells you. Make sure your host is reputable, isolates sites properly, and offers off site backups. Audit your plugins, themes, and admin users at least quarterly. Rotate keys and salts when staff or contractors change. Restore from a backup occasionally just to know it works.

None of this is glamorous. It is routine and it works. The sites that get compromised are almost never the ones that did all of it. They are the ones that did most of it, or none of it, and assumed they were too small to be noticed.

Need a hand?

If you would like an honest look at how exposed your WordPress site really is, Smart Coding can run a security audit and walk you through exactly what we found. Get in touch and we will help you close the doors before someone else walks through them.