What an unpatched vulnerability on a server costs

In 2025, Romania's National Cyber Security Directorate (DNSC) informed 2,020 public institutions and operators of essential services about more than 43,000 exploitable vulnerabilities found on their publicly exposed IT infrastructure, with a recommendation to fix them urgently. For most of those organisations, an unpatched vulnerability is not an unknown risk. It is a line in an email somebody already received, naming the product, the address and the fix that already exists.

What happens when that line stays a line appears in the same report. Aaylex ONE SA, the food group behind the CocoRico brand — over 2,000 employees, 36 sites across nine counties — was hit by Akira ransomware, with effects on accounting, production, operations and the file servers; the DNSC later recovered more than 66% of the data. Initial access most likely came through exploitation of CVE-2020-3259, in the web interface of Cisco ASA and Firepower Threat Defense appliances. The first four digits of that identifier are the year it was published.

How long the window lasts, and what an unpatched vulnerability costs

The finding itself is already established, and we wrote it up separately, in the article on servers exposed to the internet: the 2026 edition of the Verizon DBIR, built on more than a billion detection records, measures a median of 43 days to fully remediate a vulnerability from the CISA catalogue of actively exploited vulnerabilities, up from 32, and only 26% fully remediated, down from 38%. We are not repeating the finding here. We are doing the arithmetic.

The median hides the part that matters. Analyses of the same data show that on day 7, between 60% and 70% of actively exploited vulnerabilities are still open — regardless of the year, the volume or the maturity of the organisation; even at their best, organisations close 30-40% in the first week. By day 28, 35% of instances were still open in 2025, against 27% in 2024. And the volume keeps growing: in the median case, 50% more critical vulnerabilities than the year before. The backlog compounds too: in a separate measurement, by Cyentia and Veracode, 82% of organisations carry known vulnerabilities left unresolved for more than a year.

Time has a price, and there is one figure in which time is the only variable. The IBM Cost of a Data Breach Report 2026 shows that breaches identified and contained in more than 200 days cost an average of 5.65 million dollars, against 4.32 million for those resolved faster — a difference of roughly 1.33 million, and the distance between the two groups widened compared with the previous year rather than narrowing.

Figures in the millions sound like an American corporation, and fairly so. The closest thing to a mid-sized firm comes from the Sophos survey The State of Ransomware 2026, covering 2,158 IT leaders in 17 countries, at companies of 100 to 5,000 employees hit by ransomware: organisations with revenue under 50 million dollars received median ransom demands of about 140,000 dollars, those above 5 billion, 5.7 million. Attackers calibrate the demand to the perceived ability to pay. The average recovery cost, excluding any ransom, was 1,700,200 dollars — an order of magnitude for that population, not an invoice a 60-person company should expect.

Easier to feel than the money is the probability. In the same survey, 41% of attacks were stopped before encryption — but firms of 3,001-5,000 employees manage that in 46% of cases, and those of 100-250 employees in only 34%. The report does not explain the twelve-point gap, but it translates the window from money into probability: the later somebody looks, the more often the attack reaches encryption. And the root cause sits exactly where the window is: exposed applications and systems 38%, firewall 21%.

Where the window is actually lost, in a company that is not negligent:

• The notification lands in a generic mailbox and is forwarded "to IT" with no deadline and nobody to confirm the fix was applied.
• The fix needs a maintenance window, the window needs sign-off from someone in operations, and the sign-off slips to next weekend — for three weekends running.
• The vulnerable device sits at the edge of the network and is administered by the internet provider or the integrator, so nobody inside the company feels like its owner.
• The high-scoring ones get fixed, because a high score is easier to explain to management, while the one actually being exploited stays eleventh on the list.

Why the window does not close by hiring faster

The normal reflex, on seeing the figures above, is to conclude that you are one person short. The data does not support that conclusion. The Cyentia Institute modelled, across roughly 300 organisations, the monthly rate at which vulnerabilities are closed against the rate at which they open, and found something uncomfortably stable: a typical organisation has the capacity to remediate around 1 in 10 vulnerabilities per month in its environment, and this appears to hold for large firms, small firms and everything in between. Remediation capacity behaves like a ceiling, not like a linear function of how many people you have on the team.

The Sophos survey shows the same thing from another direction. A shortage of people or capacity is cited heavily by companies with 100-250 employees, which surprises nobody; the unexpected part is that four in ten organisations with 3,001-5,000 employees cite it at a rate only 3% lower. Resources do not necessarily get easier with scale. And the most cited operational cause, for the second year running, remains "security gaps, known or unknown", at 62%, ahead of a shortage of people or skills, at 58%.

