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.
OWASP updated its Top 10 for 2026. Here's what each risk actually means for a WordPress site, ranked by what causes real hacks, not theory.
Five administrator accounts sat hidden in a client's WordPress database for more than a year before we found them.
Not hidden as in unused. Hidden as in WordPress itself couldn't show them to us. The accounts had been deleted from the users table at some point, but their admin-level permissions stayed behind in a separate table, orphaned records tied to user IDs that no longer existed, invisible on the Users page, dating back to around March 2025. That's the part of a WordPress hack most checklists skip. It's not always the moment someone breaks in. Sometimes it's the year nobody could even see what was still sitting there.
OWASP updated its Top 10 for 2025, the first real revision since 2021. Two categories are new. SSRF disappeared into Broken Access Control. Security Misconfiguration jumped from fifth place to second. Most WordPress advice online is still written against the 2021 list, some of it against 2020.
We're not going to walk through all ten risks and pretend they carry equal weight on a WordPress site. They don't. A handful of them explain almost every hack we've cleaned up. The rest matter more to a plugin developer than to you. Here's which is which.
OWASP updates this list every few years using data from real penetration tests and vulnerability disclosures across thousands of applications. The 2025 version is the first update since 2021, and it moved things around.
Two categories are brand new. OWASP built Software Supply Chain Failures out of what used to be a narrower category called Vulnerable and Outdated Components, and gave it third place. Mishandling of Exceptional Conditions took tenth place, covering what happens when an application handles an error badly and leaks something it shouldn't.
OWASP also folded Server-Side Request Forgery, which sat at tenth in 2021, into Broken Access Control. And Security Misconfiguration climbed from fifth place to second, which says something about how most modern breaches actually start. Not a clever exploit. A setting nobody checked.
None of this was written with WordPress in mind. OWASP builds this list for web applications generally, from a custom-coded banking platform to a mobile app backend. WordPress is a different animal. Most of what runs on a WordPress site wasn't written by the site owner, or even by WordPress. It was written by whoever built the plugin you installed three years ago and forgot about. Treating all ten risks as equally urgent, the way OWASP presents them and the way every WordPress-OWASP article we could find treats them too, is the responsible default. It's just not the useful one for deciding what to fix first. That changes which of these ten risks actually decide what happens to your site.
Ten risk categories, but three of them explain almost everything we see on a compromised WordPress site. Get these right and you've closed the door hackers actually use.
This is the new category, and on WordPress it's the whole ballgame. Patchstack's own data puts more than 90% of known WordPress vulnerabilities inside plugins, not WordPress core. You didn't write that code. You probably don't know who did. You just clicked install.
The failure isn't always a coding mistake either. A nulled theme downloaded to save sixty dollars, a plugin whose developer account got compromised and pushed a malicious update, an abandoned plugin nobody patches anymore, all of that lives here. We've written up exactly how this plays out in WordPress Supply Chain Attacks and in Nulled WordPress Themes and Plugins. If you read nothing else in this article, read one of those two.
The Users page on that client's site showed exactly one account: the real one. The database told a different story. Five other accounts had already been deleted from the users table, but their admin-level permission records were still sitting in a separate table, tied to user IDs that no longer existed and invisible from the dashboard. They dated back to around March 2025, well over a year before we found them. Had an attacker ever recreated a matching user ID, those permissions would have snapped straight back onto it.
That's a textbook access control failure: not a clever exploit, but a gap between what one part of the system shows you and what another part still allows. On most WordPress sites this shows up smaller, a plugin that doesn't check permissions properly, or a role you assigned once and forgot to remove. We walk through the full incident in How We Recovered a Hacked WordPress Site, and the login-side defenses in How to Protect WordPress From Brute Force Attacks.
The backdoor on that same site was a plugin called XDav Tracker, sitting in wp-content/plugins/ under a fake description about "computer vision algorithms and tracking cameras." It hid itself from the Plugins list with a single filter hook, so opening Plugins → Installed Plugins showed nothing unusual. It only activated for logged-out visitors, which is why the dashboard looked clean the entire time we were logged in and working. Its payload wasn't even stored on the site: on every page load it called a Polygon blockchain smart contract, read back a URL, and loaded the real malicious script from there, a technique researchers call EtherHiding. Delete the file and the instructions for what to fetch next are still sitting somewhere no cleanup touches.
Our security experts remove malware, fix vulnerabilities, and protect your site.
That's a software integrity failure at the sharp end: unauthorized code, dressed up as authorized code, verifying nothing about where its next instructions come from. It's different from A03. Supply chain failures are about code you didn't vet before installing it. Integrity failures are about code someone planted after you already trusted the site, and stock WordPress has no mechanism that checks whether every plugin file actually belongs.
None of this triggered an alert. WordPress doesn't flag a plugin that hides itself from its own admin list. It doesn't tell you a permission record outlived the account it belonged to. It doesn't email you when a file shows up in wp-content/plugins/ that nobody installed. Stock WordPress logs almost nothing that matters, and by default nothing is watching for it either.
That's Security Logging and Alerting Failures, and it's not what got that site hacked. It's why the compromise ran undetected for well over a year instead of a day. The three risks above decide whether someone gets in. This one decides whether you find out before they've had that long to make themselves comfortable. We cover what to actually watch for in WordPress Site Hacked? How to Investigate.
The other six categories are genuine risks. We just haven't seen them be the reason a WordPress site got hacked, not compared to what we've covered so far.
A02: Security Misconfiguration. Debug mode left on in production, directory listing enabled, default settings nobody changed. Common, but usually a side issue rather than the entry point.
A04: Cryptographic Failures. Weak keys, data sent over plain HTTP. Matters more for what you store than for how you get hacked.
A05: Injection. SQL injection, XSS, the classics. On WordPress this almost never starts with your own code. It starts inside a vulnerable plugin, which really means it's A03 wearing a different name. We go deeper on the XSS side specifically in WordPress XSS Attacks.
A06: Insecure Design. No rate limiting on login attempts, weak session handling. A plugin architecture problem, not something you configure your way out of.
A07: Authentication Failures. Weak passwords, no 2FA, unlimited login tries. Real, but it's the well-worn front door. Most attackers we see are already inside through a plugin before they'd ever need to guess a password.
A10: Mishandling of Exceptional Conditions. New in 2025, and genuinely underrated on WordPress. An error message that leaks your file paths or database structure because WP_DEBUG got left on. Almost nobody's writing about this for WordPress specifically yet.
None of that means ignore them. It means they're rarely the reason we get called in. Fix them on your own schedule, not instead of the four above.
Ten categories, but not ten priorities. Here's how we'd rank them if we were auditing your site tomorrow.
OWASP 2025 category | Risk on WordPress | What actually causes it here | Act first if |
|---|---|---|---|
A03: Supply Chain Failures | High | Vulnerable, nulled, or abandoned plugins and themes | You have plugins you haven't checked in months |
A01: Broken Access Control | High | Orphaned admin permissions, unchecked user roles | You don't know every admin on your site by name |
A08: Integrity Failures | High | Planted backdoor files, unauthorized code changes | You've never run a file-change scan |
A09: Logging and Alerting Failures | High (severity, not entry) | No activity log, no alerts, nothing watching | You'd have no way to know if A01 or A08 already happened |
A07: Authentication Failures | Medium | Weak passwords, no 2FA, unlimited login tries | Your admin login has no rate limit |
A02: Security Misconfiguration | Medium | Debug mode on, exposed files, default settings | You've never audited wp-config.php |
A05: Injection | Medium | Almost always inherited from a vulnerable plugin | You run plugins that handle raw user input (forms, search) |
A06: Insecure Design | Low–Medium | Plugin architecture flaws, not something you configure | You're evaluating a new plugin before installing it |
A10: Mishandling of Exceptional Conditions | Low–Medium | Error messages leaking paths or DB structure | You've left WP_DEBUG on in a live environment |
A04: Cryptographic Failures | Low | Weak keys, unencrypted data at rest or in transit | You store sensitive customer data directly in WordPress |
The first four rows are where every real incident we've worked started, or where it stayed hidden longer than it should have. The rest are worth fixing. They're just not what wakes you up at 2am.
OWASP calls this an awareness document, not a compliance standard. There's no certificate, no audit body, nothing to hang on a wall. So when you see "OWASP compliant WordPress" floating around as a goal, treat it as shorthand for covering the categories that matter, not a checklist you finish once and forget.
Here's what that looks like in practice, weighted toward what actually causes the damage:
Audit every plugin and theme you run, including the ones nobody remembers installing. Remove anything abandoned, nulled, or unmaintained. (A03)
List every admin account by name and reason, and check for orphaned permission records too, not just the accounts you can see. If you can't explain why someone has access, remove it. (A01)
Run a file-integrity scan that flags changes inside plugin and theme folders, not just core. (A08)
Turn on activity logging and alerts. Stock WordPress won't do this for you, and it's the single biggest gap on most sites we look at. (A09)
Add 2FA and a login attempt limit on every admin account. (A07)
Turn off WP_DEBUG and directory listing in production, and confirm wp-config.php isn't publicly readable. (A02, A10)
Six items, not sixty. Most of the value sits in the first four.
Those five orphaned admin permissions are gone now. So is the XDav Tracker plugin that planted the backdoor behind them. What's different this time isn't a longer checklist. It's knowing which four of these ten categories to check first, and building in logging from day one so a compromise like that can't sit quietly for over a year again.
If you're not sure where your own site stands against those four, that's exactly what a security audit is for. Book a WordPress security audit and we'll tell you plainly, not with a compliance badge, but with the same four categories we just walked through.
There's no such thing, officially. OWASP doesn't certify sites or run an audit program. What people usually mean is whether a site reasonably covers the ten risk categories. A WordPress site with updated plugins, real admin account hygiene, and logging turned on covers most of what matters, even without anyone calling it compliant.
Yes, but unevenly. OWASP wrote the list for web applications in general, and a WordPress site inherits most of its risk from installed plugins and themes rather than custom code. That shifts the weight toward Software Supply Chain Failures and away from categories like Cryptographic Failures, which matter more to a team building something like a payment system from scratch.
Two new categories arrived: Software Supply Chain Failures and Mishandling of Exceptional Conditions. Server-Side Request Forgery, which stood alone in 2021, got folded into Broken Access Control. Security Misconfiguration jumped from fifth place to second. Together the changes reflect how most breaches actually start now, through configuration and supply chain problems rather than one clever exploit.
Software Supply Chain Failures. Patchstack's own data puts over 90% of known WordPress vulnerabilities inside plugins, not WordPress core. An outdated, abandoned, or nulled plugin is the most common way we've seen a WordPress site get hacked.
Partially. Most handle authentication well, things like 2FA and login limits, and some do file-integrity scanning. Almost none handle Software Supply Chain Failures directly, since that requires knowing which specific plugins carry known vulnerabilities, not just that a file changed. Pair a security plugin with an actual plugin audit rather than treating the plugin as full coverage.
SEO & Security Expert, 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 →XSS lets hackers run malicious scripts on your WordPress site through comments, forms, or vulnerable plugins. Here's what it is and how to stop it.
Comment spam, form spam and fake registrations all cost you time, leads and security. Here's a business owner's guide to stopping WordPress spam for good.
A brute force attack is a hacker's program trying login after login, thousands or millions of combinations, until one works.
XML-RPC still runs on most WordPress sites by default. See what it does, who still needs it, and a clear answer on when to disable it safely.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
