--- title: 'WordPress security in 2026: what your IT team will ask, and the honest answers' url: 'https://maw11.preview.mountainairweb.com/blog/wordpress-security-for-marketing-teams' markdown: 'https://maw11.preview.mountainairweb.com/blog/wordpress-security-for-marketing-teams.md' date: '2026-08-05' description: '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…' taxonomy: category: - WordPress --- [WordPress](https://maw11.preview.mountainairweb.com/blog/category:WordPress) August 5, 2026 7 min read # WordPress security in 2026: what your IT team will ask, and the honest answers Marketing owns the website; IT owns the risk. This is the briefing that lets both sides sign the same page. Nicholas Murray Author **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](https://patchstack.com/whitepaper/state-of-wordpress-security-in-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](https://www.wordfence.com/wp-content/uploads/2025/04/2024-Annual-WordPress-Security-Report-by-Wordfence.pdf)). 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](https://wordpress.org/news/2026/09/wordpress-7-1-2-release/), [The Hacker News](https://thehackernews.com/2026/09/attackers-exploit-wordpress-cve-2026.html), [CISA](https://www.cisa.gov/news-events/alerts/2026/09/25/cisa-adds-one-known-exploited-vulnerability-catalog)). 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](https://www.patchstack.com/articles/critical-supply-chain-compromise-on-20-plugins-by-essentialplugin/)). 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](https://wpengine.com/secure-wordpress-hosting/)): | 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](https://patchstack.com/articles/hosting-security-tested-87-percent-of-vulnerability-exploits-bypassed-hosting-defenses/)). 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](https://wp-umbrella.com/blog/what-is-virtual-patching-in-wordpress/)). 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](https://wpspear.com/patchstack-review/)). 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](https://docs.wpvip.com/code-deployment/github-repository/)), 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](https://equixly.com/blog/2026/09/24/cve-2026-87902-from-wordpress-path-traversal-to-rce-via-pear/)), 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 1. 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. 2. Turn on virtual patching. It is the cheapest control with the biggest effect. 3. Put updates on a calendar with a person’s name on it, tested on staging. 4. Make sure the theme code lives in your GitHub, not your agency’s. 5. Ask when the backup was last *restored*, not just taken. 6. 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](https://maw11.preview.mountainairweb.com/free-audit) includes a plugin-risk and security-header pass, and the [Trust page](https://maw11.preview.mountainairweb.com/trust) has the rest of our answers written down. ## More from the journal [See all posts](https://maw11.preview.mountainairweb.com/blog) WordPressSep 16, 2026 ### Headless WordPress in 2026: why we usually say no (and what we recommend instead) Headless WordPress doubles your systems, drops the editor preview and most plugins, and the reasons people wanted it… [Headless WordPress in 2026: why we usually say no (and what we recommend instea…](https://maw11.preview.mountainairweb.com/blog/headless-wordpress-in-2026) WordPressSep 9, 2026 ### What a WordPress maintenance plan should actually cover (and what most leave out) Hosting plans, cheap update subscriptions and developer care plans all call themselves WordPress maintenance. What each covers, the… [What a WordPress maintenance plan should actually cover (and what most leave ou…](https://maw11.preview.mountainairweb.com/blog/what-a-wordpress-maintenance-plan-should-cover) WordPressJul 22, 2026 ### WordPress or flat-file: how to choose for a marketing site in 2026 A practical decision guide for marketing teams and agencies: when a flat-file CMS like Grav beats WordPress, when… [WordPress or flat-file: how to choose for a marketing site in 2026](https://maw11.preview.mountainairweb.com/blog/wordpress-or-flat-file-for-a-marketing-site) --- ## Navigation - Parent: [Blog](https://maw11.preview.mountainairweb.com/blog.md) - Previous: [How to migrate a website without losing your rankings](https://maw11.preview.mountainairweb.com/blog/migrate-a-website-without-losing-rankings.md) - Next: [WCAG 2.2 for marketing websites: what changed, what the law says, what it costs to ignore](https://maw11.preview.mountainairweb.com/blog/wcag-2-2-for-marketing-websites.md)