Top Website Vulnerabilities Hackers Exploit

A friend of mine runs a small pottery studio. Lovely little site, maybe two hundred visitors on a busy day, nothing a hacker would ever care about. That was his thinking too, right up until the morning his homepage started bouncing every visitor to a sketchy online pharmacy in another country. He rang me, genuinely baffled. Why would anyone target him?

Here is the uncomfortable answer I gave him, and the one I want to give you. Almost nobody chose his site by name. The attacks that flatten ordinary websites are run by bots that scan millions of addresses an hour, hunting for one known weakness to stroll through. Your site is not a target so much as a number in a very long list. And honestly, that is good news. The same short list of weaknesses turns up again and again, which means you can close most of them before a bot ever comes knocking.

Before we get into the weak spots, a quick word on foundations, because building them is my actual job. A surprising share of the hacks I get asked about begin life inside a fragile, badly coded, or pirated theme. A clean theme wipes out an entire category of risk on day one. If you would rather not wrestle with raw PHP, our WordPress theme builder writes standards friendly code for you, you can start from one of our free WordPress themes instead of trawling shady download sites, and if you enjoy understanding the machinery, I put together a full walkthrough on how to create a WordPress theme from scratch. Solid base first. Then the vulnerabilities.

TL;DR: Most sites get hacked through a short, predictable set of weaknesses, not clever zero day genius. The usual suspects are outdated plugins and themes, weak or reused passwords, SQL injection, cross site scripting, cross site request forgery, broken access control, insecure file uploads, plain misconfiguration, missing HTTPS, and pirated software you install yourself. More than 11,000 new WordPress vulnerabilities were disclosed in 2025, and the fastest were mass exploited within hours of going public. The cure is rarely exotic: update everything, use strong unique passwords with two factor, run a firewall and a security plugin, give every user the least access they need, and keep tested backups. Below I walk through how each attack works and exactly how to shut it down.

Why hackers target a site like yours

Let me kill the most comforting myth first. The idea that you are too small to bother with is exactly what gets small sites hacked. Attackers are not sitting at a desk picking victims by hand. They run automated scanners that crawl the open web nonstop, fingerprinting what software each site runs and flagging anything with a known hole.

A compromised site is useful to them even if it sells nothing. It can send spam, host phishing pages, mine cryptocurrency, hide malware, pump out hidden links to game search rankings, or simply become one more soldier in a botnet. None of that needs you to be famous. It needs you to be reachable and slightly out of date, which describes a frightening number of sites.

So the question is never really “am I worth attacking.” It is “is there an open door.” The rest of this guide is a tour of the doors people most often leave open, and how to close each one.

Where website attacks actually come from

Here is the part that surprises people who assume WordPress itself is the problem. It usually is not. When Patchstack tallied the year, more than 11,000 new WordPress vulnerabilities were disclosed in 2025, up roughly 42 percent on 2024, and the overwhelming majority, well over nine in ten, lived in plugins and themes rather than in WordPress core. Core is one of the most scrutinised pieces of software on the planet. The soft underbelly is the third party code you bolt onto it.

That tracks with what the cleanup crews see. In Sucuri’s 2024 data, WordPress made up about 96 percent of the infected content management system sites they cleaned, yet roughly 37 percent of those hacked WordPress sites were simply running outdated software. The platform is not fragile. The neglect is. Keep that framing in mind as you read, because almost every vulnerability below is either something a plugin author got wrong or something an owner forgot to maintain.

1. Outdated plugins, themes, and core software

If I could fix only one thing on every website in the world, it would be this. Running old software with a publicly known flaw is the single most common way ordinary sites get owned, and it is the easiest to prevent.

The pattern is brutal in its simplicity. A researcher finds a bug in a popular plugin. It gets disclosed and patched. The moment that disclosure goes public, every bot on earth learns about it too, and they immediately start spraying that exploit at every site still running the old version. You are now racing the internet to click update, and a lot of people lose that race by weeks or months.

The classic cautionary tale is Equifax. In 2017 attackers walked off with personal data on roughly 147 million people, and the way in was a known flaw in an open source component that a patch already existed for. The fix was available. Nobody applied it in time. That is not a sophisticated heist. That is a missed update at enormous scale.

