Vulnerability Remediation: From Low Findings to Full Compromise

The scan report came back with no criticals. Forty-one findings: mostly lows, a handful of mediums, and a covering note saying overall risk was acceptable. Nobody lied, and nobody was careless. Six weeks later the environment was ransomed, and the path the attacker took ran through five of those findings in order.

This is what severity scoring does badly. A CVSS score describes a weakness in isolation, on a hypothetical average system. Attackers do not operate in isolation. They operate in your environment, where a low-severity information leak tells them precisely which host to go after next, and where a “minor” configuration weakness three hops away turns a foothold into everything.

Severity is not risk

A base CVSS score deliberately ignores almost everything that decides whether a finding matters to you: whether the asset is internet-facing, whether it sits in a segment that reaches anything valuable, whether an exploit exists, whether the vulnerable code path is even used. It was never designed to be a work queue, and using it as one is how organisations end up patching a 9.8 that nobody has ever exploited while leaving a 4.3 that is actively being used as a stepping stone.

The arithmetic that actually matters is simple and uncomfortable. If an attacker needs five steps, and each one is individually easy, then the chain is easy. Severity does not add up; it compounds.

Better signals to prioritise on:

• CISA KEV. The catalogue of vulnerabilities known to be exploited in the wild. If something is on KEV, it is being used right now, and the CVSS number is irrelevant to your decision.
• EPSS. A probability that a given vulnerability will be exploited in the next thirty days. A 9.8 that nobody is exploiting is genuinely less urgent than a 6.1 with a high EPSS score.
• Exposure and reachability. Internet-facing changes everything. So does whether the vulnerable component is actually loaded and reachable.
• Blast radius. What does this asset reach, and what credentials live on it?

And one more thing, which is the hardest to fix: many of the worst findings are not CVEs at all. Over-privileged service accounts, legacy protocols left enabled, certificate templates misconfigured, flat networks. They have no patch, so they never enter the patching process, and they sit untouched for years while everyone concentrates on the number that has a vendor fix attached.

What changed: AI can now find the vulnerabilities as well

For most of the history of this discipline, the scarce resource was skilled human attention. Finding a novel vulnerability in well-reviewed code took a specialist weeks. Chaining several of them into a working intrusion took a good team. That scarcity is what made “we will get to the lows next quarter” a defensible position.

In April 2026, Anthropic announced Project Glasswing and disclosed what its unreleased Claude Mythos Preview model had been doing in testing. The numbers are worth sitting with, because they change the arithmetic above.

• It found thousands of zero-day vulnerabilities, many of them critical, across every major operating system and every major web browser.
• Among them: a 27-year-old flaw in OpenBSD, and a 16-year-old flaw in FFmpeg that automated fuzzing had run past roughly five million times without ever catching.
• On known, already-patched vulnerabilities, it produced working exploits for more than half of forty selected CVEs from 2024 and 2025. The previous flagship model was close to a zero per cent success rate at the same task.
• On Firefox specifically, it produced 181 working exploits, against two for the previous generation across several hundred attempts.

And then the finding that matters most for this article:

Mythos Preview autonomously chained between two and four separate Linux kernel vulnerabilities into working privilege escalation — and did it in nearly a dozen distinct cases.

That is the diagram at the top of this page, performed by a machine, at machine speed, without a specialist. The composition step that used to be the expensive part is now something a model does on its own.

Two details deserve particular attention. The first is that Anthropic states these capabilities were not explicitly trained for — they emerged as a downstream consequence of the model simply getting better at code. That means this is not a one-off tool that can be countered; it is a property of capable models, and it will keep improving on its own schedule.

The second is the response. Mythos Preview was not released generally. Access went to defenders first: AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA and Palo Alto Networks, plus more than forty organisations that maintain critical software infrastructure. That is a genuinely responsible decision and it buys the ecosystem time. It does not buy permanence. Capability demonstrated once is capability that other labs, and eventually other actors, will reach.

Anthropic’s own summary of what this means is blunt, and it is the sentence to take away: what once took months, it says, “now happens in minutes with AI”.

The practical consequence for your environment is direct. Prioritising by individual severity was always a rough approximation. Against an automated attacker that will cheerfully try every combination of your low-severity findings until one works, it stops being an approximation and becomes a liability.

Patch more often than feels necessary

A single monthly cadence for everything is a schedule designed for a slower opponent. It is also, usually, a schedule designed around change-management comfort rather than around risk.

