Known Fixes, Still Waiting

1. At a Glance

Issue study · From the public record. None of the organisations behind the events described here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.

Organisation type	Telecom operators whose own applications (customer portals, activation tools, dealer portals, reports) stand on frameworks, libraries and databases made by others, each with its own fixes and end date
Size band	The case in the record: an unnamed wave against network devices in many countries. Our reader: a regional internet or broadband provider, a cable operator, a provider of connectivity to businesses, a virtual mobile operator, or another mid-size operator
Region	The case: devices in many countries. The rules: India
The decision at stake	Whether to defer the overdue fixes on the operator’s own applications for another quarter, apply them and hope, or first find out what each fix would touch and which applications can no longer take fixes at all
The public outcome	Around the turn of 2025 an attack group targeted more than a thousand of one maker’s network devices. Describing the same group’s wider campaign, the maker’s researchers found it got in mainly with valid login credentials; a second news report says that in at least one incident it used a flaw whose fix had been published years earlier
Why it matters to a mid-size operator	A flaw does not stop being usable because its fix is old. And India’s Telecommunications (Telecom Cyber Security) Rules, 2024, of 21 November 2024, provide for a report “within six hours of becoming aware of a security incident affecting its telecommunication network or telecommunication service”, with the users affected and the remedial measures “taken or proposed to be taken”

2. The Business Problem, in the Buyer’s Words

“Every month the security report has the same list. Sixty-odd fixes overdue on our own applications, and beside nearly all of them the same note: may affect service. My head of IT is not wrong, and my head of security is not wrong either. Nobody can tell me which of those fixes would really break something, and which were simply never scheduled. And there is one line I dread: the dealer portal, where the report says no remediation is available, because the framework under it is past its end date. I want to know what we are choosing between, before someone asks me why.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The operator is caught between fixes it is afraid to apply and one application it cannot fix at all.

3. What We Found

Method. 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, one survey of IT professionals, and the rules operators in India now work under on security incidents.

One public case. These are the record’s own words. No operator is named in this study, and none was an IOanyT client.

What	What the public record says
The wave	Around the turn of 2025 an attack group targeted more than a thousand of one maker’s network devices, in many countries (a security news report, citing threat researchers)
How the group got in	Describing the group’s wider campaign, the maker’s researchers found it got in mainly with valid login credentials
An old flaw	Describing the group’s wider campaign, the maker’s researchers found that 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
New flaws	The maker said no new flaws in its products were found
Why that fix had not been applied	We did not examine why, and draw no cause from it

Network devices, the routers and switches that carry traffic, are not IOanyT’s 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.

Old flaws stay on the list. These figures are not about telecom. The US government keeps a list of flaws known to be used in attacks. 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. The counts change.

Support ends on a published date. These dates are not about telecom, and which of these products operators run was not researched.

Software	Published support dates
Java 8 (one maker’s edition)	Standard support ended 31 March 2022; paid extended support until 31 December 2030
Windows Server 2012 and 2012 R2	Extended support ended 10 October 2023; paid security updates ended on 13 October 2026
SQL Server 2016	Extended support ended 14 July 2026; paid security updates run to July 2029
Apache Struts 2.5	End of life 30 April 2024; newer lines of the framework are still supported

The worry, and why old systems stay. In one survey of about 500 IT professionals in the US, across industries and company sizes, run by a vendor and not about telecom, more than four in ten named security weaknesses among the top challenges of their old systems, and half said that their current system still works was a reason for not modernising.

What Indian operators now work under. The Telecommunications (Telecom Cyber Security) Rules, 2024 (G.S.R. 720(E), 21 November 2024) came into force on publication; an amendment of 22 October 2025 left the rules on the security officer and on reporting unchanged. Under rule 4(4)(a) a telecommunication entity is to “adopt a telecom cyber security policy”, and rule 6(1) reads “Every telecommunication entity shall appoint a Chief Telecommunication Security Officer”. Rule 7 provides that it report “within six hours of becoming aware of a security incident affecting its telecommunication network or telecommunication service”, and “within twenty-four hours of becoming aware of such incident” furnish, as applicable, “the number of users affected by the security incident”, “the duration of the security incident”, “the geographical area affected by the security incident” and “the remedial measures taken or proposed to be taken”. A telecommunication entity is “any person providing telecommunication services, or establishing, operating, maintaining, or expanding telecommunication network”, including authorised entities and persons exempted from authorisation; the rules set no size threshold. The rules do not name an old application, and whether an incident in a billing, customer or portal application falls under them is for an operator’s own advisers. The link to old applications is our reading.

Our reading of why fixes wait on an operator’s own applications. These three are our reasoning from the record above. None is a finding of any source, and none is offered as the explanation of the case.

