TL;DR
- WordPress security in 2026 is mostly a plugin problem, not a core problem. Patchstack counted 6,700 new ecosystem vulnerabilities in the first six months of 2025. 89% landed in plugins, exactly one in core. Webhostmost tracked 333 new disclosures in a single week of January 2026. 71% shipped without a patch ready.
- The smallest checklist that actually protects a small site is eight items long. Strong unique passwords and two-factor authentication on every admin. Auto-updates on for core. Plugin and theme updates applied within a week. Abandoned plugins replaced. Clean wp-config. HTTPS everywhere. Off-site backups, tested. A security plugin or host firewall reading login attempts.
- Two-factor authentication is the single most effective move. Fifteen minutes with a free plugin and a free phone app. The auth gate breaks brute-force, credential reuse, and most session hijack patterns at once.
- Backups are the recovery layer that costs almost nothing and pays back the day you actually need them. Free UpdraftPlus, free off-site destination, one quarterly restore test. The cheapest insurance available.
- Plugins last updated more than 12 months ago are the largest risk concentration. The dashboard tells you about pending updates. A quarterly plugin audit catches abandonment. Patchstack’s 2025 State report makes the disconfirming case directly — relying on updates and security plugins alone is not enough. The auth gate is the part most often skipped.
The plugin update list shows seven pending entries. Three of them are flagged as security releases. The site owner is asleep. The exploit attempt against one of those plugins is awake.
That gap between disclosure and update is the hole in most small-website security postures. It does not require a security professional to close it. It requires a checklist short enough to actually finish.
Most of the work is free. Most of the work is the work small-website security has always been about — strong passwords, current software, off-site backups. The new layer is the volume of plugin disclosures arriving every week, and the discipline of two-factor authentication that is now table stakes.
Think of the checklist as something that fits on the back of a postcard, kept where you actually see it. Not the 200-step audit that lives in a forgotten browser tab. The postcard is the thing that gets done.
Why is WordPress security harder for a small website than it used to be?
The volume of plugin disclosures is the first reason.
Patchstack’s 2025 mid-year vulnerability report counted 6,700 new WordPress vulnerabilities in the first six months of 2025 alone. Eighty-nine percent of those landed in plugins. Themes carried 386. WordPress core itself carried exactly one. Of the total, 41 percent were classed as exploitable in real-world attacks. Roughly fifty-eight percent required no authentication at all to exploit. An attacker could run the exploit without a username or a password.
The patch-gap is the second reason. Webhostmost’s January 2026 audit guide tracked 333 new vulnerability disclosures in a single week. Most of those shipped without a patch ready — seventy-one percent had no fix at the time of disclosure. The plugin you trusted yesterday may have a public CVE today and no fix for another two weeks.
The auth gap is the third. Most attack-volume against small WordPress sites still goes through the front door — automated scripts hammering the login form. A site running on default settings, with one admin and a six-character password, is the easy target. The plugin disclosures are the new pressure on top of an old problem.
The reassuring news, often missed by security-plugin marketing copy, is that WordPress core is mostly not the source. Auto-updates apply core security releases without your involvement. The fifteen plugins on your site are the surface area, not the WordPress installation itself.
What is the smallest checklist that actually protects you?
Eight items.
Strong, unique passwords and two-factor authentication on every administrator account. Auto-updates on for WordPress core. Plugin and theme updates applied within a week of release. Abandoned plugins replaced or removed. A clean wp-config with DISALLOW_FILE_EDIT set. HTTPS everywhere. Off-site backups, tested for restore. A security plugin or host-provided firewall watching login attempts.
That is the whole list. Most items are free. Most items take less than thirty minutes once. A few — the plugin audit, the quarterly restore test — are recurring habits, not one-time installs.
The mental model behind WordPress security splits the attack surface into four layers. Hosting and operating system. WordPress core. Plugins and themes. Users and content. The threats concentrate sharply in layers three and four. Layer one is the host’s job. Layer two is the auto-updater’s job. Layers three and four are yours — and the eight-item checklist covers them.
Skip the 200-step audit. The postcard is the thing that gets finished.
How do you turn on two-factor authentication without paying for it?
Install one free plugin. Two Factor or WP 2FA both work, and both are maintained. Both are in the WordPress.org plugin directory.
Activate it for your administrator user first. Scan the QR code with the free Google Authenticator app on your phone, or with Authy if you prefer. Test it once — log out, log back in, confirm the six-digit code from your phone unlocks the dashboard. Then turn it on for every other admin or editor account on the site.
Total cost zero. Total time fifteen minutes. Total effect a brute-force login attempt now needs your phone in addition to your password. The single largest share of automated attacks against small WordPress sites bounces off the second factor.
Print the recovery codes the plugin generates. Keep them in the same place you keep your passport. Phones get lost — recovery codes are the unbrick path.
The auth gate is the move most often skipped. The plugin disclosures get the headlines. The unattended admin login gets the actual compromise.
Which plugins put a small site most at risk?
Three categories.
Plugins you installed once for one task and never used again. The contact-form plugin from the theme demo that ships with five popups. The SEO plugin you tried for a week before going back to the one your friend recommended. Each is a piece of code running on your server, with full access to your database, even when nothing on the public site uses it. Open Plugins, Installed Plugins, deactivate the ones you do not recognize, then delete them.
Plugins last updated more than 12 months ago. The plugin directory shows the last-update date on every listing. A plugin without a release in over a year is usually abandoned. Replace it with a maintained alternative, or remove the feature it provided. The Webhostmost guide identifies abandoned plugins as the highest-risk category in the small-site cohort — vulnerabilities discovered in them never get fixed.
Plugins from a vendor with one or two reviews, no public changelog, and no support history. The directory’s review-count and active-installation numbers tell most of the story. A plugin with fifty active installations and a single five-star review is not a vetted choice. One with fifty thousand active installations and a six-year track record is.
The dashboard’s update list tells you about the first two categories the moment you log in. The third needs a quarterly audit — twenty minutes, once a quarter, walking the plugin list against the directory page for each one. That cadence is enough.
Want a longer-form companion at the in-house-marketer tier? The AI-audited WordPress security hardening pass walks the plugin and CVE cross-reference.
What goes in wp-config, and what does not?
Goes in — DISALLOW_FILE_EDIT set to true. The WordPress.org hardening handbook names this constant as the primary wp-config setting for a production small site. With it set, an attacker who somehow reaches the dashboard cannot paste malicious code directly into a theme file from the editor.
Goes in — WP_DEBUG set to false in production. Debug output exposes file paths and stack traces. An attacker reads them like a map.
Goes in — eight unique authentication keys, generated from the WordPress.org salt generator at api.wordpress.org/secret-key/1.1/salt/. Each WordPress install gets its own. Reusing the keys from a different site is a credential leak.
Does not go in — API keys for third-party services, unless the plugin’s documentation specifically tells you to put them there. Most plugins prefer their own settings page.
Does not go in — plain-text comments containing real database credentials left over from a host migration. The site moved last summer. The comment block at the top of wp-config still has the old credentials in it. Strip those.
Does not go in — shell commands, debug print statements, or anything that will run on every page load. The file is read on every request, and a slow line there slows the entire site.
How often do you back up, and where do the backups live?
Daily for a site with active content. Weekly for a brochure site that changes once a month. The free UpdraftPlus plugin schedules both at no cost.
The destination matters more than the cadence. A backup that lives on the same server as the live site is not a backup against site compromise. If the site gets ransomwared or wiped, the backup goes with it. Send backups off-site — a free Google Drive folder works, a free Dropbox folder works, a free Backblaze B2 account works. UpdraftPlus connects to all three with a few clicks.
Keep multiple historical versions. Compromises are often discovered weeks after the fact — the most recent backup may already be infected. A two-week retention window is the minimum. A three-month rolling retention is comfortable.
Test the restore at least once a quarter. A backup nobody knows how to restore is not a backup. Spin up a free local WordPress install, point UpdraftPlus at the most recent backup, restore it, confirm the homepage loads. Twenty minutes — cheap insurance.
The full walkthrough lives in the backup verification plan article.
What can you stop worrying about?
WordPress core itself, in 2026, is mostly not the problem. Patchstack’s 2025 mid-year report counted exactly one vulnerability in core out of 6,700 across the ecosystem. The auto-updater applies core security patches on its own. Unless you have specifically disabled auto-updates, that layer is handled.
Hosting-layer security on a managed WordPress host or a reputable shared host. The host’s job includes the operating system, the web server, the PHP runtime, and the database engine. A small business on Bluehost, SiteGround, or Kinsta is paying for that work to be done.
The “WordPress is insecure” framing pieces. They are usually selling a security plugin or a managed-host upgrade. The honest answer is that WordPress is as secure as the choices made on top of it. Skipping the eight-item checklist is the insecure choice. Running the checklist is the secure one.
The 200-step audit guides. They are written for enterprise environments with full-time security staff. A small website with one owner does not have the budget for the audit and does not need it. The eight-item postcard is enough for the threat profile a small business actually faces.
Most of what is sold as “WordPress security” to small-website owners is solving the wrong problem at the wrong tier. The plugins on your site are the problem. The dashboard scare-modal selling you something else is the distraction.
Other questions worth answering
Should you disable the xmlrpc.php endpoint?
Yes, in most cases. The xmlrpc.php endpoint exists for legacy mobile apps and pingbacks. Most small sites do not use it. The endpoint sits open as a second login surface that attackers automate against.
Patchstack’s 2025 mid-year report found 57.6% of WordPress exploits needed no authentication. A one-line .htaccess block or a security plugin kills the endpoint in under a minute.
What file-system permissions does the hardening handbook recommend?
Three numbers cover the small-site case. Directories at 755, files at 644, and wp-config.php at 600 or 440. The WordPress.org Hardening Handbook (updated January 7, 2026) names those defaults to verify after any host migration.
Permissions drift quietly — a one-click restore can leave wp-config readable by every account on a shared server. Check once a quarter.
What makes a supply-chain compromise different from typical CVE disclosures?
Two different things. A typical CVE disclosure is a flaw an attacker finds in legitimate code and exploits before the vendor patches. A supply-chain compromise is malicious code shipped through the legitimate vendor’s own update channel.
Patchstack’s 2025 State report covers the Bricks Builder case, where mass exploitation began within hours. Roughly 33% of disclosed WordPress vulnerabilities never get patched in time.
Are AI-coded extensions a hidden vulnerability?
Yes, sometimes. AI coding tools generate WordPress plugin code that often misses the language’s security idioms — capability checks, nonce verification, output escaping. Patchstack’s 2025 mid-year report found 89% of new vulnerabilities landed in plugins.
AI-generated plugins inherit that surface and add their own gaps. WordPress.org’s plugin directory does not currently flag AI-generated submissions. Vet a new vendor the way you vet a contractor — look for a track record.
Which security step should you do first?
Two-factor authentication on the administrator account. The single move that breaks the largest share of real-world attack patterns — credential reuse, brute-force, session hijack — in fifteen minutes.
Then back up the site, off-site, with a tested restore. The recovery layer in case anything else goes wrong.
Then audit the plugin list. Deactivate what you do not use. Remove what is abandoned.
The order matters because two-factor on day one prevents a compromise during the rest of the cleanup. If the auth gate is closed, the time you spend on the plugin audit is time spent without an active threat.
Patchstack’s 2025 State of WordPress Security report names the disconfirming voice clearly. Relying on updates and security plugins alone is not enough. Compromised sites routinely have their security plugins disabled, bypassed, or removed by the malware that broke in.
Roughly a third of disclosed vulnerabilities are not fixed in time for public disclosure. The Bricks Builder remote-code-execution case in 2024 saw mass exploitation within hours of disclosure. The time from CVE to attack is sometimes shorter than the time from CVE to patch.
The auth gate is the part most often skipped. It is also the part that holds when the rest fails. Start there.
Want a calm second opinion on which plugins to drop, or whether your wp-config has the right constants set? You can contact me here. Send me your plugin list and the relevant lines of wp-config with secrets stripped. I will tell you which plugin to remove first and which constant to add. There is no pitch, no upsell, and the conversation is free.