Tier by exposure, not by severity alone:

Internet-facing, or on KEV — days, with a rehearsed emergency path measured in hours.

Internal, exploitable, high EPSS — one to two weeks.

Everything else — the monthly cycle is fine.

The obstacles are real and worth naming: change windows, fear of breaking production, applications whose vendor only certifies an old version, no test environment, and assets with no identifiable owner. None of those are solved by wanting to patch faster. They are solved structurally:

• Automate the boring majority. unattended-upgrades or dnf-automatic for Linux security updates; Windows Autopatch, Intune or WSUS rings for the Microsoft estate. Reserve human attention for the exceptions.
• Deploy in rings. Canary, then pilot, then broad. Counter-intuitively this is what lets you go faster: you find breakage on ten machines instead of a thousand, so the organisation stops being frightened of patching.
• Have reboot discipline. A patch that is installed but not rebooted into is not applied. Kernel livepatching buys uptime and is genuinely useful, but it is not a permanent substitute.
• Measure mean time to remediate, not the number of scans run or findings opened. If you track one number, track the age of your oldest unremediated internet-facing finding. It tells you more than any dashboard.
• Rehearse the emergency path. The out-of-band critical will arrive on a Friday. Whether that is a procedure or an improvisation is decided long before it happens.

Every layer has its own queue

Vulnerability management tends to mean “servers”, because that is what the scanner was pointed at. The chain runs through everything else too.

Physical

• Building systems are computers. Badge controllers, door systems, cameras and NVRs run full operating systems, are rarely patched, frequently sit on the same flat network as everything else, and often still have vendor default credentials behind a web interface designed in 2014.
• Out-of-band management. iDRAC, iLO, IPMI and BMCs run firmware that sits below the operating system. A compromised BMC survives an OS rebuild, and far too many are reachable from the general LAN.
• The unglamorous things. Unlocked racks, live network ports in reception, USB ports on kiosks, and drives leaving the building at decommissioning with data still on them.

Network

• Edge appliances are now the most reliable way in. VPN concentrators, firewalls and load balancers are internet-facing by definition, run bespoke vendor code, and cannot be patched without an outage — so they get deferred. Attackers know this better than anyone.
• Switch and router firmware routinely runs years behind, because nothing visibly breaks when it is old.
• Management planes on the production network, SNMP with default community strings, and Telnet still quietly enabled on something.
• Segmentation is the compensating control. Where you cannot patch quickly, make the thing reachable by fewer other things.

Hypervisor

• Patching ESXi, vCenter, Hyper-V, Proxmox or Nutanix means moving workloads, so it slips more than anything else in the estate.
• Hypervisor ransomware is now a standard play. Encrypting the datastore takes out every virtual machine at once, which is far more efficient for an attacker than encrypting them individually.
• Compromise of vCenter is compromise of everything it manages. Treat its advisories as a different class of urgency.
• Get management interfaces off the user network. If you do one piece of segmentation work this year, do this one.

Linux

• Kernel and userspace on a schedule, with unattended-upgrades or dnf-automatic handling security updates unattended.
• Livepatching (kpatch, Ksplice, Canonical Livepatch) keeps uptime while kernel fixes land, but plan real reboots anyway.
• End-of-life distributions still in production — the quiet killer, because the scanner reports nothing to patch when no patches exist.
• Third-party repositories and vendor tarballs that no package manager tracks, and language dependencies — pip, npm, Maven, Go modules — that an OS-level scanner never sees at all.

Windows

• Patch Tuesday is the floor, not the ceiling. Out-of-band releases happen, and they happen for the things being exploited.
• Third-party applications are the real gap. Browsers, Java runtimes, PDF readers, remote-access tools. The Microsoft estate gets patched; the software sitting on top of it often does not.
• Active Directory weaknesses that are not CVEs: certificate template misconfigurations (the ESC family), Kerberoastable service accounts, unconstrained delegation, LAPS not deployed, and privileged accounts that should have been disabled years ago.
• Vulnerable signed drivers, used to disable security tooling. Turn on the Microsoft driver blocklist.

Cloud

• Shared responsibility cuts both ways. The provider patches the hypervisor. You still own the instance, the image, the dependencies and — above all — the configuration.
• Most cloud incidents are identity and configuration, not CVEs. Over-broad IAM roles, public storage, permissive security groups, and instance metadata exposure that turns a routine SSRF into cloud credentials.
• Stale machine images and container images baked months ago and never rebuilt, and managed services left on versions past support.
• SaaS OAuth grants and integration tokens — standing access to your data that nobody reviews and no scanner reports.

