The Federal Patch Deadline Is Now Three Days. When Was Your Website Last Updated?

Most vulnerabilities never matter. The ones that do are used almost immediately

CISA puts the share of published vulnerabilities ever exploited at under four percent, and reports that half of those are in use within two days of disclosure. Security for a small site is therefore a speed problem rather than a strength problem, and speed is measurable.

Two figures from CISA belong side by side, because either one alone is misleading. The first: less than four percent of the total number of published vulnerabilities have been publicly exploited³. Anybody who has ever been handed a scanner report running to several pages should find that reassuring, and it is the honest counterweight to an industry that sells by volume of findings.

The second figure removes the comfort. Of that small exploited share, CISA reports 42 percent in use on day zero of disclosure, 50 percent within two days, and 75 percent within 28 days³. The distribution is front-loaded to a degree most owners would not guess. There is no quiet period between a vulnerability becoming public and somebody trying it, because publication is itself the starting gun.

Put together, they describe something quite specific. A monthly maintenance visit, which is what a great many small businesses buy, is structurally too slow for the events that actually cause harm, while being far more attention than the ninety-six percent of findings that will never matter. The schedule is wrong in both directions at once. That is a design problem, not a diligence problem, and it is fixable.

It also explains why obscurity offers nothing. We covered the mechanism separately in what Google does when a site is hacked, where Google attributes compromise to vulnerabilities in a site’s security rather than to any decision about the business behind it. Scanning at internet scale does not pause to consider whether a Naples business is worth the trouble.

The federal deadline moved from three weeks to three days

CISA issued BOD 26-04 on 10 June 2026, superseding the directive that created the vulnerability catalog. We counted the public catalog file ourselves: of 67 entries added since June, 54 carry a three-day remediation deadline, against a historic norm of 21 days.

The current directive is BOD 26-04, Prioritizing Security Updates Based on Risk, issued on 10 June 2026, which supersedes and revokes both BOD 22-01 and BOD 19-02¹. Rather than treating every vulnerability alike it sorts them by four questions: whether the asset is publicly exposed, whether the vulnerability is in the known-exploited catalog, whether an attacker can automate the attack, and how much control exploitation gives them¹.

For the worst combination, the directive requires the agency to complete remediation or mitigation "within the timeline (three days)" and to carry out a forensic triage of the asset to assess whether the system is already compromised¹. The reasoning CISA gives is worth quoting directly, because it is unusually candid about why the window closed: threat actors exploit unpatched vulnerabilities, and "their use of AI may further narrow the time defenders have to react between patch release and possible exploitation"¹.

We wanted to know whether that was a policy document or an actual change in behavior, so we checked. CISA publishes the catalog as a downloadable file, describing it as the authoritative source of vulnerabilities that have been exploited in the wild². We downloaded it on 22 August 2026, at catalog version 2026.08.21, and counted the gap between the date each entry was added and the date its fix was due. The table below is that count. It is reproducible by anyone with the same public file.

The shift is unambiguous. Across the full catalog of 1,674 entries the historic norm is 21 days. Among the 67 entries added since 1 June 2026, 54 carry a deadline of three days. One important caveat belongs here in plain language: this directive binds federal agencies, not your business. Nobody is going to fine a Naples contractor for a slow update. It is a benchmark of what the people who do this professionally now consider urgent, and it is the most credible one available.

Counted from the CISA catalog JSON feed, version 2026.08.21, downloaded 22 August 2026. Total 1,674 entries, of which 273 were added in the preceding twelve months and 352 are flagged as having known ransomware campaign use. Our arithmetic, CISA’s data.

This already happened to WordPress, last month

On 21 July 2026 CISA added two WordPress Core vulnerabilities to the catalog which, chained together, allow an unauthenticated attacker to reach remote code execution on default installations. One carried a three-day deadline. The fix had already shipped in WordPress 7.0.2, so the only variable left on any given site was whether anybody applied it.

None of the above is abstract if your site runs WordPress. On 21 July 2026, CISA added CVE-2026-60137 and CVE-2026-63030 to the catalog, both against WordPress Core. The catalog entry states that the first can be chained with the second "to allow an unauthenticated attacker to gain remote code execution on default WordPress installations"².

Read the phrase "default installations" carefully. Not misconfigured sites, not sites running unusual components, not sites belonging to anyone in particular. The remediation deadline on CVE-2026-63030 was 24 July, three days after it was added². That is the tightest window CISA issues, applied to the software a very large share of small businesses in Southwest Florida happen to be running.

The fix already existed. WordPress had shipped 7.0.2, described in its own announcement as a security release addressing "one critical and one high severity security issue"⁵. So the vulnerability was public, the patch was public, and the only remaining variable on any given site was whether anybody applied it. That is the entire subject of this article compressed into one month of real events.

