“It still runs” no longer means “it’s still safe.” Here is why AI-driven exploit discovery is turning decades of unpatched technical debt, legacy frameworks, and hidden API flaws into an immediate target list.
This topic has been nagging at me for months, because it sits right on the seam between the two hats I wear: sysprog and security. Technical debt is one of those phrases that everybody nods along to without ever really agreeing on what it means.
What is technical debt from a sysprogs perspective
Technical debt is all the “we’ll fix it later” stuff we’ve been carrying for decades, like:
- The workaround that became permanent.
- The library nobody has updated because it works and touching it feels like waking a sleeping dog.
- The undocumented exit that only one person understood, and that person retired in 2009.
On the mainframe we’re especially good at this, because our stuff does keep working. That’s the whole selling point.
But “it still runs” and “it’s still safe” are not the same sentence, and I think a lot of us have quietly let them blur together.
The words, ”It still runs” and “It’s still safe” are not the same sentence.
What made me finally sit down and write this? Anthropic’s Mythos.
What is Mythos?
For anyone who has been off-grid this year, Mythos is one of Anthropic’s AI models, and the thing that matters for us is what it does with code. It reads source code or analyses binary objects, ranks the ones most likely to contain a flaw, forms a hypothesis about how that flaw could be exploited, and then writes a working proof-of-concept to prove it was right.
Not a signature match against a known-CVE list. Actual reasoning about code it has never seen before.
The numbers we’re hearing are the part that made me put my coffee down.
Project Glasswing testing found a 17-year-old remote-code-execution bug in the FreeBSD NFS server, and a 16-year-old flaw in FFmpeg’s H.264 codec, both of which had been sitting under the noses of human reviewers and automated scanners for over a decade.
Anthropic’s write-up mentions one vulnerability that had survived for 27 years. Give it a CVE number and a Git commit hash, and it’ll produce a full, working exploit in hours for very little money.
Access is restricted for now to a short list of organisations including Microsoft, Google, and the Linux Foundation. But the people watching this closely reckon it’s 12-18 months before equivalent capability turns up in open-source models that anyone can run on their own kit.
I predict that by the end of 2026, Mythos-level ability will be in the hands of any attacker.
To put it bluntly, we have to prepare for the fact that by the end of the year (and yes, I mean 2026), Mythos-level ability will be in the hands of any attacker. I have no way to be certain about that prediction, but sometimes your gut feeling is just right.
Don't miss these other great articles
A technical debt problem — not just an AI problem
Here’s the bit I want systems programmers to sit with.
For years, the comfort blanket around old code has been obscurity. The effort to understand a crusty bit of Assembler or a forgotten C library was high enough that attackers went looking for softer targets.
The comfort blanket around old code has been obscurity. Mythos removes that.
The thinking was, “Nobody understands this module anymore; therefore, nobody can attack it.” That was never really true, but it was true enough.
Mythos removes that blanket.
The scale of concern
The age of the code is no longer protection. If anything, it’s the opposite, because old code was written before we understood the mistakes we now know to avoid, and it hasn’t had a fresh pair of eyes on it in a generation.
And technical debt is exactly where the old code lives:
- Every end-of-life framework you’re still running is permanent, unpatchable exposure.
- VB6’s runtime went end-of-life in 2008.
- AngularJS 1.x in 2021, and three high-severity CVEs were disclosed against it in 2025 that will never be fixed, because there is nobody left to fix them.
- Bits of the old .NET Framework are in the same boat.
These aren’t obscure edge cases; they’re sitting in production estates all over the place, quietly, because ripping them out was always next year’s project.
The scale is also worth a mention. The Common Vulnerabilities and Exposures (CVE) disclosures forecast for 2026-2027 is somewhere around 66,000 CVEs, about 46% above what the trend line said it should be. AI-assisted discovery is the reason for the jump.
That’s not attackers getting smarter. That’s the cost of finding a bug collapsing towards zero.
The Mainframe Angle
(you knew I’d get to it)
I’ve spent a lot of my career telling people that “inherent mainframe security” is a phrase that should make them nervous, not comfortable. The platform is genuinely well-designed. But it is not magic.
And the way modern attacks reach, it is rarely a frontal assault on z/OS. It’s the connections. The API sitting between a distributed front-end and the mainframe with authentication that was “temporary” in 2016. The service account with far more authority than it needs. The trusted link that lets something hop sideways from a soft distributed box onto the platform we all assumed was the safe one.
Every one of those is technical debt. And every one of them is exactly the sort of thing a tireless code-reader is good at spotting. The expired certificate nobody renewed, the privileged session nobody monitors, the access control that was misconfigured on a Friday afternoon years ago: these have always been the real gaps.
The difference now is the speed at which someone can find them.
Stop treating your dependency and software inventory as a compliance chore and start treating it as a target list.
My recommendation is to stop treating your dependency and software inventory as a compliance chore and start treating it as a target list, because that’s what it is to the other side. You want to be the one who reads it first.
What I’d actually do about it
None of this is a counsel of despair. The honest truth is that the fixes are the boring ones we already knew about; we’ve just run out of excuses to keep deferring them. Here’s where we start:
- Know what you’re running, down to the versions and the libraries, because you can’t defend an estate you can’t list.
- Treat unsupported software as a control failure, not a footnote; NIST 800-53, PCI-DSS v4.0, and the HIPAA Security Rule already do, so you may as well get there first.
- Look hardest at the joins (the APIs, the service accounts, the trusted connections into the platform), rather than the platform itself.
- Pick off the oldest, most-deferred debt now, while the people who understand it are still contactable.
The interest on technical debt was always going to be paid eventually. Mythos just moved the due date forward.
Reading the article left me with two very different reactions.
I believe its core message is both valid and important: AI will significantly accelerate the search for vulnerabilities. That will affect mainframe environments as well. But the first impact will probably not be on the mainframe platform itself. It will be on the applications, interfaces, and operational models that have grown around it over decades.
In the mainframe world, the statement “It has been running reliably for 30 years” is still heard far too often. But reliability is not the same as security. Older COBOL, PL/I, or assembler applications may perform their business functions flawlessly while still containing assumptions that are problematic by today’s standards: missing or incomplete authorization checks, hard-coded credentials, shared user IDs, overprivileged service accounts, or interfaces whose security model has never been fundamentally reviewed.
Then there are the connections to distributed systems. APIs, web applications, middleware, file transfers, database access, and service accounts now connect the mainframe to a wide range of other platforms. In many cases, the real risk is not located in z/OS, CICS, IMS, or Db2 themselves, but at those points of integration. A highly secure core platform only provides limited protection if upstream applications can access it with broad privileges.
This is where the article makes an important point: the assumed protection provided by complexity and obscurity is losing its value. AI-assisted tools can analyze source code, data flows, dependencies, and recurring vulnerability patterns much faster. That could also become highly relevant for mainframe applications, especially when COBOL source code, copybooks, JCL, interface definitions, and documentation are analyzed together.
At the same time, I find the article too alarmist in several areas.
The capabilities described are transferred almost automatically to mainframe code without offering concrete evidence. Analyzing a widely used open-source project is not the same as assessing a CICS or IMS application that has evolved over several decades. Mainframe applications have their own runtime models, data formats, transaction concepts, security mechanisms, and operational dependencies. Without that context, even a powerful AI system will remain limited.
I also believe that equating age with insecurity is too simplistic. A 30-year-old COBOL program may have a clearly defined scope, extensive testing, and exposure limited to a tightly controlled environment. At the same time, a modern API can become a serious security risk within months if authorization and access controls are poorly implemented.
Age is therefore an indicator, not proof of insecurity.
I take a similar view of the article’s broad equation of end-of-life software with immediate exploitability. Unsupported components are unquestionably a serious risk. But actual risk still depends on accessibility, privileges, data flows, existing controls, and the specific operating context. Mainframe environments in particular often include multiple technical and organizational layers of security that need to be considered in any realistic assessment.
I also find it problematic that the article groups very different issues together under the label of “technical debt.” Outdated application code, missing documentation, weak authorization models, unmonitored service accounts, and inadequate operational processes may be related, but they are not the same problem. They need to be analyzed separately and addressed with different measures.
My conclusion: as a wake-up call for mainframe leaders, the article works very well. It rightly reminds us that a secure platform does not automatically mean secure applications and interfaces.
As a rigorous mainframe risk assessment, however, I find it too broad and insufficiently nuanced. The real task is not to declare old code a security problem by default. The real task is to create transparency across long-standing applications, permissions, data flows, and interfaces.
That is exactly where AI could make a significant contribution in the future.
Mark, I like where you’re going with this article.
I’d add that this is an architectural problem as well as a security problem.
Over the years I’ve been dropped into more than a few environments where there was nothing to read, no one left to ask, and a production system everyone was afraid to touch. At that point they’re no longer paying interest on technical debt. The entire bill is sitting on the desk stamped “Payment Overdue.”
One of the largest modernization efforts I worked involved more than 40 systems and well over 100 integration points. Before we could design anything new, we had to become archaeologists. We spent months discovering what actually existed because the documentation reflected the system people remembered, not the one that had evolved over decades.
I’ve seen the same thing at the infrastructure level. Undocumented RACF decisions, forgotten exits, batch service accounts with a history no one could explain, APIs that quietly became part of the business because they worked. None of those started as bad decisions. Most were perfectly reasonable responses to the pressures of the day. They simply accumulated faster than anyone had time to revisit them.
AI changes the economics. The cost of understanding old systems has always been the limiting factor. As that cost now approaches zero, every hidden dependency, forgotten interface, and undocumented assumption becomes easier to discover.
For decades, technical debt has forced organizations to keep paying the “ecosystem tax” of rediscovering their own systems. Reducing technical debt is far more than just a maintenance issue. It’s necessary to reduce risks when making changes to critical production systems. It’s also imperative to shrink potential attack surfaces. Tools attackers use get better every day, which lowers the barrier to entry for would-be cybercriminals.
It’s a backlog of organizational knowledge that was never captured. Paying it down is about reducing risk and preserving enough understanding that the next generation can safely change the system instead of being forced to tiptoe around it.
I suspect that’s going to become one of the defining architectural challenges of the next decade.