Five hours: how fast a plugin bug becomes an attack

The bugs attackers want most are now exploited at scale within hours of being made public. What that looked like on WordPress and Shopify this year, and a care routine that keeps up.

Website care3 November 2026Updated 5 November 20264 min readBy Team Krikir

An hourglass and a shield, for how fast a plugin bug becomes an attack

In short

For the WordPress bugs attackers went after hardest in 2025, mass attacks started a median five hours after disclosure.
Shopify stores were hit too: in October three apps served code that sent shoppers to a fake payment page.
A weekly update round is too slow on its own. Automatic security updates, fewer plugins and a firewall close the gap.

Every year Patchstack, a security company that tracks WordPress plugins, publishes a report on the year before. The one released on 25 February had one number in it that every site owner should know. In short, a plugin bug that attackers want now gets used against real sites within hours.

5 hoursWeighted median time from a vulnerability being made public to mass attacks, for the WordPress bugs attackers exploited most in 2025 (Patchstack).

The rest of the report adds to it. It counts 11,334 new security holes in WordPress plugins and themes during 2025, a 42% jump on 2024. 91% were in plugins. 46% had no fix available on the day they were made public. And paid plugins and themes had three times as many actively exploited bugs as free ones.

How a plugin bug played out this year

Elementor Pro, August. A flaw rated 9.8 out of 10 let anyone upload a file to a site without logging in, through an Elementor form with an optional file upload field. Elementor Pro runs on millions of sites. The fix came in version 4.2.2. Sites that updated the same day closed the hole. Sites on a monthly update round had a long, open window.

WordPress itself, 28 October. Version 7.1.4 fixed a bug that could let an attacker run code during an update. Wordfence saw more than 18,500 probing requests in the first 21 hours. Most sites updated themselves automatically, because WordPress installs minor releases by default. The ones that did not were usually sites where somebody had switched automatic updates off years ago.

Shopify stores are not exempt

Shopify looks after its own platform, and its checkout was not breached. But every app you install can add code to your storefront, and that code runs with your store’s name on it.

Between 10 and 17 October, a security firm called cside found that three apps (Hulk Product Options, Swym Wishlist Plus and Selleasy) were serving injected code through their own configuration servers. When a shopper clicked Checkout, the code sent them to a fake payment page, took their card details, and then forwarded them to the real checkout. The order went through as normal, so the store owner saw nothing wrong. The same report links earlier incidents to apps from Qikify in July and Hextom in August.

The lesson for store owners is uncomfortable: the apps you trust are part of your security, and you rarely see what they load.

Why a weekly update round is no longer enough

Most small businesses that keep their site updated at all do it in a batch: once a week, once a month, or when someone remembers. That worked when attacks took weeks to arrive. Against a five-hour window it leaves most of the week open.

The answer is to split updates into two kinds:

Security fixes go in automatically, as soon as they are released, for WordPress core and for plugins from vendors with a good record.
Feature updates wait for a test, on a staging copy, at a quiet time.

Then add a firewall that blocks known attacks before your plugins are even patched. Patchstack, Wordfence and some hosts do this; the term to look for is “virtual patching”. It covers the window between a bug being published and your update running.

A care routine that matches the speed

Here is the routine we recommend. You can run it yourself, or check that whoever looks after your site already does.

Every day, automatically: security updates for core and plugins, an off-site backup, uptime checks every few minutes, and a firewall with virtual patching.

Every week: read the update log, test and apply feature updates on staging, and place a test order or send a test form to make sure the money and the leads still arrive.

Every month: delete plugins and apps you do not use, check the PHP version (8.2 loses support on 31 December), review who has admin access, and restore one backup to prove it works.

On Shopify: list every app and what it adds to the storefront, remove the ones you no longer use, and ask vendors how they load their scripts. Shopify is moving apps to theme app extensions and stops old-style script tags on storefronts on 1 March 2027, which will help. Until then, a weekly test checkout is the cheapest early warning you have. If the payment page ever looks different or the address bar shows a domain that is not yours or Shopify’s, stop and investigate.

The cost of not doing it

A hacked site rarely announces itself. More often it shows up as a Google warning, a drop in sales, a card company asking questions, or customers reporting fraud weeks later. Cleaning up costs far more than prevention, in money and in trust.

None of the routine above is clever. It just has to happen every week, and in most small businesses nobody owns it.

Our website care service runs this routine for you. When a flaw has no fix yet, we block the route in, or switch off or replace the plugin, with your approval. For the dates to plan around, read WordPress 7.2 and PHP 8.2.