For larger organisations: bring scanning in-house

Beyond a certain size, an external scanning engagement stops being enough. The case for running your own platform:

• Coverage. A hosted external scanner cannot see your internal segments, your OT network, or isolated environments. Those are exactly where chains run.
• Frequency. When you own the platform you scan continuously, rather than when the engagement renews.
• Authenticated scanning. Credentialed scans find dramatically more than unauthenticated ones, and the credentials involved should stay inside your boundary.
• Integration. Findings flow into your CMDB and ticketing automatically, get assigned to a real owner, and have SLAs measured against them.
• Sensitivity. A complete inventory of your weaknesses is itself a high-value target. It is reasonable to want it under your own control.

What the platform should consist of:

• Asset discovery first. You cannot scan what you do not know exists, and incomplete inventory — not scanning capability — is the usual point of failure.
• Authenticated network scanning — Tenable, Qualys or Rapid7 commercially; Greenbone and OpenVAS where budget matters more than polish.
• Agents for endpoints and roaming devices that are rarely on the network when the scan window opens.
• Image and container scanning in CI — Trivy or Grype, failing the build rather than filing a ticket.
• Software composition analysis for application dependencies, which network scanning will never see.
• Cloud posture management for the configuration and identity layer.
• One place where findings are correlated, de-duplicated and assigned — DefectDojo if you want that open source.

One caution, because this is where in-house programmes most often go wrong: scanning capacity is not the bottleneck. Remediation throughput is. A platform producing forty thousand findings that nobody actions is worse than a modest one whose output gets fixed, because it teaches the organisation that the report is noise.

The structural fix: have less to patch

Everything above is about responding faster. The larger win is reducing how much there is to respond to. Every package you never install is a vulnerability you never have to triage, a patch you never have to test, and a ticket that never gets created.

Minimal operating systems

Install the minimal profile rather than the general-purpose one. A default server install drags in compilers, interpreters, clients and daemons that your workload never touches — and you inherit every advisory against all of them. Beyond the minimal variants of RHEL, Ubuntu and Debian, there are purpose-built options — Flatcar, Talos Linux, Bottlerocket — that ship with no package manager and effectively no shell, because the whole category of “something else installed on the box” has been designed away.

Image mode

Image mode — bootc, and RHEL’s image mode built on it — treats the operating system as a container image. You build it in CI, test it, sign it, deploy it atomically, and roll it back atomically. Updating stops being “apply two hundred and forty packages to a running server and hope” and becomes “boot the new image that has already been tested”. The same pipeline and the same review path covers the OS and the application, and drift between servers stops being possible.

Minimal and hardened container images

A conventional base image carries hundreds of packages your application does not use, and you inherit every CVE in all of them. Most container scan reports are dominated by findings in software the container never executes.

• Chainguard Images — built from source on Wolfi, distroless by default, continuously rebuilt, signed, and shipped with SBOMs and provenance attestations. The marketing line is near-zero known CVEs; the practical value is that your scanner output becomes short enough that somebody actually reads it.
• Google distroless, and the -slim and Alpine variants of common base images, as free alternatives that get you a good part of the way.

The cultural shift that comes with this matters more than the tooling: rebuild rather than patch. Images are rebuilt from a current base on a schedule and redeployed, instead of being patched in place. The question changes from “which CVEs does this have?” to “how old is this image?” — which is a far easier question to automate and to audit. Sign what you build with cosign, keep the SBOM, and use admission control to refuse images that are unsigned or stale.

An honest caveat: minimal images move effort rather than eliminating it. Debugging a container with no shell takes adjustment, and you take on a dependency on your image supplier’s rebuild cadence. Both are manageable, and both are worth knowing about before you commit.

Where to start

• Fix the inventory. Everything else is guesswork until you know what you have.
• Put KEV membership and internet exposure above raw CVSS in your priority order.
• Set tiered SLAs and start measuring mean time to remediate.
• Get hypervisor, BMC and network management interfaces off the user network.
• Rebuild one service on a minimal image and compare the scan output with what it replaced.
• Rehearse an emergency out-of-band patch before the Friday you need it.

Nothing on the report was critical. That is exactly how it happened. Attackers do not read your severity column — they read your environment, and they now have a great deal of help doing it quickly.