WordPress runs somewhere around 43% of the web, and that number is exactly why it attracts so much automated attack traffic. Nobody is manually typing your domain into a terminal and trying to break in by hand, the overwhelming majority of WordPress compromises come from bots crawling the entire internet, fingerprinting which CMS a site runs, checking its plugin and theme versions against a database of known vulnerabilities, and firing an automated exploit the moment a match turns up. Understanding hacking this way changes how you defend against it: you’re not protecting against a person who specifically wants your site, you’re protecting against a scanner that doesn’t care whose site it is, only whether the door happens to be unlocked.
Outdated software is the single biggest factor, and here’s the actual mechanism
When a WordPress core update, or a plugin/theme update, patches a security vulnerability, the changelog and the diff between the old and new version are both public. Security researchers and attackers alike read those diffs. Within days, sometimes hours, of a patch landing on WordPress.org, automated tools exist that can identify sites still running the vulnerable version and attempt the exploit at scale, often against tens of thousands of sites in a single run. This is why “I’ll update it later” is so much riskier for WordPress than for, say, a desktop application nobody’s actively scanning, the patch itself functions as a public announcement of exactly what was broken and, often, exactly how to exploit it in unpatched installs. Sites running a plugin more than a few versions behind current, especially ones with published CVEs, are essentially sitting in a shooting gallery with the target already painted on.
Weak passwords and why “complex enough” isn’t really the bar
Brute-force and credential-stuffing attacks against wp-login.php are constant background noise for any WordPress site with a public login form, and they don’t need to guess your password from scratch, credential-stuffing tools work from massive leaked-password databases collected from breaches at completely unrelated services, testing the assumption that a meaningful percentage of people reuse passwords. A password that’s individually “strong” (mixed case, numbers, symbols, twelve characters) is still vulnerable if it’s a password you’ve used anywhere else that’s ever been breached, because the attacker isn’t guessing character combinations, they’re replaying a password they already know is yours from a different, unrelated leak. The actual defense here is a unique, randomly generated password stored in a password manager, combined with two-factor authentication so a correctly guessed password alone still isn’t enough to get in.
Shared hosting and the cross-contamination problem
On shared hosting, multiple customer accounts often run on the same physical server, and depending on how strictly the host isolates accounts from each other, a vulnerability in one customer’s outdated, unrelated site can sometimes be leveraged to reach files belonging to a neighboring account on the same server, a pattern usually called cross-site contamination. This isn’t a WordPress vulnerability at all; it’s a hosting architecture issue, and it’s precisely why “my site was hacked and I have no idea how, I keep everything updated” cases sometimes trace back to a completely different, badly maintained site sharing the same server rather than anything the victim did wrong. Hosts with proper account isolation (each account genuinely sandboxed from every other) largely eliminate this risk, which is one of the more concrete, measurable reasons managed WordPress hosting commands a premium over cheap shared plans.
Security plugins don’t prevent attacks, they change your odds of catching one
It’s worth being precise about what a security plugin like Wordfence or Sucuri actually does, because “install a security plugin” gets repeated as advice without much explanation of the mechanism. These plugins primarily do three things: a web application firewall that blocks known malicious request patterns before they reach WordPress’s own code, file-integrity monitoring that alerts you when core, plugin, or theme files change unexpectedly, and rate-limiting or lockout on repeated failed login attempts to blunt brute-force attacks. None of that makes your site invulnerable, a genuinely novel exploit against a plugin nobody’s patched yet (a zero-day) can still get through a WAF that only recognizes known attack signatures. What a good security plugin buys you is faster detection and a much smaller window between compromise and discovery, which matters enormously because damage compounds the longer an intrusion goes unnoticed.
SQL injection and cross-site scripting, explained without the jargon
Both of these vulnerability classes come from the same root cause: a plugin or theme accepting user input (a form field, a URL parameter, a comment) and using it somewhere sensitive without properly validating or escaping it first. SQL injection happens when that unescaped input gets concatenated directly into a database query, letting an attacker craft input that changes the query’s meaning entirely, turning a simple “look up this post” query into one that dumps the entire wp_users table, including password hashes. Cross-site scripting (XSS) happens when unescaped input gets rendered back into a page as HTML, letting an attacker plant a <script> tag that runs in another visitor’s browser, potentially stealing their session cookie or performing actions as them, including an admin visitor. WordPress core has mature, well-tested functions for handling this correctly, $wpdb->prepare() for queries, esc_html(), esc_attr(), and similar for output, and the vast majority of these vulnerabilities in the wild come from third-party plugins and themes that skipped or got these functions wrong, not from WordPress core itself, which is precisely why plugin quality and update discipline matter as much as core updates.
File permission mistakes that quietly widen the attack surface
WordPress’s own hardening documentation recommends specific permission levels, typically 644 for files and 755 for directories, tighter still (440/400) for wp-config.php on hosts that support it, and permissions looser than that, often set accidentally by an FTP client defaulting to 777 “to make sure it works,” mean that if an attacker gets any foothold at all, even a low-privilege one, overly permissive file permissions make it trivial to write or modify files they shouldn’t be able to touch. This is a case where the fix costs nothing and takes minutes, but it’s rarely checked because everything “works” either way right up until it doesn’t.
Excess user privileges turn a minor breach into a major one
WordPress’s role system (Subscriber, Contributor, Author, Editor, Administrator) exists specifically so that most accounts don’t need, and shouldn’t have, the ability to install plugins or edit theme files. A common but avoidable mistake is granting every team member Administrator access “so nobody’s blocked,” which means if any one of those accounts gets phished or has a reused, breached password, the attacker inherits full site control immediately rather than the limited capabilities a properly scoped role would have contained them to. Auditing Users → All Users periodically and demoting accounts to the least privilege they actually need is one of the cheapest structural improvements available, and it matters more as a team grows, not less.
No SSL, and why it’s about more than the padlock icon
Running a site without HTTPS means every request between a visitor’s browser and your server travels in plain text, readable by anything sitting on the network path between them, a public WiFi network, a compromised router, an ISP. For a WordPress admin logging in over an unencrypted connection, that includes the login credentials themselves, transmitted in the clear and trivially interceptable by anyone positioned to watch that traffic. Free, automated certificates from Let’s Encrypt removed essentially every excuse for skipping this, and most hosts now provision one by default, but sites migrated from older setups or self-managed servers sometimes still run without one.
Unmonitored sites: the compromises that just sit there
A large number of WordPress sites are set up once and then essentially forgotten, a portfolio site from years ago, a promotional microsite for a campaign that ended, a blog nobody’s posted to in a year. These sites often keep running on cheap hosting with nobody checking on them, which means a compromise can persist for months or years without anyone noticing, quietly serving spam content, redirect malware, or hosting phishing pages under a domain with whatever residual trust and search ranking it accumulated while legitimate. If a site isn’t actively maintained anymore and isn’t providing enough value to justify keeping it live, seriously consider decommissioning it rather than leaving it as unmonitored infrastructure; if it does need to stay up, at minimum keep it updated and check it periodically even without active content work, since an abandoned-but-live WordPress install is functionally the same attack surface as an actively used one.
Backups aren’t prevention, but their absence turns every other failure into a catastrophe
None of the categories above are made less likely by having backups, but every one of them is made dramatically less damaging by having them. A site with automated, tested, offsite backups can typically be restored to a known-clean state within an hour of discovering a compromise; a site without them faces a from-scratch rebuild, lost content, and in cases where the hack has been live for a while, no clean historical version to even roll back to. Treat backups as the safety net underneath every other security measure, not a substitute for any of them, and specifically test a restore occasionally, since a backup nobody has ever successfully restored from is a backup you don’t actually know works.
Nulled plugins and themes: backdoors distributed by design
A meaningful share of WordPress compromises trace back to a premium plugin or theme downloaded for free from somewhere other than its actual developer or WordPress.org, a “nulled” copy with the licensing check stripped out. The economics here are worth understanding: whoever redistributes a nulled plugin usually isn’t doing it out of generosity, they’re doing it because they’ve inserted a backdoor into the code first, and every site that installs it becomes a foothold they can activate later, often for exactly the kind of automated redirect-spam or credential-harvesting campaigns discussed elsewhere. There’s no reliable way to audit a nulled file for safety without a full code review, which defeats the point of downloading it for free in the first place, and the only durable fix is treating “found it on a random forum or torrent” as an automatic disqualifier regardless of how legitimate the plugin looks once installed.
CSRF: tricking a logged-in admin into acting without knowing it
Cross-site request forgery is a subtler category than SQL injection or XSS, and it exploits trust in a different direction: instead of attacking the server, it attacks the fact that a browser will automatically include a logged-in user’s cookies with any request to a site they’re authenticated on, even if that request was triggered by a completely different, malicious page the user happens to have open in another tab. A poorly built plugin that performs a sensitive action (deleting content, changing a setting, creating a new admin user) based on a simple GET request with no verification that the request genuinely originated from its own admin form is vulnerable to this: an attacker just needs to get a logged-in administrator to click a link or load an image tag pointing at that vulnerable endpoint, and the browser does the rest automatically. WordPress’s nonce system (wp_nonce_field(), check_admin_referer()) exists specifically to close this gap by attaching a single-use, time-limited token to legitimate requests that a forged request from elsewhere can’t reproduce; plugins that skip nonce verification on state-changing actions are a recurring source of real-world CVEs.
Phishing targets the person, not the code
No amount of hardened code stops an attacker who convinces a site administrator to hand over credentials directly. A common pattern: a fake “your plugin license has expired” or “urgent security update required” email, styled convincingly enough to match a real vendor’s branding, linking to a fake login page that captures whatever’s typed into it. Because these campaigns target the human rather than a technical flaw, the defense is procedural rather than a plugin setting, verify unexpected urgent emails by navigating to the vendor’s site directly rather than clicking the email’s link, and treat any login prompt that arrived via email link with the same suspicion you’d apply to a stranger asking for your house key. Two-factor authentication limits the blast radius here too, since a phished password alone typically isn’t sufficient to complete a login if a second factor is required.
How WordPress’s own security process actually works
WordPress core has a dedicated security team that receives vulnerability reports privately, develops and tests a fix, and coordinates a release, often bundled as an automatic background security update that applies without the site owner needing to do anything, this auto-update mechanism for security releases has existed since WordPress 3.7 and is a large part of why core-level compromises are comparatively rare next to plugin and theme vulnerabilities. The same discipline doesn’t automatically extend to the plugin ecosystem: WordPress.org’s plugin review team does scan for known-bad patterns and can pull a plugin from the directory once a vulnerability is confirmed, but a plugin author’s response time to actually patch varies enormously, and abandoned plugins, the “not updated in over two years” warning WordPress now surfaces in the admin, may never get patched at all. Databases like WPScan’s vulnerability feed track disclosed plugin and theme CVEs specifically, and running your installed plugin list against it periodically (several security plugins do this automatically) is a concrete way to know your actual exposure rather than assuming “it’s popular, so it must be fine.”
A realistic incident timeline
A typical automated compromise doesn’t look like a dramatic break-in; it looks mundane right up until it isn’t. A scanner identifies a site running a contact-form plugin two major versions behind current, with a known unauthenticated file-upload vulnerability. The exploit uploads a small PHP file disguised with an innocuous name into the uploads directory, which by default doesn’t execute PHP on well-configured servers but does on plenty of poorly configured shared hosts. That file becomes a simple web shell, a remote command interface, giving the attacker the ability to modify any file the web server user can write to, which on shared hosting is usually the entire WordPress install. From there, the attacker might inject spam content into old posts for SEO purposes, add a hidden admin account, or drop the redirect malware covered in other guides on this topic. None of this required a human attacker’s individual attention at any point; the entire chain, from initial scan to persistent backdoor, runs unattended and can complete in under a minute once a vulnerable target is identified.
Putting it together as an actual checklist
Keep WordPress core, every plugin, and every theme updated, and remove anything inactive that you’re not using, since inactive components remain a scannable attack surface even when deactivated. Use unique, randomly generated passwords stored in a password manager and enable two-factor authentication for every account with publishing or admin access. Choose a host with genuine account isolation if you’re on shared infrastructure, install a reputable security plugin for firewall coverage and file-integrity monitoring, review file permissions against WordPress’s hardening guidelines, audit user roles down to least privilege, run HTTPS everywhere, and maintain tested, automated backups stored somewhere other than the same server. None of these individually guarantees safety, but together they close the overwhelming majority of doors that automated scanners are actually checking for, which is the threat model that accounts for most real-world WordPress compromises.
The uncomfortable but useful way to think about this: WordPress itself, kept current, is not the weak point in most compromises. The weak point is almost always somewhere in the long tail of third-party plugins, recycled passwords, careless file permissions, and human trust that surrounds a core install that’s usually doing exactly what it’s supposed to. Treating security as an ongoing maintenance habit rather than a one-time setup step is what separates sites that stay clean for years from sites that get compromised, cleaned up, and compromised again within months because the underlying gaps that let the first attack through were never actually closed.
Related reading:
Best Managed WordPress Hosting Providers