Known Flaws Stay Open for Years. What Nobody Writes Down Is What the Fix Would Break.

The monthly security review reaches item nine. It is a fix for the software underneath the customer self-service portal.

The fix was published three years ago. It has been deferred fourteen times. The reason in the minutes is the same each time: may affect the portal.

The head of security asks what, exactly, it would affect. The head of IT remembers that the last time anything under the portal was updated, bill downloads stopped for two days, and nobody found out why until a former developer was telephoned. Neither of them can say more.

What We Found

For this article we went through the public record on known security flaws that stay unfixed: two news reports of one wave of attacks on network devices, the US government’s list of flaws known to be used in attacks, published support dates of common software, and one survey of IT professionals.

Five findings stand out.

Old, known flaws stay usable for years. Around the turn of 2025, according to a security news report citing threat researchers, an attack group targeted more than a thousand of one maker’s network devices, in many countries. Separately, describing the same group’s campaign against telecom networks, the maker’s own researchers found that it got in mainly with valid login credentials. In at least one incident it used a flaw whose fix had been published years earlier; a second news report added that old systems left unfixed remain at risk. The maker said no new flaws in its products were found. Network devices, the routers and switches that carry traffic, are not our kind of work, and login credentials, not missing fixes, were the main way in. We use the case for one narrow point: a flaw fixed years earlier was still usable. We did not examine why that fix had not been applied, and we draw no cause from it.

The list of flaws known to be used in attacks holds old ones. The US government keeps such a list. On 8 October 2026 it held 1,739 entries. Apache Struts, an old web framework that many business applications were built on, has 9 flaws on it. Three entries are flaws in the web language PHP itself, and flaws in it dating from 2012 and 2019 were added to the list in March 2022. These figures are not about telecom, and the counts change.

The software underneath has published end dates. For Java 8, an older version of a widely used programming language, standard support in one maker’s edition ended on 31 March 2022, with paid extended support until 31 December 2030. For Windows Server 2012 and 2012 R2, extended support ended on 10 October 2023, and paid security updates ended on 13 October 2026. For SQL Server 2016, extended support ended on 14 July 2026, and paid security updates run to July 2029. One line of Apache Struts, 2.5, reached end of life on 30 April 2024; newer lines are still supported. These dates are not about telecom.

IT professionals name the worry. In one survey of about 500 IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, more than four in ten named security weaknesses among the top challenges of old systems.

Nobody in the public record writes down why a fix waits. We found no public account, from any operator, of what an overdue fix on its own applications would have broken.

Our reading is that fixes on an operator’s own applications rarely wait because anyone is careless. They wait because an application leans on the framework, libraries and database beneath it in ways nobody wrote down. So “may affect service” is accepted, quarter after quarter, since nobody can show that it is wrong.

What Waits While Nobody Knows What a Fix Would Break

The first cost is the list that only grows. Each quarter more fixes join it, with the same note, and none leaves.

The second is the risk acceptance with no reason in it. The form says “possible impact on service”. It does not say what impact, who looked, or what would have to change.

The third is the application whose software gets no more fixes, listed beside fixes that could go in tomorrow. All say “deferred”; only some are waiting for something that will come.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Deal With Security Fixes That Keep Waiting, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Defer the fixes again	The fix is minor, or the application is about to be switched off	The list grows, the reasons are forgotten, and each application stays exactly as exposed
Apply the fixes and hope	A small application your team knows well, with a simple way back	Something customers use stops working, nobody knows why, and the next fix waits longer
Record what each fix would touch and break, then let your own team apply it	Many fixes carry “may affect service” and nobody can say what that means	It costs money before any fix is applied; nothing is safer until your team applies the fixes; your team still checks each fix
Rebuild the application that cannot take fixes	Part of the estate stands on software with no supported version left	It costs the most and takes months; the old application is exactly as exposed until the last module has moved

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own applications, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Own applications listed with what they stand on	Known by memory	Every application listed with its framework, libraries, database, versions and published support dates	The map of the applications as they stand
Overdue fixes marked with a reason	”Deferred: may affect service”	Each fix on your security team’s list marked by that team: can go in now, blocked by something named, or cannot be applied, with the reason	The risk register
What each fix would touch	Not known; the last bad weekend is remembered	The screens, jobs and reports that use the part being fixed, named for each fix	The specification
Applications on software that gets no more fixes	Not counted	Counted, each with a plan, and falling as rebuilt modules are accepted	The risk register, reviewed at each stage

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a telecom operator.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the security fixes that keep waiting on your own applications. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications your firm built or had built, and the assessment records what each one stands on (framework, libraries, database, versions and support dates) and what a fix underneath would touch or break, for each overdue fix on your security team’s list, so that team can mark it. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means only an application whose underlying software gets no more fixes, rebuilt module by module beside the old one. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This approach has limits. We do not apply security fixes; your own team does, and checks each one. We do not scan or monitor your systems, and we do not tell you which flaws you have; your security team’s list is where we start. We do not work on network devices or the systems that run the network, or deal with login credentials. We do not upgrade software in place, or work inside a packaged billing product. Until your team applies a fix, or the last module of a rebuild has moved, an application is exactly as exposed as before. Reading code may not find everything an application needs. We promise no protection from attack. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a telecom operator.

What changes for the business:

Role	What they gain
CEO	An overdue fix stops being a line marked “deferred” and becomes a decision with a reason and a date.
CTO or CIO	For each of the firm’s own applications, a written list of what it stands on and what a fix underneath would touch. “It may break something” becomes “it would break this”.
CFO	The cost of ending each exception can be set beside the cost of carrying it, application by application.
CISO	The list can be sorted: fixes that can go in now, fixes blocked by something named, and applications that cannot take fixes at all.
Head of regulatory affairs	Each deferred fix has a recorded reason and an owner, and not only a risk acceptance renewed every quarter.

None of these means an application cannot be attacked.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
Around the turn of 2025 an attack group targeted more than a thousand of one maker’s network devices. It got in mainly with valid login credentials, and in at least one incident used a flaw whose fix had been published years earlier.	Our part is far narrower: we do not work on network devices, deal with login credentials, scan for flaws or apply fixes, and we do not say what went wrong. For applications an operator built, we record what each stands on and what a fix would touch, so the operator’s own team can decide on each fix and apply it.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by writing a reason beside every fix that waits, because “may affect service” is the one line nobody has checked.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →