Thirteen hours to exploit: a repeatable N-day triage runbook

This is a methodology post, so there is no single vulnerability to dissect. The deliverable is the pipeline itself: a repeatable N-day triage runbook that turns a fresh advisory into a version fingerprint, a safe proof of exposure, a specific patched build, and a verified fix, in that order, under a clock. It is deliberately different from our earlier piece on the KEV clock, which framed the remediation deadline and why an entry on the catalog reorders your queue. This one ships the machine that runs inside that deadline, plus the reproducible per-CVE exposure check that is its output. Verifiable security.

Why thirteen hours changes the process

Two numbers set the scope. CVE-2026-33626, a flaw in the LMDeploy inference server, was reportedly exploited within about thirteen hours of its disclosure, as The Hacker News reported at the time. CVE-2026-8451 in NetScaler followed a similar curve, with exploitation observed inside roughly a day. These are not the slow-burn CVEs that can wait on a backlog. They are the ones where the gap between public knowledge and mass scanning is shorter than the gap between two of your meetings.

The CISA Known Exploited Vulnerabilities catalog puts a formal clock on the same phenomenon. cPanel's CVE-2026-41940 was added to the catalog on 30 April 2026; Ivanti Sentry's CVE-2026-10520 was added on 11 June 2026. Each catalog entry carries a required remediation date, and for the fastest-moving classes that date is close. The lesson across both signals, the informal thirteen-hour anecdote and the formal KEV deadline, is identical: the response has to be a procedure, not a project. A procedure can be run in an hour by whoever is on shift. A project needs a meeting to even begin, and a meeting is exactly the time you do not have.

Both clocks start the moment the advisory is public. The runbook exists to make the bottom line finish first. Illustrative timing, drawn from the public record.

The runbook, stage by stage

Five stages, run in order, each producing a single clear output that feeds the next. Nothing here requires convening a group; it requires having decided the steps in advance.

1. Ingest

Watch four feeds continuously: NVD for the authoritative record, the vendor PSIRT for the affected and fixed builds, the CISA KEV catalog for confirmed in-the-wild exploitation, and FIRST's EPSS for the modeled probability that exploitation is coming. When a high-signal entry appears, an unauthenticated code path, a widely deployed product, a rising EPSS score, or a fresh KEV listing, extract two facts before anything else: the exact affected and fixed version ranges, and the vulnerability class. Everything downstream keys off those two facts, so getting them right is the whole job of this stage.

2. Fingerprint

Build a passive version check. The goal is to inventory who is exposed without ever touching the vulnerable code path. A banner, a build string in a response header, a static asset hash, a login-page fingerprint, or the vendor's own version endpoint is usually enough to sort your fleet into affected, fixed, and unknown. Fingerprinting is safe to run at scale precisely because it reads a version, it does not trigger a condition. This is the single highest-leverage stage, because it converts a global advisory into a specific list of your hosts that carry the risk today.

3. Prove

A version number is a strong signal, not a proof. The Prove stage authors a minimal, non-destructive proof of exposure that demonstrates the vulnerable condition is actually reachable, without exfiltrating data or running attacker-supplied code. The shape depends on the class: a length variance showing an over-read returns more bytes than it should, a benign marker that echoes back to confirm an injection point, or a plain reachability check that an endpoint answers before authentication. None of these move data or execute a payload. For us, a confirmed proof becomes an Ed25519-signed Proof Capsule recording the host, the version evidence, and the reachability result, reproducible offline by you or your auditor. That signature is what separates "we think you are exposed" from "here is the proof."

4. Fix

Map the finding to the exact patched build, not a vague upgrade note, and pair it with a compensating control that buys time while the patch is scheduled. A WAF rule that blocks the specific request shape, an admission policy that rejects the vulnerable configuration, or network isolation that removes the surface from the public internet can hold the line for the hours or days before a maintenance window opens. Under a thirteen-hour clock, the compensating control is often what actually beats the attacker to the host. The patch is what makes the fix permanent.

5. Verify

Re-run the fingerprint and the proof against the same host. The fingerprint confirms the build moved to the fixed version; the proof confirms the condition is no longer reachable. Two independent checks, because a version bump that never actually deployed and a config change that never actually took are both common failure modes. Verify also answers a question the first four stages cannot: given how short the pre-patch window was, was this host reachable during it, and does the evidence let you rule out compromise before you patched. A fix you did not verify is a hope, and hope does not survive a countdown.

A version number is a strong signal, not a proof. The runbook does not stop at "you look exposed," it produces the signed, reproducible evidence that you were, and then that you no longer are.

Run this on every same-day advisory

Find, Prove, Fix, Verify, under a countdown

The reason this works is that it removes the two slowest things from incident response: the meeting and the guess. Every stage has one output, every output is evidence, and the whole pipeline can be run by whoever is on shift when the advisory drops. Thirteen hours is not enough time to convene a working group. It is enough time to run a runbook you rehearsed last month, and that is the entire point of writing it down before you need it.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held, before the scanners reach you.