# A flaw has just been published: how long do I have

> The question isn’t rhetorical, and the measured answer is shorter than most merchants assume. Here are the delays actually observed between a flaw being published and the first mass attacks.

- Source canonique : [https://allaux.fr/en/securite/combien-de-temps-pour-appliquer-un-correctif](https://allaux.fr/en/securite/combien-de-temps-pour-appliquer-un-correctif)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Read the advisory for two things only: is the flaw exploitable without authentication, and is your version inside the affected range. If both answers are yes, apply the fix straight away rather than at the next maintenance window, after backing up files and database. If an account is required, the update can join your normal cycle.

## There isn’t one deadline, there are several

The question nearly always reaches me in the same words: a flaw has just been published in an extension I use, can it wait until Monday. It’s a fair question. Updating on a Friday evening, on a shop that’s taking orders, means accepting the risk of breaking something at the worst moment of the week, with nobody around to fix it before Monday. The trouble is that the timetable isn’t yours.

What makes the decision hard isn’t only that the window is short. It’s that it can’t be known in advance. Two flaws published in the same week, carrying identical severity scores, can produce automated attacks within hours in one case and no observed exploitation for nearly a month in the other. You only find out which was which afterwards, and if you bet wrong, your customers will tell you.

| Valeur | Description |
|---|---|
| 5 hours | median time between public disclosure of a flaw and the first mass attacks |
| 1 in 2 | roughly half of high-impact vulnerabilities are exploited within 24 hours of disclosure |
| 46% | of vulnerabilities had no patch available at the time they were publicly disclosed |

Source : Patchstack, State of WordPress Security in 2026 (2025 figures)

## Four real timelines, four different answers

Hours. On 17 July 2026 WordPress shipped emergency releases 7.0.2, 6.9.5 and 6.8.6 to fix two flaws that, chained together, allow unauthenticated remote code execution. Public proof-of-concept code appeared within hours of disclosure, and real-world exploitation was confirmed by several teams in the days that followed. Waiting for the weekend was not an option here, and WordPress.org forced automatic updates on the affected branches.

Days. An authentication bypass in the Burst Statistics extension, CVE-2026-8181, scored 9.8, was found on 8 May 2026 and patched four days later, on 12 May 2026, in version 3.4.2. More than 7,400 attacks were blocked in twenty-four hours. The fix existed; it still had to be applied.

Almost a month. Everest Forms Pro, CVE-2026-3300, also scored 9.8, was patched on 18 March 2026. Active exploitation was only observed from 13 April 2026. A merchant who updated three weeks late would have got away with it. Nothing guaranteed that at the moment of deciding.

Weeks, then a spike. Gravity SMTP, CVE-2026-4020, was patched on 17 March 2026 in version 2.1.5. Mass exploitation only started in early May 2026, peaking on 6 and 7 June 2026. Nearly three months between the fix and the peak: a shop still unpatched from March was a perfectly valid target in June.

Two of these four flaws carry exactly the same severity score and had nothing like the same timeline. That is precisely why a score alone can’t make the decision for you.

## The paradox: the patch is what triggers the attack

This is the part merchants find hardest to accept, and I understand why: intuitively, a published fix should be good news. It is — for the sites that install it. For everyone else it does the opposite.

A new release is a public event. The corrected code can be compared with the previous code, the difference is visible, and that difference shows where the defect was and what had to be filtered. From that moment the flaw stops being a hypothesis and becomes verifiable information that can be applied in bulk to every installation that hasn’t moved yet. That’s why the most dangerous window isn’t before the patch, but immediately after it.

The direct consequence: the day your dashboard shows “update available”, you aren’t at the start of a comfortable grace period, you’re already in the race. And the reverse case matters too — 46% of vulnerabilities have no patch at all when they are made public. There, updating isn’t even an option, and temporary mitigation is your only room to manoeuvre.

## What moves a flaw from “next maintenance window” to “tonight”

1. **It works without authentication** — The heaviest criterion by far. As long as an account is needed, even a customer account, the attack has to be prepared. If none is, it can be automated across the whole web at no extra cost, and your shop will be hit by a general sweep rather than by someone targeting you.
2. **The extension is widely installed** — The bigger the install base, the more worthwhile automation becomes for an attacker. An extension running on tens of thousands of sites justifies building a tool; a module on three hundred shops, far less. It isn’t a guarantee, it’s a probability.
3. **The patch is already public** — Once the fixed version exists, the code difference can be read, and the clock started when it was published, not when you read about it. A flaw announced with no patch available is, paradoxically, less urgent to update — there is nothing to install. It is urgent to mitigate.
4. **No mitigation is available** — If you can disable the affected feature, remove the module when it isn’t used, restrict access to the entry point or block a route at the firewall, you buy time and can update calmly midweek. If none of that is possible without breaking a selling function, updating is all that’s left, and it’s for tonight.

## Without an inventory, none of this is usable

> Everything above assumes two things many shops don’t have. First, an accurate, current list of what actually runs on the site: extensions, themes, installed versions, including anything added once for a test and never removed. Without that list, you can’t even tell whether the advisory you just read concerns you. Second, a way to update without breaking the shop: a restorable, tested backup, a staging environment, an agreed maintenance window. Without those, the real reason an update waits for the weekend isn’t caution — it’s the fear of breaking something you wouldn’t know how to repair. That fear is fixable.

## Related reading

- **Tracking flaws that affect your store** — How to hear about a disclosure on the day, rather than three weeks later. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Emergency security update** — What I actually do when the answer to this page’s question is “tonight”. ([/wordpress-woocommerce/mise-a-jour/urgence-securite](/wordpress-woocommerce/mise-a-jour/urgence-securite))
- **Backing up before any intervention** — The prerequisite that turns a risky update into a reversible operation. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **Abandoned modules and extensions** — The case where no patch is ever coming, whatever deadline you set yourself. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))

## FAQ

### Is a high-severity flaw always exploited first?

No. The score measures potential impact, not how attractive the flaw is to automate. Two flaws on this page share the same 9.8 score: one saw active exploitation about a month after its patch, the other produced more than 7,400 blocked attacks in twenty-four hours. Install base and the absence of authentication usually weigh more than the score.

### So can it wait until the weekend?

If the flaw works without authentication, on a widely installed extension, with a patch already public and no mitigation available: no. If one of those four points drops away you have some slack, but measure it in days rather than weeks. The median time to mass exploitation is five hours.

### What do I do if there is no patch yet?

That applies to nearly half of vulnerabilities at disclosure. Reduce exposure instead: disable or remove the component if it isn’t essential, restrict access to the affected feature, block the targeted entry point at the application firewall, and watch the logs. These measures are temporary and should be lifted once the fix is applied.

### Do automatic updates settle the question?

Only partly. They cover what comes through the official update channel, and the publisher can force them in an emergency, as was done for the WordPress releases of 17 July 2026. They don’t cover components installed by hand, or those whose publisher distributes the builds itself. Those are the ones to track manually.

### How do I know whether I was hit before I updated?

Updating cleans nothing: if exploitation happened first, the access obtained stays in place. After a late update on a critical flaw I review administrator accounts, recently modified files, unusual scheduled tasks and the access logs for the period concerned.