Short answer: WordPress core is not the problem. Of the 11,334 vulnerabilities found in the WordPress ecosystem in 2025, 91% were in plugins, 9% in themes, and six (all low priority) were in core (Patchstack, Feb 2026). The risk is the plugin you installed three years ago, the update window between a disclosure and your next maintenance pass, and the one-in-ten chance a host-level firewall catches the exploit. The fix is boring and specific: fewer plugins, virtual patching to cover the gap, updates on a schedule, code in your own repository, and someone whose job it is. Below is the version you can forward to IT.
The numbers that matter
| Fact | Figure | Source |
|---|---|---|
| New WordPress vulnerabilities, 2025 | 11,334 (+42% on 2024) | Patchstack 2026 |
| Where they were | 91% plugins · 9% themes · 6 in core | Patchstack 2026 |
| Had no vendor patch at disclosure | 46% | Patchstack 2026 |
| Median time to first mass exploitation (heavily exploited CVEs) | 5 hours; 45% within 24 h | Patchstack 2026 |
| Host-level firewalls that stopped real plugin exploits | Missed 87.8% across five major hosts | Patchstack test, Aug 2025 |
| WAF attacks blocked in one quarter | 9.1 billion (Q4 2025) | Wordfence |
Two caveats for your IT reviewer: Patchstack sells virtual patching, so its exploitation-timing and hosting-test figures come from a vendor; and Wordfence’s 2024 annual report puts over 68% of disclosed vulnerabilities at low risk to most sites because they need an authenticated user or a click (Wordfence). The pattern survives the caveats: most of what gets exploited is a plugin, and it gets exploited fast.
Two incidents from this year worth knowing by name
CVE-2026-87902. On 22 September WordPress shipped 7.1.2 for a CVSS 9.2 path-traversal flaw in core affecting every version since 4.7, nearly a decade of releases. Under certain server conditions it allowed remote code execution. Exploitation in the wild began the same day the patch came out; CISA added it to its Known Exploited Vulnerabilities catalog three days later with a 72-hour federal deadline (WordPress.org, The Hacker News, CISA). Core auto-updates handled it for most sites. Sites with auto-updates off, or a custom deployment pipeline nobody runs, did not get it.
The EssentialPlugin supply-chain backdoor. A portfolio of 20-plus plugins with over 200,000 active installs was sold in 2025. The new owner planted a dormant backdoor in a commit labelled as a compatibility fix, then activated it in April 2026 to write web shells onto sites. WordPress.org closed the plugins and force-pushed neutered versions (Patchstack). The lesson your IT team will care about: updating the plugin did not remove the files it had already written. Only a forensic check and a restore did.
What managed hosting covers, and what it doesn’t
We put most WordPress clients on WP Engine, and the honest split looks like this (WP Engine):
| Covered by the host | Still needs a developer |
|---|---|
| Network-level WAF, DDoS mitigation, malware scanning | Application-layer virtual patching for specific plugin CVEs |
| Core auto-updates | Plugin and theme updates on a schedule, tested on staging |
| Daily encrypted off-site backups, 30-day retention, one-click restore | Periodic restore tests with a written recovery time |
| Hosting-portal MFA and SAML SSO (Okta, Entra, Google) | 2FA on wp-admin for editors; the host’s MFA doesn’t cover it |
| Staging and dev environments, Git deploys | Role design (editors are not administrators), quarterly access review |
| SOC 2 Type II and ISO 27001 for the platform | Activity logging inside WordPress, security headers, hardening |
The gap in the middle is the one that bites. A host’s firewall is generic; in Patchstack’s 2025 test, identical sites on five hosts were hit with 11 real plugin exploits and the best host-level defence (Cloudflare’s WAF) stopped four (Patchstack). Vendor test, as noted, but consistent with what we see in logs.
Virtual patching, in one paragraph
A virtual patch is a rule at the application layer that blocks the specific request pattern an exploit uses, so the vulnerability is neutralised before the plugin author ships a fix and before you install it (WP Umbrella). Patchstack maintains the largest rule set; WP Umbrella bundles it in a security add-on for a couple of dollars a site a month, which is what we recommend on every WordPress care plan. An independent 2026 review found 27 of 28 tested CVEs blocked, with a median rule latency of about 14 hours after disclosure (WPSpear). It is a stopgap, not a substitute for updating, but with 46% of vulnerabilities having no patch at disclosure, a stopgap is the whole game for the first days.
Answering the security questionnaire
These are the items that come up in almost every vendor review we have been through, with answers that hold up.
Multi-factor authentication. Hosting portal: MFA or SSO through your identity provider. WordPress admin: a 2FA plugin enforced for every editor and administrator. SFTP and SSH: per-person keys, no shared logins.
Least privilege. Marketing staff are Editors, not Administrators. Administrator accounts are named, counted and reviewed quarterly. Offboarding is a checklist covering WordPress, the hosting portal, GitHub and DNS.
Who owns the code. The theme and any custom plugins live in a GitHub organisation you own, with the developer added as a collaborator and branch protection on main. This is the enterprise norm (WordPress VIP’s whole deployment model is repository-centric with required checks on every pull request, VIP docs), and it is what makes the EssentialPlugin pattern visible: a reviewed Git history is where a benign-looking commit gets caught.
Audit logs. Hosting-portal access logs from the host, a WordPress activity log plugin for content and setting changes, GitHub’s audit log for code.
Backups. Daily, encrypted, off-site, 30-day retention from the host, plus manual checkpoints before every deploy, plus a restore tested on staging at least twice a year with the recovery time written down.
Patching SLA. Core auto-updates on. Plugins and themes within 24–72 hours of release, tested on staging, with virtual patching covering the gap. Critical core issues the same day; 87902 was exploited within hours and CISA allowed three days.
Incident process. Who is paged, how the host is escalated, isolation (take the site offline or restore the pre-incident backup), a forensic check for dropped files, the client-notification timeline, and a written post-mortem.
Compliance. The platform’s SOC 2 and ISO 27001 cover the hosting. Password policy, staff training and data handling are your organisation’s answers, not the host’s or the developer’s.
The pre-launch audit
Every site we ship now gets an automated security audit before go-live: coding-standards and security sniffs (PHPCS with the WordPress rulesets, PHPStan), escaping and sanitisation checks, capability and nonce checks on every form handler, dependency audit for known-vulnerable packages, and a structural review of the theme. That last one sounds dull until you read that the 7.1.2 remote-code-execution path required a theme with a top-level directory starting page- (Equixly), which a static audit would flag. The report goes to your IT team with the fixes already applied, which tends to end the questionnaire conversation early.
The short list for marketing leaders
- Count your plugins. Every one is an attack surface and a maintenance obligation; the last site we launched runs eight, each with a reason to exist.
- Turn on virtual patching. It is the cheapest control with the biggest effect.
- Put updates on a calendar with a person’s name on it, tested on staging.
- Make sure the theme code lives in your GitHub, not your agency’s.
- Ask when the backup was last restored, not just taken.
- Keep auto-updates for core on, so the next 87902 patches itself overnight.
If you would like these checked against your current site, the free audit includes a plugin-risk and security-header pass, and the Trust page has the rest of our answers written down.