For you, the homework is dull and decisive. Turn on automatic updates where you can, check for them by hand where you cannot, and delete any plugin or theme you are not actually using, because dead code can still be exploited. If you are not sure what is current, my guide on how to check for WordPress security updates shows where to look, and it is worth learning to scan your own site for known vulnerabilities so you find the weak plugin before a stranger does.

2. Weak and reused passwords (and brute force logins)

Stolen and guessed credentials are the other giant. In Verizon’s 2025 breach report, credential abuse was the single most common way attackers got their first foothold, involved in around 22 percent of breaches. No exotic exploit. Just a login that should never have worked.

Two flavours do most of the damage. Brute force is the dumb one, where a bot hammers your login page with thousands of password guesses until one lands. Credential stuffing is the smart one, where attackers take username and password pairs leaked from some unrelated breach and replay them against your site, betting that people reuse passwords. They usually win that bet, because most people do reuse, often across a dozen or more accounts.

The defences are unglamorous and they work. Use a long, unique password for every admin account, ideally from a password manager so you never have to remember them. Turn on two factor authentication so a stolen password alone is not enough to get in. And put real brute force protection in front of your login page to lock out the bots after a handful of failed tries. While you are at it, stop using “admin” as your username, since that hands an attacker half of the answer for free.

Pro Tip: Two factor matters most on the one account you would never think to protect, the old editor or contributor you set up years ago and forgot. Attackers love a low level account with a weak password, because once they are inside they go hunting for a way to climb to admin. Audit your user list, kill the accounts nobody uses, and force two factor on everyone who can still log in, not just you.

3. SQL injection

SQL injection has been near the top of the web security charts for over two decades, and it is still there because the underlying mistake is so easy to make. Your site stores its content in a database. When a form, a search box, or a URL passes user input straight into a database query without cleaning it first, an attacker can smuggle in their own database commands disguised as ordinary input.

Picture a login that builds its query by gluing your typed text directly into the command. Now imagine someone types this into the username field instead of a name:

' OR '1'='1

If the code is naive, that snippet rewrites the logic so the query is always true, and the attacker waltzes in without a password. Worse versions let them read your entire database, dump customer records, or wipe tables. The 2023 MOVEit breach, which exposed data on tens of millions of people across thousands of organisations, started as a SQL injection flaw.

You mostly inherit this risk from plugins rather than writing it yourself, so the front line defence is the same boring discipline as before: keep everything patched, and lean on a firewall that recognises and blocks injection patterns. If you write any custom code, the non negotiable rule is to use prepared statements, which keep user input as data and never let it become a command. As a small extra hurdle, it is worth learning to change the default WordPress database prefix away from wp_, because a lot of automated injection attacks assume the standard table names.

4. Cross site scripting (XSS)

Cross site scripting is the most common vulnerability type reported in WordPress, year after year, and the scale of it is hard to overstate. Wordfence alone says it blocked more than nine billion XSS exploit attempts in 2024. Nine billion.

The idea is that an attacker injects their own JavaScript into a page, and that script then runs in the browser of everyone who views it. The malicious code can quietly steal session cookies, log keystrokes on a checkout page, redirect visitors, or skim card numbers as they are typed. There are a few variants, but the nastiest is stored XSS, where the bad script gets saved into your database, through a comment field or a profile, say, and then fires for every single visitor automatically.

The British Airways breach in 2018 was this kind of attack in spirit. A few lines of skimming script on the payment flow harvested the details of around 380,000 customers and cost the airline a record fine. A handful of characters in the wrong place, real money out the door.

The cure lives in clean coding: anything a user types should be treated as suspect, escaped properly before it is shown back, and never dropped raw into a page. Since you rely on plugin authors to get that right, patching and a decent firewall again do the heavy lifting. Adding a content security policy header, which tells browsers to only run scripts from sources you trust, gives you a strong second net.

5. Cross site request forgery (CSRF)

This one is sneaky because it weaponises your own logged in trust against you. Cross site request forgery tricks your browser into firing off a request you never meant to send, to a site where you are already signed in.

It plays out like this. You are logged into your site in one tab. In another tab you open a random page, maybe from a link in an email. That page secretly contains a hidden form or image that fires a request at your admin area, something like “change the admin email to mine” or “create a new administrator.” Because you are still authenticated, your browser cheerfully attaches your session cookie, and the server cannot tell the forged request from a real one. The change goes through, silently.

