AI Finds Software Flaws Faster Than Banks Can Fix Them

For most of software's history, the hard part of security was finding the flaw. A skilled person had to read the code, think like an attacker and get lucky. Flaws were scarce. A bank could afford to fix them on a schedule.

That's over. Frontier AI models now find flaws by the thousand and the bottleneck has moved from finding them to fixing them. Anthropic, the company behind Claude, said so itself in May. After about 50 partners used its most capable model at the time on critical software for a month, it said the limit is no longer finding flaws. It's how quickly people can verify, disclose and patch (opens in a new tab) what the AI finds.

A few terms first. I'll use them throughout. A vulnerability (or flaw) is a mistake in software that an attacker can use. A patch is the fix the software maker releases. An exploit is a working way to use the flaw. That's all the jargon you need.

My view in one line: banking has to stop defending on a calendar and start defending continuously, using the tools modern software teams already use every day. Fintech isn't exempt either. A major chunk of my career went into banking and payment systems: I worked on State Bank of India's core banking system as an engineer at TCS, then spent five years in eBay and PayPal's architecture team working on PayPal's notifications. Today I run Zunderdog, a software company. What follows is opinion, built on the published evidence and on what those years taught me.

What Changed: Finding Flaws Got Cheap

Three things stand out in the companies' own reports.

• AI finds serious flaws at scale. Anthropic's Project Glasswing (opens in a new tab) was a programme where Anthropic and about 50 partners used an unreleased model, Claude Mythos Preview, to find flaws in critical software before attackers did. In its May update (opens in a new tab) Anthropic says the partners found more than ten thousand high or critical flaws. It had also scanned over 1,000 open-source projects (software whose code is public and which other products are built from) and reported about 530 serious flaws to their maintainers. By then 75 had been patched, a figure Anthropic calls probably an undercount.
• Disclosure and exploitation are speeding up. Google's threat intelligence team reported on 1 October (opens in a new tab) that newly disclosed flaws rose from 5,045 a month in January 2026 to 10,740 a month in August. The number seen exploited in real attacks rose from an average of 10.5 a month in 2025 to 18 a month between January and August 2026. It also found that exactly half of the flaws AI discovered were remote code execution flaws, the kind that lets a stranger run commands on your system, against 26% across what Google calls the broader CVE ecosystem.
• A patch is itself a clue. Once a fix is public, anyone can compare the old code with the new to see what changed. Anthropic's Frontier Red Team showed (opens in a new tab) its model building eight working attacks from Firefox patches in about 12 hours and says one person can now turn a month of patches into working attacks in an afternoon. That's a lab result from the company that built the model. I read it as a direction, not a forecast.

How criminals and state-backed groups actually use these tools is a separate story. I've covered it in my piece on what the AI companies' own reports show about attackers.

The Gap: Fixing Still Runs on a Calendar

Here's the other half. Verizon's 2026 Data Breach Investigations Report (opens in a new tab) studied more than 22,000 confirmed breaches. Exploiting a flaw is now the most common way a breach starts. Verizon says (opens in a new tab) it's the first time in 19 years that it has beaten stolen passwords. Fixes, meanwhile, are slow.

Please read those fairly. Verizon's 43 days is a median across all the organisations in its data, not a bank figure. Minus seven days is Mandiant's own estimate of the average. In plain words, exploitation routinely started before a fix even existed. Mandiant also says it doesn't consider 2025 the year breaches were the direct result of AI. I agree. This isn't AI inventing new attacks. It's the clock speeding up on the old ones.

Banks' rules were written for a slower clock. RBI's 2023 Master Direction on IT governance (opens in a new tab) asks for patches to be applied in a secure and timely way and for flaws to be fixed in a time-bound manner, with no fixed number of days. It asks for a vulnerability scan of critical systems and customer-facing ones in the DMZ (the network zone that faces the internet) at least every six months and again after major changes. That made sense when finding a flaw took a skilled person a long time. Set beside a model that can build an attack in hours, a six-monthly scan looks like a photograph of something that moves. That's my reading, not RBI's. RBI is plainly watching. One of its deputy governors said in a speech on 24 September (opens in a new tab) that AI works as both a tool of attack and a tool of defence. The same speech says the challenge isn't only to identify vulnerabilities but to address the material exposures in time.

Getting it wrong is expensive. IBM's 2026 India study (opens in a new tab) puts the average breach at ₹25.5 crore, up 15.9% on last year. In financial services it's ₹40.9 crore, the highest of any sector in India.

Fintech Isn't Untouched Either

It would be comforting to think this is a legacy-bank problem. It isn't.

New systems sit on the same building blocks as old ones: operating systems, web servers, databases and open-source libraries written by other people. When AI finds a flaw in one of those, every bank and fintech that uses it inherits the flaw. The PHP flaws I wrote about in PHP2Shell: what to do this week are a recent example. Both teams that reported them used AI models in the work. Calif's researcher says his own knowledge of PHP steered it.

Outside suppliers are where flaws spread. Verizon (opens in a new tab) found a third party involved in 48% of breaches, up 60% on the year before. RBI surveyed 33 commercial banks and 10 of the largest NBFCs for its June 2026 Financial Stability Report (opens in a new tab). Of those who answered, 93% depend partly or substantially on outside vendors for cybersecurity functions. The survey ranked that risk second, behind AI-enabled threats.

A fintech's advantage is speed. Many fintechs have no change board that meets once a month. Its risk is the mirror image: build fast on frameworks and libraries, ship and never look back. Speed to ship only helps if speed to fix comes with it.

