Your renderer's vendor shipped a fix this morning — why can the number of capable attackers rise?

## Two curves crossing Think of a single flaw's life as two quantities changing over time: **how many people can exploit it**, and **how many machines are still vulnerable**. Intuition says the fix makes both fall. Only the second one does, and it falls slowly. Before the fix, the first quantity is tiny. Exploiting the defect requires having found it — original research, or a purchase from someone who did it. After the fix, the first quantity jumps, because the fix itself tells people where to look. ## Why a fix is a description of the bug A fix is a change to code, and a change is visible. Comparing the corrected build with the immediately preceding one narrows attention from an entire application to a handful of altered functions. The nature of the change is often self-explanatory: a length check added before a copy, a bounds test on an index, a type confirmed before a cast, a permission verified before an action. Each of those says, in effect, 'the previous version could be driven past this point'. Reconstructing input that reaches the changed code is then a bounded engineering problem rather than a search. This is why disclosure timing is contentious at all: the moment of publication is the moment the knowledge becomes symmetrical. It is also why the interval between a fix shipping and exploitation appearing has, for well-understood classes of flaw, been observed to be short — sometimes days. ## Why your side does not move at the same speed Getting the corrected code *running* is a chain, and every link is a place where the estate stalls: - The update must be published to the channel the machines use. - It must be downloaded and installed. - The vulnerable code must actually be re-loaded, which for a long-running application means the process has to restart. That last step is the one that surprises people. An inventory can honestly report that every laptop has the fixed version installed while a renderer process that a user has kept open for eleven days is still executing the old code in memory. Exposure ends at the restart, not at the install, and certainly not at the advisory. ## The window, laid out The same defect produces two different exposures. The first — the true zero-day window — is narrow in reach: one holder, spending the asset carefully. The second — the n-day window — is wide: many actors, working from public knowledge, against every machine that has not yet restarted the affected program. For most organisations the second window is where nearly all the real risk lives, and it opens at the moment the first one closes. ## What this means for how you talk about a compromise When someone says 'we were hit by a zero-day', the load-bearing check is whether a fix existed on the day. If it did, the event lives in the n-day window, and the honest description is that public knowledge outran the estate's restart clock. That is a different problem with different owners and, unlike the zero-day case, it is entirely addressable. It also reframes what 'we are patched' means as a claim. 'Patched' as an inventory statement is about installed versions. 'Patched' as a risk statement is about processes running corrected code. Only the second one closes the window, and only the second one is worth asserting to anyone who will act on it. ## Common wrong answers - 'Risk falls the moment the vendor ships' — it falls only for the machines that have already restarted, while the capable population rises immediately. - 'Only sophisticated actors can build an exploit from a fix' — deriving a trigger from a visible code change is far cheaper than original discovery, which is exactly the point. - 'The advisory date is the exposure date' — the advisory marks when knowledge became public, not when your code changed behaviour.