One more argument, from Romania: in its 2025 report, the DNSC states a staffing level of 17.69%. The national authority operates at less than a fifth of its established posts and still monitored 317,000 CVE records, of which it analysed 121 in detail immediately after publication. It did not manage that by hiring more. It managed it by selecting.

The problem is not the workload, it is the order

This is where the whole discussion changes. FIRST.org, the body that publishes EPSS scores, notes that the CISA KEV catalogue contains around 0.5% of published CVEs, and that in any given 30-day window EPSS observes exploitation activity against roughly 2.5-3% of them. The most generous estimate says at most around 6% of published CVEs are ever exploited in the wild; stricter datasets point to 1-2%. Of 35,364 vulnerabilities published in the first half of 2026, only 85 had appeared in KEV at the time of an independent analysis — with the fair caveat that KEV lags by months and records only confirmed exploitation.

Read together with the capacity ceiling, that figure inverts the problem. If you fix around 10% of your inventory per month regardless, and only a few percent of the vulnerabilities in that inventory will ever be used against you, then you do not have a workload problem. You have a selection problem. The company that fixes 10% a month and chooses badly loses; the company that fixes exactly the same 10% and chooses well is covered. The difference between them is not one extra hire.

You do not fix more. You fix in a different order — and that order has to be recalculated at the pace at which the attacker's list changes, not at the pace of the quarterly report.

That pace is not generous. VulnCheck measured, across 884 vulnerabilities that entered KEV in 2025, that 28.96% had evidence of exploitation on the day the CVE was published or earlier; in the first half of 2026, 23.43%. The 2025 edition of the DBIR measured, on 2024 data, a median of 5 days to mass exploitation of a KEV vulnerability and zero days for perimeter ones — a figure from the previous edition, on a different year, so not one to subtract anything from. For almost one vulnerability in four, the attacker's clock starts before yours regardless.

That is why prioritising on a single criterion does not work. The CVSS severity score describes how bad it would be if, not how likely it is. Nor is likelihood enough on its own: in August 2026, of 26 vulnerabilities added to the KEV catalogue, 18 had an EPSS score below 1%. What works is a combination of five: severity, likelihood of exploitation, presence on the confirmed-exploitation list, the real exposure of the service and how critical it is to the business. That produces the situation which frightens an auditor and is nevertheless correct: a medium-severity vulnerability, actively exploited, on an internet-facing service goes ahead of a near-maximum-severity vulnerability nobody is exploiting, on an internal service.

How heavily the vulnerability vector weighs against the others is something the sources do not settle: DBIR 2026 puts it first, at 31% of breaches; the Sophos survey sees it falling from 32% to 18%, below malicious email — but it asks victims what they believe the cause was, and a 150-person company recognises an email more readily than a vulnerability it did not know it had. The figures are not comparable with each other. What does not depend on which one you pick: 59% of ransom demands in attacks that started from an exploited firewall vulnerability are one million dollars or more, against 48% of all demands. A rarer and more expensive vector is not a reason to ignore it.

The order of operations, if you want to shorten the window

Nothing on the list below assumes a corporate budget. It assumes only that things get done in this order, not the other way round.

1. 1Inventory your real exposure — what actually answers a request from outside, not what somebody remembers. Without it, any prioritisation is done on the wrong map.
2. 2Decide who receives the notifications — from the national authority, from the vendor of your perimeter device, from your own scanning — and write down a response deadline. A notification with no owner and no deadline is not a notification, it is an archive.
3. 3Prioritise on the five criteria, not on the severity score, and recalculate often: the CISA catalogue of actively exploited vulnerabilities took 26 new entries in August 2026 alone, so an order set quarterly is already stale by the time you read it.
4. 4Treat the perimeter separately, and first. ENISA describes the activity of state-backed groups in 2025 precisely in terms of sustained exploitation of perimeter infrastructure, and the insurer Coalition, across the claims it paid in 2024, shows 58% of ransomware claims starting from a compromised perimeter device.
5. 5When you cannot apply the fix now — and sometimes you cannot — write down what goes in its place until then: access restricted to the sources that need it, monitoring on the affected service, a date to come back to it. An acknowledged window is a different thing from a forgotten one.
6. 6Keep a record of the decisions: what was fixed, what was deferred, on what basis and by whom. It is the only thing that turns "we did not have time" into "we prioritised, and here is how".
7. 7If there is nobody you can put on this weekly, outsource the judgement, not just the tooling — a cyber security partner who also takes the decision, not one who merely delivers the scan report.

What a product that watches the server around the clock does

The class of product that fits this problem is not an antivirus and not a SIEM. It is deterministic detection running around the clock, at near-zero cost per event, plus a layer of model-based judgement called in only for what crosses a threshold — both on the customer's own infrastructure. Round-the-clock detection keeps the priority list current; the judgement layer makes it readable by somebody who is not a specialist. What a model can and cannot do in triage we discussed in the article on security alert triage.

