Patch Tuesday comes once a month. According to Rapid7, the attackers now show up in three days.

In its Q3 2026 Quarterly Threat Landscape Report, Rapid7 found an average of three days between a high-severity vulnerability going public and its exploitation. And 71% of the exploitation it tracked happened within the first seven days. Rapid7 doesn’t soften the takeaway: “If your patch cycle still has the word ‘monthly’ in it, congratulations: It’s perfectly calibrated for an adversary who stopped existing a while ago.”

That’s a sharp line from a vendor, but last week gave us a live example. And the fix isn’t “patch everything faster.” It’s knowing which handful of flaws can’t wait, and having a process ready before they arrive.

What Rapid7 found

The headline numbers, from Rapid7’s report and its summary post:

• Three days on average from public disclosure to exploitation, for vulnerabilities rated 7 to 10 on the CVSS scale.

• 71% of tracked exploitation within 7 days, 80% within 14 days, and 90% within 30 days.

• 43 newly exploited high- and critical-severity vulnerabilities in the quarter, down 7% from Q2 but 19% higher than a year earlier.

• 34 of those 43 (79%) could be exploited remotely, with no login and no user interaction. Rapid7 calls these “holy grail” vulnerabilities.

A note on scope before going further. These numbers describe the vulnerabilities Rapid7 tracked as exploited. Its press release says the report draws on the company’s managed detection and response operations, vulnerability intelligence platforms, and threat research telemetry. That’s one company’s view of 43 flaws, not a measurement of every vulnerability disclosed this year. It’s a strong signal about how fast attackers move once they pick a target. It isn’t proof that every high-severity bug gets exploited in three days.

In fact, the same report shows the opposite for most flaws. Of 2,082 high-severity remote code execution vulnerabilities in Rapid7’s data, 18 were exploited, a rate of less than 1%. Most high-severity bugs never get used in an attack. The ones that do get used fast.

That’s the whole problem in two sentences. You can’t treat every critical CVE as an emergency, and you can’t wait a month on the few that are.

Last week showed what three days looks like

The PHP flaws from last week’s threat alert are a clear example of how quickly the window closes.

• Oct. 17: AWS saw attempts to exploit the flaws four days before they were publicly disclosed, according to The Register.

• Oct. 21: The PHP project shipped fixes in 8.5.12, 8.4.27, 8.3.36, and 8.2.35 after details leaked ahead of coordinated disclosure, according to Huntress.

• Oct. 24: A researcher recorded 35 successful shell executions across three honeypots running a vulnerable PHP build, per The Register. The researcher cautioned that the honeypots used a favorable setup, so the results don’t show how reliably the exploit works against production servers.

• Oct. 26: CISA added both flaws, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities catalog, the government’s list of flaws with evidence of real attacks.

• Oct. 29: The deadline CISA set for federal civilian agencies to act, according to NVD’s record of the KEV entry. That’s three days after the listing.

For the PHP flaws, the window didn’t just shrink. Attack attempts started before the patch existed. A client on a monthly cycle that ran on Oct. 14 wouldn’t have seen this fix until mid-November.

Why the government landed on three days, too

Rapid7 isn’t the only one counting in days. In June, CISA issued Binding Operational Directive 26-04, which replaces flat patch deadlines for federal civilian agencies with deadlines based on risk. It sets urgency using four questions:

1. Is the vulnerable asset publicly exposed?

2. Is the flaw in CISA’s KEV catalog?

3. Can an attacker automate every step of the exploit?

4. Does a successful exploit give the attacker partial control or total control?

When the answers point to the worst case, the timeline is three days, plus “forensic triage” to check whether the system was already compromised before the patch went on. At the other end, low-risk flaws can wait for the next scheduled upgrade.

The directive applies to federal agencies, not to MSPs or their clients. But it’s a useful model, because it says out loud what Rapid7’s data suggests: a small set of flaws needs a three-day clock, and the rest can stay on a normal schedule. CISA itself encourages all organizations to adopt risk-based vulnerability management and prioritize KEV-listed flaws.

Build an emergency patching track

Most MSPs already have a good monthly process. Keep it. What’s missing is a second, faster track with clear rules for what gets on it.

1. Define the trigger in writing

The emergency track should be narrow on purpose. If everything is an emergency, nothing is. A practical trigger, borrowing from Rapid7’s findings and CISA’s four questions:

• The affected system faces the internet, and

• The flaw needs no login or user interaction, or

• The flaw is in the KEV catalog or the vendor confirms it’s being exploited.

A no-login flaw on an internet-facing firewall, VPN, web server, or remote access tool meets the bar. A local privilege escalation on an internal workstation usually doesn’t, and it goes in the monthly cycle.

2. Know what each client exposes before the alert lands

You can’t patch in three days if it takes two days to find out who’s affected. For each client, keep a current list of internet-facing systems and the software running on them: firewalls, VPNs, remote access gateways, web servers, mail servers, and any app with a public login page. Rapid7’s advice is to start by identifying externally accessible assets and the vulnerabilities affecting them.

The PHP flaws were a good test. PHP sits under WordPress sites, hosting control panels, custom apps, and software bundled inside vendor appliances. If you had to search for it client by client, that’s your gap.

3. Watch the right signals

