If a plugin on your website has just been named in a critical security advisory, the answer fits in four lines. Check whether you run the affected version. If a fixed version exists, install it today, not on maintenance day. If no fix exists yet, switch the plugin off or block the specific attack until one does. Then check whether anyone got in before you closed the door, because an update stops the next attacker and does nothing about the last one.
The rest of this article is the detail behind each of those lines, using a case from this month as the example.
What happened this month
On the evening of 7 October, the WordPress security firm Patchstack began seeing automated attacks against Bricksforge, an add-on for the Bricks site builder that Patchstack estimates runs on about 6,000 websites. The flaw, tracked as CVE-2026-85097, let anyone upload a file through one of the plugin’s forms without logging in, and then run it. On a web server, that means taking over the site.
By the time it was reported publicly on 12 October, the attempts had come from 63 different internet addresses, many of them sending identical requests seconds apart. That is what automated scanning looks like. Versions up to 3.1.8.9 are affected, and 3.1.8.10 fixes it.
Nobody running Bricksforge needed to be singled out. The scanners do not know or care whose site it is. They find the plugin and try the door.
First, find out whether it is your problem
Many site owners hear about advisories late or not at all. A plugin does not normally email the people who use it when a flaw is published, and the WordPress dashboard tells you that an update is available, not that it is urgent. Advisories come from security firms such as Wordfence and Patchstack, and from the plugin developer’s own changelog.
When you do hear, three questions settle whether it applies to you:
- Is the plugin installed at all, active or not? A deactivated plugin still has its files on the server, and some flaws can be reached through those files directly. Anything you do not use should be deleted, not just switched off.
- Which version are you running? The plugins screen lists it. Compare it with the affected range in the advisory.
- Do you use the vulnerable feature? This tells you how much damage was possible. It does not change whether you act.
If a fix exists, install it today
Last year’s numbers explain the urgency. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 91% of them in plugins. For the flaws attackers went after hardest, the weighted median time from disclosure to the first exploit was five hours.
A routine that applies updates once a week or once a month was designed for a slower web. Against a flaw that is being scanned for tonight, it is a schedule for being compromised.
Update that one plugin first, on its own, rather than waiting to batch it with everything else. If you are worried the update will break something, take a backup before you start. A broken layout is a problem you can fix in the morning. A hijacked server is not.
If no fix exists yet, you still have choices
This happens more often than people expect. Patchstack found that 46% of the vulnerabilities disclosed in 2025 had no patch by the time they were made public. Waiting for the developer is a decision too, and it is often the worst one available.
There are three better options, in order of preference:
- Switch the plugin off and remove it, if the site can live without it for a while. A missing feature for a week costs far less than a cleanup.
- Replace it with a maintained plugin that does the same job.
- Block the specific attack at a firewall that understands WordPress. This is sometimes called a virtual patch: a rule that stops the malicious request before it reaches the vulnerable code. It buys time. It does not fix the plugin.
On that last option, do not assume your hosting company’s firewall already covers you. When Patchstack tested the standard defences used by hosting providers against attacks on known WordPress vulnerabilities, they blocked 12% of the attacks in one test and 26% in a broader one. Even the best-performing host stopped only about 61%. Patchstack sells exactly this kind of protection, which is worth keeping in mind, but the reason is easy to see. A general-purpose firewall is built to stop general-purpose attacks, and an attack on one plugin’s upload form looks to it like an ordinary form being filled in.
Updating does not undo what already happened
This is the step most often skipped. An update closes the hole. It does not remove anything an attacker put through the hole before you closed it, and a successful upload attack usually leaves behind a file that lets them back in by another route. The researchers analyzing Bricksforge said so directly: updating does not remove files that have already been planted.
So once the update is in, look for:
- Code where it should not be. PHP files inside the uploads folder are the clearest sign. That folder should hold images and documents, never code. In the Bricksforge attacks, the planted files sat in the plugin’s temporary upload folder.
- Administrator accounts that nobody on your team recognizes.
- Scheduled tasks, new plugins or modified core files that nobody added.
- Requests to the vulnerable feature in the server’s access log from before you updated.
If you find any of these, stop and treat the site as compromised. Preserve a full copy of the files, the database and the logs before deleting anything, because that copy is the record of how they got in. Delete first and you will have a clean site and no idea whether the same thing will happen next month.
Who is supposed to be doing this?
Read back through the steps and the job description writes itself. Someone has to know which plugins and which versions your site runs. They have to watch the advisories for those plugins every day, have the authority to update or switch off a plugin the same day without waiting for a meeting, and be able to read a server log afterwards.
On most company websites, that person does not exist. The developer who built the site has moved on. The marketing team can change a page but not a server. The hosting company considers the plugins your business.
If that describes your site, the gap is a bigger risk than any single plugin.
What we tell people who ask us
At TAPQUAD, this is the work behind our web management plans. Plugins are patched continuously rather than on a calendar, monitoring and malware scanning run all the time, and if something does get through, we investigate it and put in writing how it happened. Every managed site carries the same guarantee: if it is compromised or goes down, we fix it at no extra cost.
If your site is not on a plan and you are looking at an advisory right now, we will inspect it at no charge and tell you what we find before quoting anything.
Sources: Patchstack, State of WordPress Security in 2026, including its tests of hosting defences; reporting on CVE-2026-85097 by SecurityWeek, The Hacker News and SOCRadar, published 12 October 2026, citing Patchstack telemetry; read October 2026.