The standard defence is a hidden, unpredictable token, often called a nonce in WordPress, attached to every action that changes something. The server checks for that token, and a forged request from another site will not have it, so it gets rejected. This is mostly the plugin author’s job, which is yet another reason to favour well maintained plugins and keep them current. Setting your login cookies to a strict same site policy adds another layer, since it stops the browser sending them along with cross site requests in the first place.

6. Broken access control

Broken access control sits at the very top of the latest OWASP Top 10, the industry’s reference list of the most critical web risks, which was refreshed for 2025. It is a fancy name for a simple failure: the site lets people reach things they should not be allowed to reach.

The everyday version is depressingly common. You view your own invoice at a URL ending in invoice=30925, change the number to 30926, and suddenly you are looking at someone else’s invoice because the server never checked whether it actually belonged to you. The same flaw lets a low privilege user call an admin only function just by knowing its address, or lets a logged out visitor reach a page that should require a login. In WordPress terms, it is the bug that lets a subscriber level account quietly promote itself to administrator.

The root cause is always the same: the application checks that you are logged in, but forgets to check that you are allowed to do this specific thing to this specific object. Proper fixes are a developer’s responsibility, built on a deny by default rule where every request is verified server side. On your side, the practical move is least privilege. Give each person the lowest role that lets them do their job, review your user roles now and then, and never run day to day as an administrator if you do not need to. While you are tightening things, it is worth refreshing your WordPress security keys and salts, which invalidate stolen session cookies and quietly log out anyone riding a hijacked session.

7. Insecure file uploads

Any site that lets visitors upload a file, a profile photo, a resume, a support attachment, is handing strangers a chance to put their own code on your server. If the upload form does not strictly check what it accepts, an attacker can upload a malicious script disguised as an innocent file.

The dangerous outcome is a web shell. The attacker uploads a small PHP file, visits its URL, and now has a remote control panel that runs commands on your server. From there it is a short walk to a full takeover: defacing the site, stealing the database, planting backdoors, using your server to attack others. This is one of the few vulnerabilities that hands over the whole machine rather than just some data.

Good upload handling checks the real file type rather than trusting the name, stores uploads outside the web root or in a folder where scripts cannot execute, and renames files so they cannot be guessed and run. Most of that is the plugin’s job, so be choosy about which upload and form plugins you install and keep them patched. A firewall that inspects uploads, and a malware scanner that flags any suspicious new file in your uploads folder, will catch a lot of what slips through.

8. Security misconfiguration

Sometimes the lock is fine and somebody just left the door open. Security misconfiguration jumped to number two on the 2025 OWASP list, and it covers all the self inflicted exposures: default passwords left unchanged, debug mode left on in production, directory listings that let anyone browse your files, error messages that leak your software versions, and admin panels reachable by the whole internet.

None of these is a clever exploit. They are settings. But each one either lets an attacker walk straight in or hands them a map of exactly which other weaknesses to try. A verbose error page that announces your plugin versions is a gift, because now a bot knows precisely which exploit to fire.

The work here is a tidy up rather than a rebuild. Change every default credential, turn debug output off on the live site, disable directory browsing, and hide the version details where you can. One small WordPress hardening step I always apply is to switch off the built in file editor, so that even if someone does get into the dashboard, they cannot edit your theme and plugin code from inside it. Drop this line into your wp-config.php file:

define( 'DISALLOW_FILE_EDIT', true );

It costs you nothing and removes a favourite tool attackers reach for the moment they get a foot in the door.

9. Missing or half finished HTTPS

If your site still loads over plain HTTP, every piece of data between your visitors and your server travels in the clear, where anyone on the same network can read or tamper with it. Login details, form entries, card numbers, all of it readable. In 2026 there is no excuse left, since certificates are free and take minutes to set up.

The subtler trap is half finished HTTPS, the kind I see constantly. You install a certificate, the padlock shows up, and you assume you are done. But somewhere a stylesheet, a script, or an image is still being loaded over HTTP. That is called mixed content, and it quietly reopens the hole the certificate was meant to close, because an attacker can hijack that one insecure script and rewrite your whole page. Browsers increasingly block it outright, which can also just break your layout.

