WordPress security problems aren't a myth spread by competitors, and they aren't evidence that the WordPress team is careless — core itself is well-audited and rarely the weak point. The problem is structural: an architecture where thousands of third-party plugins run with full privileges inside a public-facing PHP application. Understanding that structure explains both why the incident statistics look the way they do, and why headless architectures sidestep most of the risk rather than patching it.

The Numbers, Plainly

Patchstack's State of WordPress Security report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025 — a 42% jump over the previous year. The distribution is the story:

• 91% of vulnerabilities were in plugins — only two were in WordPress core
• The ecosystem now averages 250+ new plugin vulnerabilities per week
• 46% of disclosed vulnerabilities had no patch available at disclosure time
• Attackers move fast: 45% of heavily exploited flaws were exploited within 24 hours of disclosure, with a median time-to-first-exploit of about five hours

Read those last two together: nearly half of vulnerabilities go public unpatched, and exploitation starts in hours. That's the race every WordPress site owner is running, whether they know it or not.

Why WordPress Is Structurally Exposed

Four architectural facts do most of the damage:

• Every page load executes code. WordPress renders pages with PHP on request, which means the application — and every active plugin — is reachable from the public internet on every visit.
• Plugins run with full privileges. There's no sandbox. A vulnerability in a contact form plugin can read the database, write files, and create admin users, because the plugin API allows all of it.
• The admin lives on the same domain as the site. /wp-admin and /wp-login.php are discoverable on every WordPress site on earth, which is why every WordPress site on earth gets credential-stuffing traffic.
• The ecosystem is the attack surface. The average business site runs 20+ plugins from 20+ different authors with wildly different security practices. You inherit the weakest one.

Security plugins — Wordfence, Sucuri, and the rest — exist to guard this surface, and they help. But note what that means: the standard fix for WordPress security is another plugin inside the same blast radius. If the pattern of plugins patching platform weaknesses sounds familiar, it's one of the signs you've outgrown the platform — and the security retainer is a recurring line in the real cost of running WordPress.

What Headless Actually Changes

A headless architecture separates the content management system from the public website. The visitor-facing site is pre-rendered static files (or a thin rendering layer) served from a CDN; the CMS lives elsewhere, often not publicly discoverable at all. That one design decision removes most of the attack surface:

• No code execution on the public site. A static page can't be SQL-injected; there's no database behind it and no PHP to exploit. The most common WordPress attack categories simply have no target.
• No universal admin URL. Credential stuffing needs a login page to hammer. When the CMS isn't at a guessable path on the public domain, drive-by attacks lose their entry point.
• A radically smaller codebase in the request path. Serving a pre-built page involves a web server and a file. No plugin hooks, no theme functions, no third-party code deciding what executes.

The Honest Caveats

Headless is not magic. The CMS itself still needs authentication, updates, and sane access control; APIs can be misconfigured; build pipelines and tokens need protecting. What changes is the blast radius and the default posture: a vulnerability in the CMS no longer automatically endangers the public site, and doing the secure thing stops requiring a stack of guard plugins. How EmDash implements this — session handling, data protection, and the update model — is documented in EmDash CMS security: how your data is protected.

The Takeaway

You can run WordPress securely — plenty of teams do — but it's an ongoing operational discipline with a real annual cost, run against attackers who exploit new flaws within hours. Or you can choose an architecture where the public site is inert by construction. That difference in defaults is a large part of why businesses keep moving to headless platforms. If security is the push that finally starts your migration, plan it properly with the WordPress migration checklist.