Old Vulnerabilities Still Pay the Bills for Attackers

The industry likes novel exploits. Attackers like working ones.

Every year, incident reports confirm that a substantial portion of successful compromises start with vulnerabilities that were not new. Not zero-days. Not nation-state tradecraft. Old CVEs, unpatched appliances, forgotten web applications, and services that have been answering the internet for longer than anyone on the current team can explain.

The Cyber Centre ranks patching operating systems and applications among its top recommended security actions, not because it is interesting advice, but because the gap between disclosed and patched remains one of the most reliable things attackers can count on. That gap does not only exist in underfunded organizations. It exists in organizations with mature programs that simply never built urgency into their remediation cycle for lower-profile assets.

Why old risk persists

Most organizations know they have legacy exposure. The useful question is why it stays. Sometimes the vendor stopped supporting the product and a replacement is caught in budget approval. Sometimes the system supports a production process that broke the last time someone touched it, and nobody wants to be the person who broke it again. Sometimes the asset owner left and the system became institutional furniture. Sometimes it is simply that the ticket never got prioritized above the backlog of other things.

Attackers do not need those explanations. They only need the service to answer.

Old file transfer tools, legacy VPN clients, aging content management systems, printer management portals, and first-generation remote monitoring appliances all carry CVEs with published exploits, often years old, often with CVSS scores that looked manageable at the time they were deferred. The inventory usually tells a less flattering story than the strategy deck.

Legacy is not a synonym for accepted risk

There are legitimate operational constraints behind many unpatched systems. Manufacturing environments, public-sector applications, embedded systems, clinical software, and regulated workflows can all create real upgrade barriers. The mistake is letting those constraints dissolve into permanent ambiguity with no documentation, no owner, and no defined compensating controls.

If a system cannot be patched, that should be a visible decision. Is it isolated from adjacent networks? Is access restricted to what is actually necessary? Is monitoring in place and someone reviewing it? Is there a named owner accountable for the risk? Is there a retirement or migration date in someone’s planning cycle? Has leadership accepted the exposure formally, or has everyone quietly learned not to bring it up?

Known risk becomes tolerated risk when nobody has to explain it out loud. Tolerated risk becomes incident risk when an attacker’s scanner finds the service before the organization’s next vulnerability review does.

Healthcare environments carry a specific version of this problem. A medical device or clinical application may be tied to vendor certification cycles that run years behind the vulnerability disclosure calendar. Patching is not always possible on any reasonable timeline. In those cases, the control question shifts entirely: the device should not be reachable from general network segments, access should require specific authentication, and the monitoring coverage should be tighter than average, not lighter because the system “can’t be touched.” Legacy clinical systems sitting on flat networks with limited monitoring are not a technical limitation. They are a governance failure dressed up as one.

Prioritization has to survive real operating conditions

For smaller organizations, the first pass through legacy risk does not require a sophisticated program. It requires an honest inventory of what is exposed to the internet, what has privileged reach into the rest of the environment, and what has not been patched or reviewed in the past twelve months. Patching those assets before working inward on lower-priority internal systems is not a radical approach. It is the Cyber Centre’s own recommended sequence, and it is right.

For larger organizations with formal vulnerability management programs, the issue is usually not missing the findings. It is that the remediation process treats all findings with similar urgency regardless of exposure context. If the only prioritization variable is severity score, the program is missing the point. An old CVE on a publicly exposed appliance with a published exploit warrants faster treatment than a newer, higher-scored finding on an isolated internal development server. That distinction should be built into the process, not left to individual judgment on a case-by-case basis.

The governance answer is boring and necessary

Legacy vulnerability reduction is rarely solved by one heroic maintenance weekend. It is solved through ownership assignment, exception review processes with real expiry dates, budget discipline that accounts for technical debt, network segmentation that limits the blast radius of systems that cannot be updated, and the organizational willingness to retire systems that have become operationally convenient but strategically indefensible.

None of that is technically complicated. All of it requires someone to have the authority and organizational support to make it happen over time, which is exactly why it stays undone in organizations where security functions as a reporting layer rather than an operational one.

Attackers do not care whether a vulnerability is old. If it still works, it is current. The age of the CVE is irrelevant to the investigation that follows a successful compromise.

Sources and further reading

• Canadian Centre for Cyber Security: Patch operating systems and applications
• Government of Canada: Guideline on Vulnerability Management

How Arancia Can Help

Legacy exposure does not require a complex program to start reducing it.

Arancia helps organizations build an honest picture of their legacy risk, establish ownership, and design remediation and compensating control strategies that work within real operational constraints.

• Legacy exposure assessment covering internet-facing, privileged, and end-of-life systems
• Asset ownership assignment and accountability framework design
• Compensating control strategy for systems that cannot be patched immediately
• Exception and risk acceptance process design with defined expiry and review cycles
• Network segmentation review to limit legacy system blast radius

Arancia helps organizations turn documented legacy risk into managed legacy risk. Get in touch.