And here is the sentence from that announcement that decides the outcome: "On sites that support automatic background updates, the update process will begin automatically"⁵. Two sites running identical software, one with background updates functioning and one without, were in completely different positions within hours, and neither owner did anything to cause that difference.

What WordPress updates on its own, and the gap most owners do not know about

Since version 5.6, new WordPress installations automatically apply both minor and major core releases. Plugins and themes are different: WordPress documentation states they update automatically only in special cases determined by its security team. Everything else is opt-in, per plugin.

The core side is genuinely well handled. WordPress documentation states that before version 5.6 every site had automatic updates enabled for minor core releases and translation files by default, and that starting with 5.6, new installations have automatic updates enabled for both minor and major core releases by default⁴. If your site is reasonably modern and nobody has interfered with it, core security releases are probably arriving on their own.

Plugins are where the assumption breaks. The documentation is explicit: "By default, automatic background updates only happen for plugins and themes in special cases, as determined by the WordPress.org API response, which is controlled by the WordPress security team for patching critical vulnerabilities"⁴. That is a narrow emergency mechanism operated by somebody else, not a general policy of keeping your plugins current.

The gap matters because plugins are where the surface area lives. A typical small business site runs a contact form, a page builder, a booking or quote tool, an analytics connector and a handful of others, each written by a different party on a different release schedule, some by maintainers who have moved on. WordPress offers per-plugin automatic updates, and on most sites we look at, they have simply never been switched on.

There is a second-order point here that has nothing to do with security. Old plugins accumulate, and the ones you no longer use still load, still execute and still slow the site down, which we covered in how page speed relates to rankings. Removing components you stopped using some years ago improves two problems at once and costs nothing.

1. Find out what is actually updating. Open the plugins screen and look at the auto-update column. On most sites nothing there is switched on.
2. Confirm core background updates still work. They are on by default, but a host, a plugin or an old configuration line can disable them silently.
3. Delete what you no longer use. An inactive plugin is still installed code. Fewer components means fewer things to keep current.
4. Switch on automatic updates for what remains. Per plugin, deliberately, with the riskier ones handled through a staging step instead.
5. Get a rollback path before you need one. Daily backups you have actually restored once. An untested backup is a hope, not a plan.
6. Watch the site after updates land. Something checking that pages still return correctly, so a broken update is caught in minutes rather than by a customer.

The honest tradeoff, which is that updates sometimes break things

Owners disable automatic updates for a real reason: an update can break a working site, and often nobody notices for days. The answer is not to leave updates off, it is to make breakage cheap to detect and quick to reverse.

Every article on this subject tells you to turn on automatic updates and stops there, which is why so many owners have turned them off again. The concern is legitimate. A plugin update can conflict with a theme, a page builder update can rearrange a layout, and a payment or booking integration can stop working in a way that produces no error message at all, only a quiet absence of inquiries.

Weigh the two failure modes properly rather than pretending one does not exist. A broken update is visible, reversible and usually fixed within the hour once somebody knows. An unpatched vulnerability on a site running software that has been in the known-exploited catalog with a three-day deadline¹ is invisible, and the recovery involves Google’s security review process, which Google says can take several days or weeks⁶.

So the answer is not to choose between them. It is to make breakage cheap: a backup you have restored at least once so you know it works, a staging copy for the updates most likely to cause trouble, and monitoring that tells you a page stopped rendering before a customer does. With those three things in place the argument for delaying an update disappears, because the downside is an hour of somebody’s time rather than a fortnight of lost business.

That is also, in plain terms, what our website care work consists of, and it is worth being precise about what we are claiming. We are not claiming your site cannot be compromised. Nobody can claim that, and a vendor who does is describing a guarantee this field cannot support. What we are claiming is a shorter gap between a fix being published and applied, fewer installed components to keep current, and somebody watching so that a problem is found by us rather than by one of your customers. The same principle applies one layer down, to who actually holds your domain registration, since a site that is perfectly patched still disappears if the registration lapses. If you want to see the current state of a site first, that is what our free SEO audit covers.

• Speed of patching is the variable you control. Strength of defenses mostly is not.
• Half of the vulnerabilities that get exploited are in use within two days of disclosure.
• WordPress core updates itself by default. Your plugins almost certainly do not.
• An automatic update without a tested rollback is a risk you have moved, not removed.
• Treat any promise that a site cannot be compromised as a reason to ask harder questions.

If you would rather this was somebody else’s job, that is what our technical SEO services and website care cover. We will also tell you when the honest answer is that your setup is already fine, which happens more often than the security industry suggests.