To be fair to banks, the same RBI survey found 93% of respondents reporting no or low exposure to unsupported or unpatchable systems. It's self-reported and I take it at face value. My point isn't that banks run ancient software. It's that the process around the software was built for a slower world.

What SBI and PayPal Taught Me

At TCS, I learned why banks change slowly. I tuned the database behind State Bank of India's most-used transactions. When branches across the country depend on one system, every change is tested hard and released in a planned window because a mistake costs real money for real people. That discipline is right and I'd never ask a bank to drop it. But a critical security fix waiting for its slot is now a risk of its own. The answer isn't less testing. It's testing and release so automated that a security fix passes the same checks in days, not weeks.

At PayPal, I learned to verify and not to trust. I worked on notifications there, including IPN, the message PayPal sends a merchant's server when a payment goes through. PayPal's guide (opens in a new tab) tells merchants to send every message back to PayPal, which answers VERIFIED only if it matches the one it sent. The reason is easy to see: anyone who knows your server's address can post a fake "payment completed" message to it. The same habit applies to security. "We're patched" isn't a fact until someone has checked, from the outside, which version runs on which server. It applies to AI too. Its findings are leads for an engineer to check, not verdicts.

What I'd Change, in Order

I don't mean buying another dashboard. I mean what modern software teams already do daily.

1. A live inventory of what runs where. Every server, app, library and vendor product, built automatically from your code and cloud accounts and not kept in a spreadsheet. When the next PHP2Shell lands, "are we affected?" should take minutes.
2. Continuous automated testing. Tests on every change, covering the paths that move money, plus scans of your own code, libraries and running systems every day and not twice a year. This is what lets you release a fix without fear.
3. Release pipelines that can ship a fix in days. A pipeline (often called CI/CD) is the automated route from a code change, through tests, to production. Add a gradual rollout and a rehearsed rollback. Keep the change board for big changes and give security fixes a fast lane that passes the same checks.
4. AI on the defending side, with engineers checking the output. Google's Big Sleep agent found a flaw in SQLite, a widely used database engine, before it reached an official release (opens in a new tab). In July 2025 Google said its agent caught one known only to attackers (opens in a new tab). IBM's India study (opens in a new tab) found breaches cost ₹21.3 crore on average where AI and automation are used extensively, against ₹31.6 crore where they aren't used at all. Yet IBM's global study (opens in a new tab) found only 18% of organisations apply AI agents to vulnerability management. The aim is to find your own flaws before someone else's model does.
5. Vendor contracts with patch commitments. RBI's Master Direction asks banks to get written confirmation from the application's developer or vendor that it's free of known vulnerabilities and to get it again after material changes and upgrades. It also asks for the source code of critical applications or an escrow arrangement that includes fixes. That covers a moment in time. Add a number of days to ship a fix for a critical flaw, how they'll tell you, test results instead of promises. My PHP upgrade guide lists what to ask a vendor in writing.
6. Verify, don't trust. Then measure it. Track one number every month: days from "a fix exists" to "the fix is live and checked from the outside", per system. Put it in front of the board. Google's advice (opens in a new tab) is to move from patching everything in bulk to patching by what's under attack. That needs the first five in place.

Where This Leaves Banks and Fintechs

I don't think banks are careless. The people I've met in banking technology are careful to a fault. That's the point. The care was built around a calendar and the calendar is what has to change. Over the past month I've been talking to major banks about the changes that need to come and how to make them without putting the business at risk. The safe way to change is the way banks already know: small steps, well tested and easy to undo.

At Zunderdog we build and upgrade software, put tests around money paths and build the release pipelines that make a fast fix routine. Here's how we work with banks and fintechs. If you'd like to talk through how fast your team could ship a fix today, book a 30-minute call with me or tell us what you run. And if you work in a bank or fintech and have seen this from the inside, I'd like to compare notes.

Quick Answers

Is AI really finding flaws faster than banks can fix them? In open-source software Anthropic says as much: by May it had reported about 530 serious flaws and knew of 75 fixed. I haven't found a published bank figure. Across industries, Verizon's data shows a median of 43 days to fix the worst flaws and Mandiant estimates that attacks now start before a fix exists. The direction is clear even where the numbers aren't bank-specific.

Is AI already causing bank breaches? I can't show that and Mandiant says 2025 wasn't the year breaches were the direct result of AI. Most intrusions still came from basic failures. AI shortens the time between a flaw becoming known and being used.

What should a bank do first? Build a live inventory and measure how many days it takes to get a critical fix live. Those two numbers show how far you are from defending continuously.

Are fintechs safer because they're newer? Not by default. They build on the same open-source parts and lean on vendors. Their edge is how fast they can release, which only helps with tests and a pipeline behind it.

Sources

• Anthropic: Project Glasswing (opens in a new tab), its May 2026 update (opens in a new tab) and research on turning patches into exploits (opens in a new tab)
• Google Threat Intelligence Group: vulnerability discovery and exploitation trends in the AI era (opens in a new tab)
• Google Cloud: M-Trends 2026 (opens in a new tab)
• Google: Project Zero on Big Sleep (opens in a new tab) and Google's 2025 security update (opens in a new tab)
• Verizon: 2026 Data Breach Investigations Report, executive summary (opens in a new tab) and news release (opens in a new tab)
• IBM: Cost of a Data Breach Report 2026, India (opens in a new tab) and global findings on AI (opens in a new tab)
• RBI: Master Direction on IT governance, risk, controls and assurance practices (opens in a new tab) and Financial Stability Report, June 2026 (opens in a new tab)
• BIS: speech by an RBI deputy governor, 24 September 2026 (opens in a new tab)
• PayPal: IPN implementation guide (opens in a new tab)