Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

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.

Describe my issue Send a message

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.

  • 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

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.

Related reading

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

symptomes
depuis-quand
sauvegarde
acces-admin (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.

Related pages