Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Most WordPress vulnerabilities live in plugins. Learn how to vet, update, monitor and remove them, plus WordPress.org's new automated review.
Plugins are where most WordPress vulnerabilities live. A plugin sits in wp-content doing its job for months, until the version on your site turns out to have a hole in it.
We've seen how that plays out. On one client site we found a backdoor plugin that hid itself from the Plugins screen, along with orphaned administrator accounts in the database dating back to March 2025. That access sat unnoticed for over a year.
This guide is the watching part. It covers how to vet a plugin before you install it, why updating alone still leaves a gap, how WordPress.org now screens releases before they ship, and what to do the day a vulnerability lands in something you already run.
Patchstack tracked 11,334 new WordPress vulnerabilities in 2025, up 42% on the year before. Plugins accounted for 91% of them. WordPress core accounted for a handful.
The reason isn't complicated. Every plugin is code written outside the core team, released on its own schedule and maintained at its own pace. Some come from teams with a real security process. Plenty are one person's side project, updated in bursts, or not at all once the developer moves on.
Multiply that by every plugin on a typical site and you get a large, uneven attack surface. Core gets a whole team's attention. Each plugin gets whatever its author has time for that week.
Before you install anything, run it through five checks. None of them takes long.
Start with where it comes from. A plugin listed on WordPress.org sits inside a system that can pull it fast if something goes wrong. A zip file from a marketplace you've never heard of hasn't been through anything.
Look at when it was last updated. Past 90 days isn't an automatic no, because plenty of simple plugins go quiet when they don't need to change. It is a question worth asking.
Compare install count against rating trend, not just the star average. A 4.8 from twelve reviews tells you less than a 4.2 from eight thousand.
Then check the plugin's vulnerability history on WPScan before you install it, not after something breaks. Finally, see how the developer answers support threads. A maintainer who replies is usually one who'll ship a patch when it's needed.
That's five minutes, spent before the plugin becomes part of your site.
Updating matters. It's just not the whole job, and treating it as the whole job is how sites still get hit.
Patchstack's 2026 report found that 46% of disclosed vulnerabilities had no developer patch when they went public. Among the most heavily exploited flaws, the median time to mass exploitation was about five hours. Few site owners watch for a window that short.
Updating alone is not sufficient, because it only helps once a fix exists and you've installed it. Some threats never arrive through an update at all. On the client site above, the backdoor plugin removed itself from the Plugins list, so there was no update button to press. Our guide to supply chain attacks covers the opposite case, where the update itself is the attack.
WordPress.org changed something important in 2026, and it helps to know exactly what it covers.
Since 5 June 2026, every plugin and theme release goes through a cooldown before it reaches the update API, the system behind one-click updates in your dashboard. The cooldown is currently six hours, down from 24 when it launched. During that window, several AI models and Jetpack Scan analyze the release and combine their findings into a risk score. Releases that score high are blocked automatically, before any site receives them.
It has already caught something real. On 28 July 2026, a backdoor was committed to a release of a plugin with about 20,000 active installs. The review flagged it with a high score, and because the release was still inside the cooldown, the compromised version never reached the update API. The plugin was closed for downloads 26 minutes after Wordfence alerted the Plugins Team.
Three limits are worth knowing. The review covers new releases going forward, so a vulnerable version you installed before 5 June isn't touched. A score below the threshold means a release wasn't flagged, not that it's certified safe, and WordPress itself says the review can produce false positives. And it only covers WordPress.org, so it does nothing for a premium plugin from another source or a nulled copy off a forum.
Treat it as one more layer, not a replacement for the rest of this guide.
Nulled plugins aren't a discount version of the real thing. They're the real thing with someone else's code added, often a backdoor that opens the moment you activate it.
We've written the full breakdown, including what to do if you're already running one, in our guide to nulled themes and plugins. The short version is enough here. If it didn't come from WordPress.org or the developer directly, treat it as compromised, not just risky.
Vetting at install time isn't the end of it. The plugins already on your site need the same attention on a schedule, not only when something breaks.
Start with what's active. A deactivated plugin still sits on your server as files, and files are still code an attacker can reach. Delete what you don't use instead of switching it off.
Two settings are worth checking while you're there. Turn off the built-in file and plugin editor, which lets anyone with admin access rewrite plugin code from the dashboard. And block PHP execution inside wp-content/uploads, a folder meant for images and documents. Both are covered in our guide to hardening wp-config.php and .htaccess.
Not everyone who can log in should be able to install plugins, either. Our user roles guide shows who needs which role, and an activity log records every plugin install and activation, so one nobody remembers adding stands out.
A patch from the plugin developer isn't the only way to close a hole. Virtual patching blocks the specific request an exploit would use at the firewall, before it reaches the vulnerable code. The plugin itself doesn't change. The attack just can't land.
We've watched this work on a client site where we run a security plugin. On the day we checked, WordPress core was a version behind and six plugins had updates waiting. The vulnerability shield still reported zero active vulnerabilities and zero patches applied. Outdated and vulnerable are different questions, and knowing which one you're dealing with decides whether Tuesday morning goes to updates or to something else. If one of those six had picked up a known flaw, virtual patching would have covered it while we waited for the fix.
Timing matters. On the free tier of that tool, virtual patching only applies about a week after a vulnerability goes public. On the paid plan we run, it applies immediately. When mass exploitation can start within hours, a week of exposure is a long time.
Sooner or later a plugin you run gets a disclosed vulnerability. What you do next depends on which of four situations you're in.
If a patch exists, update now and confirm the new version actually installed. Don't assume the update ran because you clicked the button.
If there's no patch and the severity is low, watch it. Turn on virtual patching if your firewall offers it, and check back when the developer ships a fix.
If there's no patch and the severity is high or critical, don't wait for your usual maintenance window. Deactivate the plugin now, and delete it if you can live without it, since some flaws can still be reached through the files of a switched-off plugin. A broken feature is recoverable. A compromised site is a different kind of problem.
If the plugin is abandoned, with no updates in years and a developer who's gone quiet, stop waiting for a fix. Replace it.
Some update tools now score each update for risk. Use that as input, but the call is still yours.
None of this works alone. Vetting before install, updating, WordPress.org's new review layer and virtual patching are four layers, and skipping one leaves a gap the others don't cover.
If auditing every plugin on your site is more than you have time for, message us and we'll go through what's installed, what's current and what's quietly waiting to become a problem. If something already looks wrong, our WordPress malware removal service is where to start.
Most are. The risk sits in specific plugins, ones that haven't been updated in years, have a history of unpatched flaws, or came from somewhere other than WordPress.org. A well-maintained plugin from a reputable developer isn't a bigger risk than any other code on your site.
Search it on WPScan before and after you install it. The changelog often mentions security fixes too. For releases published since June 2026, WordPress.org's automated review adds another check, though it isn't a guarantee.
No. Updates only help once a fix exists, and 46% of disclosed vulnerabilities had no developer patch when they went public. Auto-updates are still worth turning on, but pair them with monitoring and virtual patching.
A firewall rule that blocks the request pattern a known exploit uses, applied before the developer ships a code fix. It doesn't change the plugin. It buys you time until a real patch exists.
SEO & Security Expert, AppDeel
Azizul Hakim is an SEO and website security specialist at AppDeel, the agency he founded and where he still handles client work himself. For more than ten years he has helped business owners and eCommerce brands get found in search and keep their websites secure.
Read more posts by Md Azizul Hakim →What each WordPress user role can do, who should get which one, where Editor and Contributor carry hidden risk, and a 20-minute user audit.
Does changing the wp_ database prefix stop SQL injection? See what the evidence says, what can break, and when it's still worth doing.
SFTP vs FTP for WordPress: plain FTP sends your password as readable text. See what SFTP fixes, what it doesn't, and how to switch safely.
The exact WordPress file permissions to use: 644 for files, 755 for folders, and what to do differently for wp-config.php. No guesswork, no 777.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
