WordPress vs Next.js Security: Where the Attacks Actually Come From

Eleven thousand holes, six of them in core

The best public numbers come from Patchstack, a company that runs a large WordPress vulnerability database and bug bounty. Its State of WordPress Security in 2026 report, covering 2025, is worth reading in full. The figures below are Patchstack's, quoted from that report.

• 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025, a 42% increase on 2024.
• 91% were in plugins and 9% in themes. Only 6 were reported in WordPress core.
• 46% had no fix from the developer by the time they were publicly disclosed.
• 1,966 (17%) were rated high severity, the kind likely to be exploited in automated mass attacks.
• For the most heavily targeted vulnerabilities, the weighted median time from disclosure to first exploit was 5 hours.
• Premium components were no safer: 76% of the vulnerabilities found in them were exploitable in real attacks, and premium products had three times more known exploited vulnerabilities than free ones.

Read that list fairly. It does not say WordPress is insecure. It says the WordPress core team does a good job and the extension economy around it is enormous, uneven and fast-moving. Your site's risk is the sum of every plugin and theme you have installed, how quickly each vendor patches, and how quickly you apply the patches.

Five ways attackers get into a WordPress site

Plugins and themes with known holes

This is the main road, per the numbers above. Even well-run vendors ship fixes regularly: Avada 7.16.2, released September 30, 2026, patched six vulnerabilities including cross-site scripting in form submissions. Kadence's Shop Kit add-on drew a Patchstack advisory for a high-priority SQL injection in versions up to 3.0.6. A patch only protects sites that install it, and a lapsed license often means the patch never arrives.

Password guessing at the login page

Every WordPress site has its login form at the same well-known address, so bots try passwords against all of them, all day. The official WordPress hardening guide recommends strong passwords and two-step authentication for exactly this reason. Neither is on by default for every user.

xmlrpc.php, the side door

XML-RPC lets apps manage a WordPress site remotely, and the xmlrpc_enabled filter defaults to on. In 2015, Sucuri documented attackers using its system.multicall method to try hundreds of passwords in a single request, slipping past tools that counted one request as one attempt. WordPress 4.4 blunted that trick, but the endpoint remains a common target, and most sites that do not use it would lose nothing by blocking it.

Installs nobody updates

When a fix is released, the details of the flaw become public too, and the hardening guide is blunt that older versions are what attackers go after. The abandoned brochure site, the staging copy left online, the plugin whose author moved on: each is a version number waiting to be matched against a public list.

Nulled themes and plugins

A nulled theme is a pirated premium theme with the license check removed. It often comes with a passenger. Sucuri found a webshell inside a nulled theme that could disable security plugins and send database credentials to a remote server, and Patchstack's analysis of the WP-VCD malware shows it spreading through free downloads of premium plugins and injecting itself into other themes' functions.php files. The money saved on a license is usually spent on malware removal.

The five-hour problem with weekly updates

Put two of Patchstack's numbers side by side. The most targeted flaws are exploited a median of five hours after disclosure. Nearly half of disclosed flaws have no fix at that moment. Now picture the typical maintenance routine: someone logs in on Monday, sees eleven updates waiting, applies them one click at a time on the live site, and hopes nothing breaks. Even a diligent owner is days behind the attackers, not hours.

There are good tools for closing the gap. Firewalls with virtual patching, from Patchstack and others, block known exploits before a vendor ships a fix. Automatic plugin updates help when they do not break the layout. But Patchstack also tested standard hosting-level defenses against real exploits and reports that only 26% of attacks were blocked. Security on WordPress is a process you run forever, layered on top of a stack you did not write. That is not a reason to panic. It is a reason to count your plugins and to pay someone to watch them. Our hosting and maintenance plans include tested updates, off-server backups and security monitoring.

Every plugin is a stranger you have handed a key to the building. Most of them are honest. All of them lose keys.

What can still go wrong on a Next.js site

