The Collapsing Patch-to-Exploit Window: Planning for N-Day Attacks

Three Days Is the New Normal

JFrog disclosed and patched a critical Artifactory authentication bypassAuthentication Bypass📖A security vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. that allows an attacker to circumvent the login verification process and gain unauthorized access to a system without providing valid credentials. (CVE-2026-82329) on August 28, 2026. By September 1, watchTowr was reporting in-the-wild exploitation, with attackers minting administrator tokens on unpatched servers. Three days, disclosure to exploitation — and notably, the vulnerability was not yet in CISA's KEV catalog when the attacks began.

This is an n-day attack: exploitation of a vulnerability that is publicly known and has a patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program. available, in the gap before defenders apply it. N-days lack the mystique of zero-days, but they account for far more real-world compromise, because the attacker's problem is trivially easier — the vulnerability is documented, the patch itself points to the flaw, and the target list is every organization that has not yet acted. The strategic question for defenders is not whether you will face n-day attempts, but whether your patch process finishes before the exploitation curve reaches you.

Why the Window Keeps Shrinking

**Patches are roadmaps.** Attackers diff patched binaries against vulnerable ones to locate the exact change, working backward to an exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access.. For many product classes this takes skilled teams hours to days, not weeks. Public proof-of-concept code, when it appears, collapses the remaining effort to near zero.

**Exploitation is increasingly automated.** Scanning infrastructure that once required an operator now runs as a pipeline: ingest advisory, identify fingerprintable targets, exploit at scale. In the Artifactory case, The Register noted defenders could not even tell whether observed exploitation came from humans or AI agents — automation is now indistinguishable from the operator it replaced. Whatever the mix, the practical effect is the same: the time between "patch exists" and "your unpatched instance is found" is measured in days.

**Advisory ecosystems lag.** CISA's KEV catalog is a confirmation mechanism, not an early-warning one — evidence of exploitation must be verified before an entry lands. Organizations that use KEV listing as their trigger to act are, by construction, acting after exploitation is established. KEV is an excellent floor and a poor starting gun.

Planning Around a 72-Hour Assumption

The planning consequence is a patch service-level objective measured against attacker speed rather than change-window convenience. A practical structure:

**Tier your software by exposure and blast radius, not by vendor prestige.** Tier 0 is anything internet-reachable whose compromise yields broad control: identity providers, VPN concentrators, mail servers, file transfer appliances — and, as the last two months of KEV additions make clear, developer infrastructure. An artifact repositoryArtifact Repository🛡️A server that stores and serves the binary outputs of software builds — packages, container images, libraries — plus the dependencies pulled into them. Because every deployment consumes its contents, administrative compromise of an artifact repository lets an attacker tamper with the software supply chain at scale. or source forge sits upstream of every binary you ship; the Artifactory incident showed admin access there being described, fairly, as the ability to poison everything downstream.

**Set explicit SLOs per tier.** For tier-0 systems, aim to apply critical patches within about 72 hours of vendor advisory — not the next monthly cycle. That target is aggressive precisely because the data says three days is what you actually get. Lower tiers can carry longer SLOs; the point is that the number is chosen deliberately, agreed with the business, and rehearsed, rather than emerging from whenever the change board next meets. For the process mechanics once an exploited-vuln deadline does land, see How to Triage a CISA KEVCISA KEV🛡️The Known Exploited Vulnerabilities catalog maintained by CISA, listing vulnerabilities actively exploited in attacks that federal agencies must patch by specific deadlines. Addition in 72 Hours.

**Pre-authorize emergency change.** The slowest step in most patch timelines is not the patch — it is permission. An emergency-change path with pre-agreed criteria ("critical severity, network-reachable, authentication or RCE impact") converts a three-day approval cycle into a same-day action. If your process cannot patch a tier-0 system on a weekend, you have a process vulnerability with no CVE number.

**Buy time with exposure reduction.** Every system that does not need to be internet-reachable and is anyway is voluntarily standing in the blast zone. Admin interfaces behind VPN or IP allowlists, management planes on separate networks, and aggressive removal of unused services all convert "must patch in 72 hours" into "should patch soon" — a dramatically cheaper posture. Compensating controls are the pressure valve for the systems you genuinely cannot patch fast.

**Plan for the patch you missed.** A collapsing window means some percentage of the time, exploitation will beat you. Budget for that: know in advance what an identity and persistence audit looks like for each tier-0 system, so that "we patched on day five" triggers an investigation rather than a sigh of relief. The companion piece How to Hunt for Forged Admin Tokens and Backdoor Accounts covers exactly that scenario, and How Default Secrets and Phantom Credentials Break Authentication explains why some vulnerability classes make post-patch auditing non-negotiable.

The Metric That Matters

Most vulnerability-management programs report patch compliance as a percentage at 30 days. Against a three-day exploitation window, that number is a comfort metric. The figure worth putting in front of leadership is time-to-patch for internet-facing critical vulnerabilities, tracked as a distribution, with the tail investigated the way you would investigate an outage. Attackers are running a race with a known course; the only strategic response is to know your own lap time and decide, deliberately, which systems must finish first.