So do it properly. If you have not yet, follow a clear walkthrough to install an SSL certificate on your WordPress site, then force every request to HTTPS and chase down any mixed content warning until the console is clean. Add an HSTS header once you are confident everything loads securely, and browsers will refuse to even try the insecure version in future.

10. Nulled themes and plugins

This is the one that genuinely makes me wince, because the victim installs the attack themselves. A nulled plugin or theme is a paid product that someone cracked to remove its licence check and is giving away free. The price you actually pay is the backdoor baked into it.

Think about the incentive for a second. Nobody cracks and distributes premium software out of generosity. They do it to plant code that phones home, creates a hidden admin account, or waits quietly for a command. And it is not just back alley download sites any more. In one 2025 case that made the rounds, a bad actor bought up more than twenty five legitimate plugins, sat on them, then pushed a so called compatibility update that planted a dormant backdoor across hundreds of thousands of sites. The supply chain itself got poisoned.

My rule is simple and I will not soften it. Never run nulled software, full stop. If a premium plugin is worth using, it is worth paying for, both for the security updates and for the absence of surprises. If budget is the issue, use a reputable free version from the official directory instead of a cracked premium one. I wrote up the wider case against running a cheap or pirated theme, and after years of cleaning up the aftermath, I stand behind every word of it.

Pro Tip: If you have ever installed a nulled plugin or theme, even once, even years ago, assume the site is compromised until proven otherwise. Removing the nulled file does not remove the backdoor it already dropped elsewhere. Scan the whole site, check for admin accounts you do not recognise, and if anything looks off, treat it as a cleanup job rather than a quick delete.

A few more worth knowing about

A couple of attacks do not fit neatly above but deserve a mention, because you will hear the names.

Server side request forgery, or SSRF, tricks your server into fetching a URL the attacker chooses, often pointing it at internal systems it should never expose. The 2019 Capital One breach, which exposed data on roughly 106 million people, came down to an SSRF flaw reaching cloud credentials. It is more of a concern for custom applications than a typical WordPress blog, but it is climbing the charts as more sites move to the cloud.

Then there is the brute force cousin at the network level, the distributed denial of service attack, where a flood of junk traffic from thousands of machines tries to knock your site offline. It does not steal anything, it just buries you. These have hit record sizes lately, and the only real defence is a content delivery network or firewall service built to absorb the flood, since no single small server can ride one out alone.

The 2026 twist: bots, AI, and shrinking patch windows

Here is what genuinely changed in the last couple of years, and why old advice now feels slow. The web is mostly machines. By 2025, automated bots made up well over half of all web traffic, and the bad ones reached around 37 percent of the total. Most visitors to your login page were never human.

Two things follow from that. First, the gap between a flaw becoming public and that flaw being mass exploited has collapsed. Patchstack measured the median time to mass exploitation for the most heavily targeted WordPress flaws at roughly five hours in 2025. Five hours. The old habit of patching on a relaxed monthly cycle is no longer fast enough, which is why automatic updates and a firewall that can virtually patch a flaw the moment it is known have shifted from nice to have into the baseline.

Second, attackers now have cheap AI helping them write malware, find weak spots, and craft convincing phishing at scale. I am not saying this to scare you. I am saying it because the response is the same fundamentals, just applied with less procrastination. The attackers automated. Your defence has to be automated too, which mostly means letting updates, firewalls, and monitoring run without waiting for you to remember.

How to actually lock your site down

You do not need to be a security engineer to close most of these doors. You need a short routine, applied consistently. Here is the layered setup I would put on any site I cared about.

• Update everything, automatically where you can. Core, plugins, themes, and PHP. This single habit closes the largest share of real world attacks. If you are unsure of the safe way to do it, here is how to update WordPress without breaking things.
• Put a firewall in front of the site. A web application firewall filters out the obvious exploit traffic and can block a brand new flaw before you have even patched it.
• Run a reputable security plugin. A good one bundles malware scanning, login protection, and monitoring in one place. I compared the leading options in this rundown of WordPress security plugins.
• Enforce strong logins. Unique passwords, two factor for everyone, and least privilege roles so a single cracked account cannot wreck the place.
• Harden the install. Disable file editing, lock down file permissions, hide version details, and work through a proper WordPress hardening checklist once, so the defaults stop working against you.
• Keep tested backups, stored off the server. When all else fails, a recent backup turns a disaster into an inconvenience. Pick something dependable from my list of WordPress backup plugins and schedule it so you never have to think about it.

