Almost every WordPress site that gets hacked is compromised through an outdated plugin, not through WordPress itself. Patchstack recorded 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42% jump over the previous year, and 91% of them lived in plugins.
The core software produced a handful. So the practical defence is not “keep WordPress updated” in the abstract. It is controlling what you install, hardening the login, running a firewall that virtually patches flaws before a vendor ships a fix, and keeping backups you have actually tested.
That last point matters more than it used to. The weighted median time from public disclosure to mass exploitation is now five hours. Monthly maintenance cycles cannot win that race on their own.
Key Takeaways
- Outdated plugins and themes, not WordPress core, are where nearly all disclosed vulnerabilities appear.
- Attackers weaponise new flaws within hours, so patching alone leaves a dangerous gap.
- Roughly 46% of vulnerabilities had no vendor patch available on the day they went public.
- Cross-site scripting, broken access control, SQL injection, and CSRF account for most exploit categories.
- Layered defence works: fewer plugins, strong authentication, a WAF, hardened file permissions, and tested backups.
Why WordPress Sites Get Targeted
WordPress powers a huge share of the web, which makes it a volume target. Attack tooling is written once and pointed at millions of installations, so a flaw in a plugin with 50,000 users is worth automating. This is a popularity problem more than a code-quality problem.
The core team’s record supports that reading. Only a couple of vulnerabilities were found in WordPress core across all of 2025. Extensions are a different story. The average site runs 20 to 30 plugins, each one executing with full site privileges, each one maintained by an independent developer whose security practices you cannot inspect.
Patchstack’s 2026 research adds an uncomfortable wrinkle. More than half of plugin developers who were notified of a vulnerability did not ship a fix before the details became public. Paying for a premium plugin does not solve this either. Of the vulnerability reports Patchstack received for premium and freemium components, 76% were exploitable in real attacks.
The Most Common WordPress Vulnerabilities
Below is the full picture at a glance, followed by a breakdown of each category with the fix that closes it.
| Vulnerability | How it gets in | Real-world impact | Primary defence |
|---|---|---|---|
| Outdated themes and plugins | Known published flaw in software you never updated, and abandonware the developer stopped maintaining | The single largest source of breaches. Attackers scan for version numbers and exploit at scale | Remove unused extensions, update fast, use virtual patching for the gap |
| Cross-site scripting (XSS) | Unsanitised input in comment forms, search fields, contact forms, and URL parameters | Session cookie theft, phishing redirects, actions performed as an admin | Input sanitisation, escaping, CSP headers, a WAF |
| Broken access control | A low-privilege account performs an action reserved for admins | Accounted for 57% of attacks blocked in Patchstack testing. Looks like normal traffic | Least privilege, capability checks, specialised firewall rules |
| SQL injection | Malicious SQL passed through a form field into a database query | Read, alter, and delete site data including credentials | Prepared statements, input validation, non-default DB prefix |
| Brute force and weak credentials | Bots cycle through millions of username and password pairs | Full admin takeover with no exploit code needed | 16-plus character passwords, 2FA, login attempt limits, no admin username |
| Cross-site request forgery (CSRF) | An authenticated user is tricked into submitting a request they never intended | Actions executed using the victim’s own valid session | Nonce verification on every state-changing request |
| File upload and permission flaws | A PHP payload uploaded disguised as an image into a writable directory | Remote code execution on your server | Disable PHP execution in uploads, strict file permissions |
| Supply chain compromise | A malicious minor version pushed through a legitimate plugin update | Hidden admin accounts, credential exfiltration, persistent backdoors | Staging review before updates, monitoring, integrity checks |
| DDoS and resource abuse | Coordinated traffic floods aimed at the hosting server | Downtime, lost revenue, ranking damage | Network-level filtering, CDN, rate limiting |
| Sensitive data disclosure | Misconfiguration exposes user data, debug output, and internal paths | Reconnaissance material that fuels the next attack | Disable debug output, restrict directory listing, security headers |
1- Outdated Themes and Plugins
This is the biggest one, and it deserves the top spot. A vulnerability in an extension you never updated is a published, documented, automated attack path. The fix usually exists. It simply was not applied.
Abandonware makes it worse. A developer walks away from a free plugin, the flaw gets disclosed, and the patch never arrives. Sites keep running that code for years. Unused themes sitting deactivated on the server are still code on disk, still reachable, and still exploitable.
Patchstack’s data quantifies the exposure precisely. Around 250 plugin vulnerabilities are disclosed every week, roughly 36 a day, and 46% of them are public before any vendor patch exists.
How to fix it
- Delete every plugin and theme you are not actively using, deactivation is not removal.
- Check the “last updated” date before installing anything. Skip abandonware.
- Apply updates quickly, and review them on staging first rather than pushing straight to production.
- Consolidate overlapping plugins into one well-maintained tool to shrink the stack.
- Run virtual patching through a firewall to cover the window where no vendor fix exists.
2- Cross-Site Scripting
XSS is the single largest category of disclosed WordPress flaws, and it has held that position for years. An attacker injects JavaScript through an input the site fails to sanitise, and the script then runs in a visitor’s browser. From there it can lift session cookies, redirect traffic to a phishing page, and quietly perform actions as a logged-in administrator.
Entry points cluster around anything that accepts input: comment forms, search fields, contact and registration forms, and URL parameters.
How to fix it
- Use WordPress built-in sanitisation and escaping functions on every input and output.
- Add a Content Security Policy header to block unauthorised scripts from executing.
- Validate input on the server side, never trust client-side validation alone.
- Keep form plugins current, since outdated ones carry stale sanitisation habits.
- Put a web application firewall in front of the site to filter injection attempts.
3- Broken Access Control
This one deserves more attention than it gets. Patchstack found that broken access control accounted for 57% of the attacks blocked in its mitigation testing, and it is nasty precisely since it looks like ordinary authenticated traffic. There is no injection pattern for a generic firewall rule to match. A subscriber-level account performs an action reserved for an administrator, and nothing in the request looks obviously malicious.
How to fix it
- Apply least privilege. A content writer needs Author rights, not Administrator.
- Audit your user list and delete dormant accounts from former staff and contractors.
- Review your CORS policy so only trusted origins can make requests.
- Choose a security tool with rules built for WordPress capability checks, since generic rule sets miss this category.
- Log user activity so privilege misuse shows up in an audit trail.
4- SQL Injection
Malicious SQL is passed through a form field and executed against the database. A successful injection lets an attacker read, alter, and delete site data, including user records and credentials. It remains on the OWASP Top 10, and WordPress database misconfigurations widen the target.
How to fix it
- Use prepared statements and parameterised queries in any custom code.
- Change the default wp_ database table prefix, which attack scripts assume.
- Validate and sanitise every field a user can type into, including hidden ones.
- Restrict database user permissions to the minimum the site actually needs.
- Keep database credentials out of version control and rotate them after any incident.
5- Broken Authentication and Brute Force
Automated bots cycle through millions of username and password pairs. The default admin username hands attackers half the credential for free, and WordPress permits unlimited login attempts out of the box. Reused passwords make the rest trivial.
How to fix it
- Never use admin as a username. Rename it and remove the original account.
- Generate passwords of 16 characters and up with a password manager, unique per site.
- Turn on two-factor authentication for every account with publishing rights.
- Limit login attempts and lock out an IP after a small number of failures.
- Add a CAPTCHA to the login form to stop automated scripts.
6- Cross-Site Request Forgery
CSRF tricks an authenticated user into submitting a request they never intended, using their own valid session to do it. Think of a forged instruction sent on your letterhead. Nonce verification is the standard defence, and plugins that skip it leave the door open.
How to fix it
- Verify a WordPress nonce on every request that changes state.
- Set SameSite cookie attributes so sessions are not sent with cross-origin requests.
- Log administrators out after a period of inactivity to shrink the exploitable window.
- Avoid plugins that build custom forms without nonce checks.
7- File Upload and Permission Flaws
The uploads directory has to be writable so WordPress can store media. Attackers exploit that by uploading a PHP file dressed up as an image. If PHP execution is not disabled in the uploads folder, the payload runs.
How to fix it
- Disable PHP execution inside /wp-content/uploads/ at the server level.
- Restrict upload file types to the formats your site genuinely accepts.
- Set directories to 755 and files to 644. Never accept a plugin demanding 777.
- Lock wp-config.php down and block direct access to it.
- Disable the built-in theme and plugin file editor in the dashboard.
8- Supply Chain Compromise
The newest category, and the one that breaks old advice. Attackers now buy legitimate plugins from their developers, credential-stuff developer accounts, and push malicious minor version updates that install hidden admin accounts. Sites with automatic updates enabled applied them overnight without review.
How to fix it
- Review updates on staging before they reach the live site rather than auto-applying everything.
- Run file integrity monitoring so unexpected code changes trigger an alert.
- Watch for administrator accounts you did not create, the usual first payload.
- Prefer plugins with a named, active maintainer and a public disclosure process.
- Keep backups from before each update so a bad push can be rolled back.
9- DDoS and Resource Abuse
Coordinated floods of traffic aim to exhaust your hosting resources until the site slows to a crawl and falls over. Botnets of infected machines do the work, and the goal is downtime rather than data theft.
How to fix it
- Route traffic through a CDN with DDoS mitigation built in.
- Apply rate limiting at the network level before requests reach WordPress.
- Disable XML-RPC if nothing on your site depends on it, since it is a common amplification path.
- Pick a host that offers automatic blocking of known-malicious IP ranges.
10- Sensitive Data Disclosure
Misconfiguration leaks information the public was never meant to see: debug output, internal file paths, user enumeration, and sometimes personal data. None of it is an exploit on its own. All of it is reconnaissance for the next attack.
How to fix it
- Turn WP_DEBUG off on production and route errors to a log file instead of the screen.
- Block directory listing so folder contents cannot be browsed.
- Restrict REST API endpoints that expose usernames to unauthenticated visitors.
- Add security headers and remove version numbers that advertise what you are running.
How H Grant Designs Helps You Secure Your Website
Reading a vulnerability list is one thing. Running these controls week after week across a live business site is another, and that is the part most owners never get to. H Grant Designs has spent more than a decade building and maintaining WordPress sites, and security is handled as an ongoing service rather than a one-time checkbox.
Security Built Into the Build
Hardening is cheapest at launch. Our WordPress web design services in New Jersey start with a lean, deliberate plugin stack instead of a pile of overlapping tools, since every extension you skip is an attack path that never opens. Theme and plugin customisation is done in-house, so the code running on your site is code we can account for.
Clean structure, current PHP, and enforced HTTPS come standard. A site built this way starts with a far smaller attack surface than a template loaded with twenty plugins nobody audited.
Managed Updates and Malware Protection
Core, theme, and plugin updates get applied on a schedule under our care plan, with WordPress security and malware protection running alongside them. Updates are reviewed rather than fired blindly into production, which matters now that supply-chain attacks arrive through the update channel itself.
Daily backups run as part of the same plan. When something does go wrong, restoring from a known-clean copy turns a catastrophe into an afternoon.
Recovering a Compromised Site
If your site is already infected, speed decides how much damage sticks. Our team can clean and restore a hacked WordPress site within roughly two business days, and the care plan includes free malware removal.
The work does not stop at removing the payload. We identify what happened, document the entry point, tell you exactly what was fixed, and hand over the steps that keep it from recurring. Reinfection is common when the original hole stays open, so closing it is the actual deliverable.
Ongoing Monitoring and Support
After recovery, sites move onto managed care: continued backups, updates, malware scanning, and a human to call when something looks wrong. No agency can promise a site will never be targeted again, since attackers keep inventing new methods. What ongoing management does is shrink the window between compromise and detection, which is where nearly all the real cost lives.
Frequently Asked Questions
Is WordPress secure?
The core software is secure and actively maintained. Site-level security depends almost entirely on what you add to it and how you maintain it. WordPress core produced a couple of vulnerabilities last year against thousands in plugins.
How do I secure my WordPress site?
Reduce plugins, enforce strong passwords with two-factor authentication, run a firewall with virtual patching, harden file permissions, keep everything updated, and maintain tested off-site backups. Layers matter more than any single tool.
Why do WordPress sites get hacked?
Outdated plugins and themes, weak credentials, unnecessary admin accounts, insecure hosting, and abandoned software. Attackers automate against known flaws rather than hand-picking targets.
Are WordPress plugins safe?
Individually, most are. Collectively, they are your largest attack surface, since 91% of disclosed vulnerabilities appear in them. Safety comes from installing few, choosing actively maintained ones, and removing the rest.
Does a security plugin replace a firewall?
No. A security plugin scans, monitors, and hardens settings. A firewall filters malicious traffic before it reaches the application. Many tools bundle both, and you want both functions covered.
How often should I update WordPress?
As quickly as patches ship, with the caveat that updates alone are the second line of defence, not the first. Nearly half of vulnerabilities go public with no patch available, and supply-chain attacks have arrived through updates themselves. Staging review plus a firewall covers what updating cannot.