Set up a feed, not a habit. Subscribe to CISA’s KEV catalog updates, vendor security advisories for the products in your stack, and your threat intelligence sources. Assign one person per shift to check new entries against the exposure list. The goal is an answer within hours: affected, not affected, or unknown.

4. Get emergency maintenance approved in advance

The slowest part of an emergency patch is often the approval, not the install. Agree with each client ahead of time that emergency-track fixes can go in outside normal change windows, with notice rather than permission. Name the client contact who gets that notice, and a backup.

5. Mitigate when you can’t patch yet

Sometimes there’s no patch, or the patch breaks something, or the system belongs to a vendor you can’t touch. Have a short list of fallback moves ready: take the service off the internet, restrict it to VPN access, apply a web application firewall rule, or turn off the vulnerable feature. Rapid7 recommends assessing compensating controls and detection coverage where immediate remediation isn’t possible. Document what you did and when you’ll come back to finish.

6. Check for compromise after you patch

When exploitation starts before the patch exists, patching closes the door but doesn’t tell you whether someone already walked through it. That’s why CISA’s directive pairs its fastest deadline with forensic triage. For emergency-track flaws, the job isn’t done until someone has looked for signs of compromise: new accounts, unexpected processes, new files in web directories, scheduled tasks, or outbound connections that shouldn’t be there.

7. Record the clock

Log three timestamps for every emergency-track item: when you learned about it, when you mitigated it, and when you fully fixed it. That’s the data you’ll need for the contract and the quarterly review.

Put the clock in the contract

If your client agreements say “timely patching” or “industry-standard patch management,” that language won’t help anyone when a three-day flaw hits. Clients, insurers, and auditors increasingly want a number.

Here’s a starting structure to adapt with your legal counsel. The point is to define tiers, clocks, and exceptions, so everyone knows what “fast” means before it matters.

The clauses that make the table work:

• When the clock starts. From when the vendor publishes a fix or workaround, or when you’re notified, whichever is later. You can’t patch a flaw that has no fix, so say what happens in that case: mitigation steps and regular updates.

• What counts as done. Patched, or mitigated with a documented compensating control and a date for the full fix.

• Pre-approved emergency maintenance. The client agrees that emergency-tier work can happen outside normal windows, with notice.

• Exceptions. Systems the client or a third party controls, unsupported software, and client-requested change freezes. Each exception gets a named owner and a review date.

• Reporting. What you’ll report, and how often.

The same pattern is showing up in federal work. CISA’s implementation guidance directs agencies to make sure remediation timelines are written into service-level agreements with service providers, according to Nextgov. Commercial clients may not be far behind.

One caution: don’t promise a clock you can’t keep across every client. Start with the emergency tier on the systems you fully manage, prove you can hit it, then widen the scope.

Show patch speed in the QBR

A three-day emergency track is a real service upgrade, and clients should see it working. For each client, bring a one-page patch speed summary to the quarterly business review:

• Emergency-tier events this quarter: how many, which flaws, and which systems were affected

• Time to mitigate and time to fix for each one, against the SLA target

• Percentage of high-tier items fixed within target

• Open exceptions, each with its owner, reason, and review date

• Exposure changes: internet-facing systems added or removed since last quarter

Use a real event to tell the story. For example: “PHP flaws were disclosed on Oct. 21. Attackers were already trying them. We found your two affected servers the same day, patched them by the next morning, and checked them for signs of compromise. CISA confirmed active exploitation five days later.” That’s more convincing than any patch compliance percentage.

It also turns patching from a background chore into a visible part of the security program, which is where it belongs. Attackers measure their window in days. Your reporting should, too.

Frequently asked questions

Q: How fast are attackers exploiting new vulnerabilities?

A: In Rapid7’s Q3 2026 data, the average was three days from public disclosure to exploitation for high-severity flaws, with 71% of tracked exploitation happening within the first week, according to Rapid7. Those figures cover the 43 newly exploited vulnerabilities Rapid7 tracked that quarter, not every disclosed vulnerability.

Q: Is monthly patching still good enough?

A: For most vulnerabilities, yes. For internet-facing flaws that need no login, or that are already being exploited, no. Rapid7 found that less than 1% of high-severity remote code execution flaws in its data were exploited, but the ones that were exploited were hit quickly. A monthly cycle plus a narrow emergency track covers both cases.

Q: What is the CISA KEV catalog?

A: The Known Exploited Vulnerabilities catalog is CISA’s list of flaws with evidence of real-world exploitation. To be added, a flaw must have a CVE ID, evidence of exploitation, and clear mitigation guidance. It’s one of the most useful triggers for an emergency patching track because it confirms attacks are actually happening.

Q: Does CISA’s BOD 26-04 apply to MSPs?

A: Not directly. BOD 26-04 applies to federal civilian agencies, and it doesn’t cover contractors unless their contracts require it. But its four questions about exposure, known exploitation, automation, and level of control are a practical way for any MSP to decide which flaws need a three-day clock.

Q: What should a patch SLA in a client contract include?

A: At minimum, a patch SLA should define severity tiers, a target time for each tier, when the clock starts, what counts as fixed, pre-approved emergency maintenance, documented exceptions, and how results get reported. Review the language with legal counsel, and start with targets you can reliably meet on the systems you fully manage.