Do those six and you are ahead of the overwhelming majority of sites the bots find. And if you do get hit despite all this, do not panic and start deleting things blindly. Work calmly through the steps to remove malware from a WordPress site, then restore from a clean backup and rotate every password and key.

How a clean theme shrinks your attack surface

I keep circling back to themes because it is where so much of this starts. A large share of the truly nasty compromises I get asked about trace to a theme that was either pirated, abandoned, or coded carelessly in the first place. When the foundation is poor, every other defence is patching over a crack.

That is the whole reason TemplateToaster exists in the shape it does. It is an offline builder that generates clean, standards friendly theme code, without burying you in third party scripts you cannot see or control. You are not inheriting somebody else’s shortcuts, and you are certainly not installing a cracked theme with a stranger’s code hiding in it. Security is never just one product, but starting from a theme you can actually trust removes an entire row of dominoes before they can fall.

Final word

None of the attacks above are magic. Strip away the scary names and almost every one comes down to the same few human habits: software left out of date, passwords reused, settings left on their defaults, and code installed from people who did not have your interests at heart. The bots are tireless, but they are also lazy. They go for the open doors, and the open doors are exactly the ones on this list.

So pick a quiet hour this week and walk the list. Update everything. Turn on two factor. Install a firewall. Take a backup and actually test that it restores. None of it is glamorous, and that is the point. The people who never get hacked are rarely the most technical. They are the ones who did the dull, ordinary maintenance before anything went wrong. Be that person, and the next time a bot comes scanning, it finds nothing to grab and moves on to someone who did not read this.

FAQs

How do I know if my website has already been hacked?

The clearest signs are a sudden drop in traffic, browser or Google warnings that your site is unsafe, unfamiliar admin accounts, spammy pages or redirects you did not create, and your host suspending the account. Many hacks are quiet by design, though, since a compromised site is more valuable to an attacker while it looks normal. The reliable way to be sure is to run a malware scanner, compare your core files against clean originals, and review your list of users and recently modified files for anything you do not recognise.

Which website vulnerability is the most dangerous?

There is no single worst one, because the most dangerous vulnerability is whichever one is currently unpatched on your site. That said, the flaws that hand over the most control are insecure file uploads and SQL injection, since they can lead to full server takeover or theft of your entire database, while broken access control tops the industry’s risk lists because it is so widespread. In practice, the vulnerability that actually gets most ordinary sites hacked is the least exotic of all, an outdated plugin with a publicly known exploit.

Is WordPress less secure than other website platforms?

No, WordPress core is not inherently less secure, and it benefits from constant scrutiny and automatic security updates. WordPress shows up in more hacked site statistics mainly because it powers the largest share of the web and runs on a vast ecosystem of third party plugins and themes, which is where the overwhelming majority of vulnerabilities actually live. A WordPress site that stays updated, avoids nulled software, and uses strong logins is more secure than a neglected site on any platform.

Can a firewall or security plugin alone keep my site safe?

No single tool makes a site safe on its own, and treating a firewall as a complete solution is a common and costly mistake. A web application firewall is excellent at blocking known exploit patterns and buying you time before you patch, but it can be bypassed and it cannot fix weak passwords, bad user permissions, or a backdoor you installed with a nulled plugin. Real security is layered: updates, strong authentication, least privilege, a firewall, monitoring, and backups working together, so that when one layer fails another still holds.

How often should I check my website for security issues?

Treat critical updates as something to apply within a day or two of release, not on a leisurely monthly schedule, because the fastest exploits now go from public disclosure to mass attack in a matter of hours. Automatic updates and an always on firewall handle the urgent end for you, while a deeper review, scanning for malware, auditing user accounts, testing that your backups actually restore, fits well as a monthly habit. The goal is to make the routine parts automatic so the only thing left for you is the occasional deliberate check.

What is the difference between XSS and SQL injection in plain terms?

SQL injection attacks your database, while cross site scripting attacks your visitors. With SQL injection, an attacker sneaks database commands through an input field to read or alter the data your site stores on the server. With cross site scripting, the attacker plants malicious JavaScript that runs in other people’s browsers when they view a page, letting it steal sessions or skim what they type. Both come from the same root mistake of trusting user input, but one targets the server side data and the other targets the client side visitor.