How to respond to a critical CVE when you have no security team
Short answer: ask five questions in order: is it being exploited, do you actually run the affected code, can an attacker reach it, is there a fix or workaround, and how will you prove the fix is live. Most critical CVEs stop at question two or three. The few that don't should be handled the same day.
Most runbooks are written for organisations with a security team. This one is for a handful of engineers who also have a product to ship. The decision tree is our suggested process (the time boxes are our judgement, not a standard); the facts it relies on are linked and read on 2026-11-01.
The five questions
1. Is it being exploited?
“Critical” is a severity score, not a likelihood. The signal that changes your day is evidence of attacks:
- CISA’s Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with known exploitation. Its 2026-10-30 release has 1,766 entries (we read the published feed). Each entry carries a date added and a due date for US federal agencies, which is a useful clock even if you are not one: React2Shell (CVE-2025-55182) was added 2025-12-05 with a due date of 2025-12-12, one week.
- EPSS is a model that “estimates the probability that a published CVE will be exploited in the wild in the next 30 days,” published daily for every CVE. Useful for ranking, not proof.
- The vendor advisory, which will say if they know of attacks.
In KEV or vendor-confirmed exploited: go to question 2 immediately. Otherwise you still go to question 2, but the clock is days, not hours.
2. Do you run it, and where?
Not “is it in our repo” but “is it in what’s deployed.” Check three places: the lockfile, the built image, and the running service. Stale containers and forgotten services are where old versions hide. For JavaScript apps, the version that matters may be inside a framework: for Next.js the check is on next, not react (how to check).
Tools, cheapest first: the lockfile checker in your browser; dynv scan in CI (no account needed, exits 1 at or above --fail-on); and, for what is actually installed in running services, Dynv’s vulnerability monitoring (dynv run --vulns), which re-checks at boot, on change and every six hours. Instant advisory alerts are coming soon; today it is within hours.
If you don’t run it: write that down (date, how you checked) and stop. That note is your audit evidence.
3. Can an attacker reach the vulnerable code?
Read the advisory’s conditions. Many require a specific feature, configuration or exposure. Example from the 14 October 2026 Next.js advisories: one critical RCE applies only to apps with a use cache function returning multiple typed arrays under the App Router; another needs Image Optimization on glibc Linux; the denial of service needs a Server Action (summary table). Note the maintainers’ own caution on the first: upgrade even if you don’t think you have such a function.
Ask: is the affected service internet-facing? Is the vulnerability unauthenticated? Is the affected feature on? If any answer is “no”, you have more time, not no time.
4. Is there a fix or a workaround?
Prefer the fix. If you can’t deploy it today, apply the vendor’s workaround, restrict the exposed route or feature, or put the service behind a control that blocks the path. Record what you did and when you’ll finish.
5. How will you prove it landed?
The step most teams skip. “The PR merged” is not “production is fixed.” After deploying, re-check from the running service. And re-scan after you upgrade, because a fix can be partial. We scanned a lockfile with [email protected], the version in the React2Shell advisory (output from the current dynv build, 2026-11-01):
$ dynv scan
SEVERITY PACKAGE VERSION FIXED ID
critical react-server-dom-webpack 19.0.0 19.0.1 GHSA-fv66-9v8q-g76r
high react-server-dom-webpack 19.0.0 19.0.2 GHSA-2m3v-v2m8-q956
high react-server-dom-webpack 19.0.0 19.0.5 GHSA-479c-33wc-g2pg
high react-server-dom-webpack 19.0.0 19.0.4 GHSA-83fc-fqcc-2hmg
high react-server-dom-webpack 19.0.0 19.0.6 GHSA-rv78-f8rc-xrxh
high react-server-dom-webpack 19.0.0 19.0.8 GHSA-wx67-qw84-cm4g
medium react-server-dom-webpack 19.0.0 19.0.2 GHSA-925w-6v3x-g4j4Moving to the version that fixes the critical (19.0.1) would still leave six advisories open; the fix column tells you the newest version you need. Upgrading to the first patched version is a start, not an end.
Time boxes (our suggestion)
| Situation | Target |
|---|---|
| Exploited (KEV or vendor-confirmed), you run it, reachable | Mitigate within hours, fix and verify within 24 hours; treat as a possible breach |
| Exploited, you run it, not reachable | Fix within a week |
| Not known exploited, critical, reachable | Fix within a few days |
| Not reachable or not running | Note it; fix in the normal release |
“Treat as a possible breach” matters for remote code execution: if a service was exposed and unpatched, its process could read its own environment. Rotate what that service held, from a clean machine, starting with write-capable credentials. With Dynv, a previewed rotation shows every service and alias that shares the secret and applies one new value in a single pass.
What to write down
For auditors and for the next incident, one short record per CVE: identifier; date you learned of it; is it in KEV; do you run it (how you checked); exposure; decision; fix date and version; how you verified; who approved any delay. A paragraph is enough, and it is the evidence a SOC 2 or customer questionnaire will ask for later.
Limits
- Scanners know published advisories. A zero-day, or a vulnerability in your own code, won’t appear. A scan result is a statement about known advisories.
- A match is not exploitability. Reachability needs the conditions in step 3 checked by a person.
- Dynv’s monitor reports and alerts; it does not block an exploit. Containing a compromised service is a different control.
- KEV and EPSS are not filled in by
dynv scan. Its JSON haskevandepssfields, but they were empty in our test, so check CISA’s catalog and EPSS yourself for the CVE in question.
Facts last verified . Spotted an error? Tell us.