No stack is invulnerable, and anyone who tells you a Next.js site cannot be hacked is selling something. The attack surface is smaller and different. Here is what it actually contains, with real incidents.

The difference is how fixes travel. When CVE-2025-55182 landed, a patched Next.js version was available, and every site that used it needed one dependency bump, a build and a deploy. On a WordPress stack the equivalent event can mean waiting on several vendors, each with its own release date and license server.

The third option

Athena CMS, with AI agents on staff.

Not a theme and not a blank Next.js repo. The content system we put behind every custom site: plain fields, a real preview, every version kept, and AI agents that handle the chores a plugin only nags you about.

• PPicassoImages
• AApolloSite analysis
• AAresCompetitor watch
• PPrometheusContent holes
• AAtlasPage depth and structure
• DDelphiAI search visibility

ZDAOAand 12 more agents. Two come with Athena; the rest are monthly add-ons.

Meet the agentsTake the Athena tour

PPicassoWeekly · ImagesAApolloWeekly · Site analysis

Why the two attack surfaces have different shapes

The pattern is the same one that runs through every row of our WordPress vs Next.js comparison: WordPress lets many parties change a live system, and Next.js funnels every change through one door that has a lock and a log. The plugin dependency comparison explains how that plays out beyond security, and theme pages like Divi vs Next.js and Flatsome vs Next.js show it for specific stacks.

How Aegis and Argus keep watch on an Athena site

A smaller attack surface still needs someone watching it. On the sites we build, Athena CMS assigns that job to AI agents. Aegis checks every day for intrusions and backdoors. Argus watches the edges where trouble shows first: failing forms, broken links, slow pages and certificates about to expire. Neither replaces a developer applying a framework patch. They make sure someone knows the same day when something looks wrong, instead of when a customer phones about a strange redirect.

There is also less for an intruder to reach. Editors log in to Athena, not to a dashboard bolted onto the public website, and their edits change content, not code. Every version is kept, so a bad change can be rolled back. Compare that with the WordPress approach of a security plugin, a firewall plugin, a backup plugin and a login-limiting plugin, each with its own settings page and renewal date. The longer version of that comparison is at Athena vs WordPress.

Staying on WordPress? Harden the doors you keep

Plenty of businesses should stay on WordPress, and a well-kept WordPress site is a hard target. These steps follow directly from where the attacks come from.

1. 1

   Cut the plugin list

   Every plugin you remove is a vulnerability you cannot have, and usually a faster page too. Delete deactivated ones as well; their files still sit on the server.

2. 2

   Keep every license current

   Premium themes and builders update through their license. An expired key means the next security fix never arrives.

3. 3

   Lock the login

   Strong unique passwords, two-step authentication for every admin, and as few admin accounts as the business can manage with.

4. 4

   Block xmlrpc.php if nothing uses it

   Check first: some apps and integrations rely on it. If none do, block it at the server or firewall.

5. 5

   Install only from the source

   WordPress.org or the vendor's own site. Never a nulled copy, however convincing the download page looks.

6. 6

   Back up off the server

   A backup stored on the hacked server is not a backup. Keep copies elsewhere and test a restore.

If the site is already showing spam pages in Google, unknown admin users or redirects to strange domains, stop tuning and start cleaning: our WordPress malware removal service finds the backdoor as well as the symptom. Browser warnings have their own fix page at not secure warning, and if Google has already dropped you, see Google deindexed my website.

When security alone justifies a rebuild

Security is rarely the only reason to leave WordPress, but it is often the one that ends the debate. The site has been cleaned twice this year. The builder license lapsed and nobody wants to renew it. The plugin count passed thirty and nobody remembers what half of them do. At that point, each cleanup buys a few months, and the bill keeps coming.

A rebuild through our WordPress rebuild in Next.js service moves your content as data into fresh templates, so PHP backdoors hiding in the old theme folder have nothing to ride along in. The steps and timing are laid out under WordPress to Next.js and migration cost. For the other rows people weigh alongside security, see WordPress vs Next.js SEO and Core Web Vitals.