Sentinel, our own product, is a concrete illustration of that class, and the most useful way to describe it in an article is through what it does not do. Remediation priority is computed from severity, likelihood of exploitation, presence on the CISA list of actively exploited vulnerabilities, exposure and criticality — exactly the five criteria above — and the repair plan is drafted command by command, with backups, checks and rollback steps. But it does not apply that plan on its own, at any commercial tier: at the entry tier applying fixes is explicitly excluded from the service, at the managed tier the plans drafted by the model are reviewed by us before they reach the customer, and applying one requires two explicit confirmations on the phone, with a button that dies if the plan is regenerated.

Said plainly, for any buyer: the product does not close the window for you. It makes the window visible, puts it in the right order and hands you the procedure; the decision to stop production for five minutes in order to apply a fix stays with the company. The gaps are declared too: container logs are not collected yet, there is no dedicated file integrity monitor beyond auditd, and installation on Debian is covered by tests but not yet verified on a real Debian host. The three commercial tiers are priced on request, because it depends on how many machines are involved and how much of the operating you take on yourself.

For the technical evaluator: what to ask before you sign

If you are the one who will live with the product on the server, the questions that matter are not about dashboards. And they are worth asking any vendor in this class, not only us.

• What it collects, exactly. In our case there are five source types listed publicly — sshd, sudo and su, nginx, auditd, Suricata. Ask for the list, not a number: what is not on the list is not monitored.
• How often it looks, and on what rules. Detection runs deterministically every 10 seconds, on published thresholds: SSH brute force at 15 failures in 60 seconds, web enumeration at 200 non-existent paths in 5 minutes. A threshold you are not allowed to see is a threshold you cannot tune.
• How incidents are counted. Fingerprint deduplication turns 400 attempts from one address into a single incident, not 400. Without it, the first weekend of automated scanning trains your team to ignore alerts.
• What happens to the plan the model drafts. In our case it goes through a deterministic validator that refuses it if it is not safe: the model drafts, the validator decides. The rm command is not on the list of permitted binaries, and deletion goes through a single operation limited to the backup directory.
• How log lines are handled. They are written by the attacker, so they are untrusted data: they reach the model with explicit delimiters, the transport that reads files runs in plan permission mode, and a test plants IGNORE PREVIOUS INSTRUCTIONS in an access log and verifies that nothing was executed. A successful injection changes a label, not the system.
• What happens when the product falls over. The base nftables rule is policy accept, which makes it a deny-lister, not a firewall: if the process dies or the configuration is wrong, traffic passes. A security product that stops your business through its own failure is a new problem.
• How automatic blocking is switched on. In our case it exists and is tested, but ships disabled: the first 72 hours only show what would have been blocked. Anyone who turns blocking on from day one, on a network they have not yet observed, is promising you an availability incident.

Conclusion

The window between the moment you learn you have an unpatched vulnerability and the moment you have fixed it does not close by working harder, because the remediation ceiling measures out much the same in a small company as in one of several thousand people. It closes by choosing better, weekly, out of an inventory in which only a few percent will ever be used against you — and that choice needs something watching your server at the attacker's pace, not at the pace of the quarterly report. If you want to look together at what you have exposed right now and in what order it should be fixed, let us talk for 30 minutes, with no obligation.

Sources

• DNSC — 2025 annual activity report, approved by CSAT Decision no. 117 of 7 August 2026 (dnsc.ro)
• Verizon — Data Breach Investigations Report 2026, more than a billion detection records, with analyses published by Tenable, Nucleus Security and Qualys; the 2025 edition of the same report, via the GreyNoise analysis
• Cyentia Institute — "Patching, Fast and Slow" (cyentia.com); Cyentia / Veracode — 2026 State of Software Security
• Sophos — The State of Ransomware 2026, 2,158 IT leaders, 17 countries, companies of 100-5,000 employees (sophos.com)
• IBM — Cost of a Data Breach Report 2026, research by the Ponemon Institute (ibm.com/reports)
• FIRST.org — EPSS FAQ and EPSS documentation (first.org/epss)
• VulnCheck — State of Exploitation 2026 and 1H-2026 (vulncheck.com)
• ENISA — Threat Landscape 2026, 8,257 incidents from 2025 (enisa.europa.eu)
• Coalition — Cyber Threat Index 2025, based on claims paid by the insurer (coalitioninc.com)
• Jerry Gamblin — CVE Mid-Year 2026 Check-In (jerrygamblin.com); isMalicious — KEV and EPSS analysis, August 2026 (ismalicious.com)
• CryptoITData — Sentinel, product documentation and publicly declared limits (cryptoitdata.eu/sentinel)