1. Nobody knows what a fix would break. An application leans on features of the framework, libraries and database beneath it, and nobody recorded which.
2. So checking is done by hand, or not at all. With no record of what a fix touches, a team checks every screen, or checks nothing and hopes. Either way each fix is expensive, and fixes are saved up.
3. Some applications cannot be fixed at all. The software under them is past its end date, the newer version is a rewrite, and the replacement is priced as one large project and put off.

Illustration, not a real case. A regional broadband provider’s self-service portal was built nine years ago on a web framework. A fix for that framework was published three years ago. The portal’s bill download uses one feature the fix changes. Nobody knows this; they remember only that an earlier update stopped bill downloads for two days. So the fix is deferred each quarter with the note “may affect service”.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Defer the fixes again	The fix is minor, or the application is about to be switched off	The list grows, and each application stays exactly as exposed	Right for a named few, each with a written reason
Apply the fixes and hope	A small application the team knows well, with a simple way back	Something customers use stops working, and nobody knows which fix did it	Right where the team knows the application; a gamble elsewhere
Record what each fix would touch and break, then let the operator’s own team apply and check it	Many fixes carry “may affect service”, and nobody can say what that means	Costs money before any fix is applied; nothing is safer until the team applies the fixes; reading code may miss something	Our recommendation
Rebuild the application that cannot take fixes, one module at a time	Part of the estate stands on software with no supported version left, and an upgrade would be a rewrite	Costs the most and takes months; the old application is exactly as exposed until the last module has moved	Our recommendation for that part only, once upgrade and paid support have been weighed

5. Our Recommendation, and the Decision It Asks of the Board

Record, for each of the operator’s own applications, what it stands on (framework, libraries, database, versions and support dates) and what a fix underneath would touch or break, so that the operator’s security team can mark each overdue fix: it can go in now, it is blocked by something named, or it cannot be applied. The operator’s own team then applies the fixes, checking what the record names for each. A fix for a flaw already known to be used in attacks may not be able to wait for this; that call is the operator’s security team’s, as is each mark. Where an application stands on software that gets no more fixes, weigh upgrade, paid support and rebuild; where only a rebuild fits, rebuild it one module at a time, while the operator’s own team keeps the old one running and guarded. IOanyT applies no fix, runs no scan or monitoring, and does not work on network devices.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Own applications listed with what they stand on and its support dates	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 marked by the security 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 screens, jobs and reports that use the part being fixed, named for each fix	The specification
What was checked after each fix	A ticket that says “applied”	The operator’s team’s own note of what it checked against the named list	The firm’s own change records
Applications on software that gets no more fixes	Not counted	Counted, each with our recommendation and a written decision (upgrade, paid support until a date, or rebuild), and falling as rebuilt modules are accepted	The risk register and the staged plan
Old functions matched to new ones, where rebuilt	Not recorded	Each function linked to its replacement	The traceability matrix

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the fixes that keep waiting on your own applications, and the one that cannot take fixes at all. 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 study 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.
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. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: what each of the operator’s own applications stands on, with versions and published support dates, and what a fix underneath would touch, confirmed by the operator’s own people.
• The risk register: what each overdue fix would touch or break, and the options, with our recommendation, for each application on software that gets no more fixes, listed before any price is set.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement.
• The code: the rebuilt modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT does not apply security fixes. The operator’s own team does, and checks each one. Until it does, or until the last module of a rebuild has moved, an application is exactly as exposed as before.
• IOanyT runs no scanning or monitoring service, and does not tell an operator which flaws it has. The security team’s list is the starting point.
• IOanyT does not work on network devices or the systems that run a network, which is what the one public case concerns, and it does not deal with login credentials.
• IOanyT does not upgrade an operating system, a database, a framework or a language version in place, and does not keep or guard an old application while it is rebuilt.
• IOanyT does not work inside a packaged billing product, whose fixes come from its maker.
• Reading code may not find everything an application needs from the software beneath it.
• A rebuilt application needs fixes of its own, applied by the operator’s team, for as long as it lives. It is fixable, which is not the same as fixed.
• IOanyT promises no protection from attack.
• IOanyT gives no legal or regulatory advice. What the Telecom Cyber Security Rules ask of a particular operator is for its own advisers; this study does not say, or say that any work makes an operator compliant.
• This study does not say that IOanyT has done this work for a telecom operator. IOanyT has no published case of it.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
A security news report, February 2025	The wave around the turn of 2025: devices targeted
A second security news report, February 2025	Valid login credentials; the flaw whose fix had been published years earlier; the maker’s statement on new flaws
The US government’s list of flaws known to be used in attacks	Entry counts, Apache Struts and PHP entries
endoflife.date: Apache Struts, Java, Windows Server; SQL Server 2016 lifecycle	Support dates
A vendor’s survey of about 500 US IT professionals, 2025	Challenges of old systems, and why they stay
Telecommunications (Telecom Cyber Security) Rules, 2024, gazette copy	Who must act, the security officer, and incident reporting

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, so that your own team can apply the ones that can go in, and the board can see a date for the ones that cannot.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →