When AI made flaws cheap to find, banks’ patch queues set the pace

The week

On April 7, 2026, Anthropic announced Claude Mythos Preview, a model it said could find and exploit serious vulnerabilities in widely used software, including every major operating system and web browser. A vulnerability is a flaw an attacker can use to break in, steal data or take control. An operating system is the foundation software a computer runs on, such as Windows or Linux; a browser is the program people use to reach the web. To “exploit” a vulnerability is to actually use it to break in, which goes a step beyond spotting it.

Every piece of software has mistakes in it, and most are harmless. Finding the dangerous ones has always been slow, skilled work, which is part of what has kept the number of serious attacks in check. The announcement publicly challenged that assumption.

Anthropic did not release the model generally. Access went through an initiative called Project Glasswing. It covered a small group of launch partners, among them large technology firms, the Linux Foundation and JPMorganChase, and more than 40 further organizations that maintain critical software. The idea was to let defenders find and fix flaws before anyone else could. The company pledged up to $100 million in usage credits and $4 million for open-source security groups, the often small, volunteer-heavy organizations that look after free software used across the economy.

The same day, Bloomberg later reported, citing people familiar with the matter, Treasury Secretary Scott Bessent and Federal Reserve Chair Jerome Powell met chief executives of systemically important U.S. banks at Treasury to make sure they understood the cyber risks such models posed. “Systemically important” banks are the ones large and interconnected enough that their failure could damage the wider financial system. Neither agency gave public details.

For a bank chief executive, the week raised an obvious issue: what changes when finding flaws in software becomes much cheaper. For nearly every bank, the answer turned out to be less about the model and more about plumbing: how fast the bank can install fixes once someone else finds the problem.

The capability claims came from the developer and could not be independently tested by most of the industry, because most of the industry could not use the model. That asymmetry is the useful starting point. A handful of technology companies, open-source foundations and one large bank could run the model against code. Almost every other bank could not.

For them, cheaper discovery would arrive second-hand: as advisories, vendor patches and open-source releases, in larger volume and at shorter notice than their processes were built for. A building inspector who suddenly works ten times faster creates work for the repair crew, and the repair crew is where most banks are short.

So the question for a bank was less what the model could find and more how quickly the bank could absorb fixes. That depends on who owns the code. We separate it into three parts, which together cover a bank’s software estate: code the bank writes, code it buys, and open-source code it uses but nobody inside owns. First, some definitions.

Vulnerabilities, patches and the window between them

A vulnerability is a flaw in software that lets someone do something they should not: read data, move money, shut a system down. A patch is the fix, a change to the software that closes the flaw. Between the moment a vulnerability becomes known and the moment the patch is installed, the organization is exposed. Security teams call that gap the window of exposure, and much of their job is keeping it short.

Several other terms come up repeatedly:

• An advisory is a public notice that a flaw exists, usually with a severity rating and instructions.
• Open-source software is code published freely for anyone to use and modify, maintained by communities and foundations rather than a single vendor. It is everywhere: inside banking apps, websites and the products banks buy.
• A dependency is a ready-made component that a piece of software relies on.
• A software bill of materials, or SBOM, is an ingredients list for an application: every component inside it, and which version.

Historically, finding serious flaws required scarce human expertise, so they surfaced at a pace organizations could, more or less, keep up with. If AI tools make discovery much cheaper, the flow of advisories and patches rises. Nothing about the bank’s ability to install those patches changes automatically, and the risk lies in that mismatch.

How a fix travels through a bank

Follow a single fix from the moment it exists to the moment it protects anyone. The journey has more steps than most executives expect, and every step has an owner, a queue and a reason to wait.

First, someone has to learn that the fix exists. For vendor software that may be an email or a portal notice; for open-source components it may be a public advisory that nobody at the bank is formally watching. Second, the security team has to work out whether the bank is affected at all, which depends on knowing what software runs where. Third, someone has to judge how urgent it is: whether the affected system is reachable from the internet, and whether it holds customer data or moves money.

Fourth, the fix has to be tested, because a patch that closes a security hole but breaks the overnight batch run that posts interest to accounts is its own kind of incident. Fifth, it has to be approved through change management. Sixth, it has to be deployed, often in a maintenance window at night or on a weekend. Finally, someone should confirm it actually worked.

In a well-run bank, each of those steps is quick for the most critical systems. In a typical bank, several of them depend on one or two experienced people, a spreadsheet and goodwill. That arrangement copes with a steady trickle of fixes and fails under a flood, and a flood is precisely what cheaper discovery implies.

The process behaves like a production line: adding more inspectors at the front does not speed up a line whose bottleneck is at the back. The three parts of the software estate below are, in effect, three different production lines, each with its own bottleneck.

Code the bank writes

For internally developed applications, the bank controls both the finding and the fix. Discovery tools of this class, where a bank can get them, shorten the first step. They do nothing for the second. A fix still needs a developer who understands the application, a test cycle and a release through change management.

Most large banks govern releases through change advisory boards built for stability, with freeze windows around month-end and quarter-end. A change advisory board is a committee that reviews and approves changes to important systems before they go live; a freeze window is a period, often around financial reporting dates, when changes are not allowed at all. Both exist for good reasons. Banks have learned the hard way that a careless change can take down payments or statements.

Those processes were designed for a world where urgent security releases were occasional. If they become routine, the bank needs a defined fast lane. That means automated regression testing good enough that a change board will approve a security release in days. Regression testing is checking that a change has not broken anything that used to work; automated, it can run in hours rather than weeks. A fast lane also means criteria for when a fix may bypass the normal calendar, and a named executive who can accept the residual risk of shipping quickly.

It also means engineering capacity. Remediation competes with product work for the same developers, and the trade-off should be explicit in planning rather than settled informally by whoever shouts loudest. A board that approves a digital roadmap without asking how much of the same team’s time security fixes will take is approving a plan that may not survive contact with reality.

Triage matters most here, because this is where a bank can generate its own findings. A scanner that produces ten times as many credible results helps only if someone ranks them by exposure and business importance. That ranking depends on an application inventory that records what each system does, whether it faces the internet and who owns it. Without the inventory, a long list of findings is just a longer to-do list.

Code the bank buys

Most of a bank’s exposure sits in software it licenses: core banking platforms, digital banking front ends, payment and card systems, network and security appliances. The core banking platform is the system of record for accounts, balances and transactions: the bank’s central ledger. Front ends are the apps and websites customers see; appliances are the specialized boxes that route and filter network traffic.

Here the bank finds little and fixes nothing. It waits for the vendor to patch, then deploys. The vendors with access to frontier discovery tools were mostly large technology firms. Many specialist banking software providers were not on any published list, so their customers had to ask.

The practical work is contractual and operational. Contracts for critical software should set patch timelines by severity, require notice when a vulnerability is confirmed, and oblige the vendor to say whether it uses AI-assisted code review. Operationally, the bank needs to know how long it takes to deploy a vendor patch to each critical platform, including the testing a core conversion team insists on.

For community banks and credit unions running on a core processor or technology service provider, the deploy step belongs to the provider. The issue moves into vendor oversight: what the provider’s patch cadence is, and how it would handle a surge. A small bank’s board cannot patch its core itself, but it can ask, in writing, how quickly its provider would.

Compensating controls fill the gap between disclosure and patch. These are temporary measures that reduce risk while the real fix is pending. Network segmentation divides systems into compartments so that a break-in in one cannot easily spread. A web application firewall sits in front of a website and blocks requests that look like known attacks. The ability to switch off a non-essential feature removes the door entirely until it can be fixed. All of these buy time. They work only if they are pre-approved, because a surge is the wrong moment to design them.

Open-source code nobody owns

Open-source components sit inside both the bank’s own applications and the products it buys. The Linux Foundation’s place among the launch partners, and the donations to open-source security groups, signaled where many of the first findings were expected.

When maintainers ship fixes, no vendor pushes them into a bank’s internal applications. Someone inside has to notice, upgrade the dependency, rebuild and redeploy. If nobody is assigned, nobody does it. The fix exists on the internet; the flaw remains in the bank.

Most banks manage this part of the estate least well. A software bill of materials for each internal application tells the bank which components it uses. A named owner for each widely used component makes sure upgrades happen. For components embedded in vendor products, the bank depends on the vendor’s own dependency hygiene, which belongs in due diligence alongside the patch timelines above.

One advisory, three clocks

Suppose a mid-sized bank wakes on a Tuesday to a critical advisory for a widely used open-source component. Within a day, its security team learns the component appears in three places: an internally built loan application, the vendor-supplied online banking platform and a network appliance.

Each runs on a different clock. For the loan application, the bank’s own developers must upgrade the component, rebuild, test and release. If a quarter-end freeze is in force and there is no fast lane, the fix waits. For online banking, the bank waits for the vendor; its contract either specifies a timeline for critical fixes or it does not. For the appliance, the manufacturer issues an update, and the network team schedules it.

In the meantime, a pre-approved web application firewall rule blocks the most obvious attack pattern against the internet-facing systems, and a little-used feature in the loan application is switched off. The chief information security officer can tell the risk committee exactly which systems are exposed, which controls are in place and when each fix is expected. Preparation here means a known path to closing each flaw, since nobody can promise the flaws away.

At a less prepared bank, the same Tuesday goes differently. The security team spends the first two days just working out where the component is used, by emailing application owners, some of whom have left. Nobody knows what the online banking contract says about critical fixes. The firewall team wants approval before changing rules, and the approver is traveling. The flaw is identical; the outcome is not.

What slow patching costs a bank

For a bank, the stakes of slow patching are concrete. An unpatched internet-facing system is how many breaches begin. The consequences include fraud losses, outages that stop customers paying or being paid, notification costs, and the reputational damage of explaining to customers why their data was taken.

Regulators care for the same reasons, and for one more: financial stability. When the Treasury Secretary and the Federal Reserve Chair brief the chief executives of the largest banks, they are signaling that cyber risk has moved beyond an operational matter for individual firms. A widely shared flaw could hit many institutions at once.

Customers rarely think about patching, but they notice its absence. A bank that suffers a breach through a flaw that was publicly fixed weeks earlier faces a hard question from customers, journalists and examiners alike: why was the fix not installed? “We were waiting for the change window” is a true answer at many institutions, and a poor one.

There is also a cost argument that boards sometimes miss. Investment in automated testing, inventories and a fast lane pays off beyond defense. The same machinery that lets a bank ship a security fix in days lets it ship product improvements faster too. Banks that treat remediation speed as a capability, rather than a compliance burden, tend to get both benefits.

Across all three parts, the metric that matters is time from a credible critical finding to a deployed fix. It should be reported separately for internal, vendor and open-source code, because the levers differ. Scan coverage and raw vulnerability counts say little about that constraint.

Examiners have long reviewed whether a vulnerability management program exists and whether critical findings are tracked. The more telling evidence is the age of open critical findings and the share closed within policy. Banks that already report those figures to a risk committee will find supervisory conversations easier.

Measuring outcomes, not scans

A bank in good shape can do a handful of things on demand. It can list its critical applications, who owns them and whether they face the internet. It can say, for each critical vendor platform, what the contract requires on patch timing and how long deployment really takes. It can produce a component list for its own applications. And it can show a risk committee the time from critical finding to fix, split three ways.

The failures follow a pattern. One is measuring activity rather than outcome: proudly reporting how many scans were run while critical findings sit open for months. Another is assuming the vendor has it covered without asking. A third is treating open-source components as nobody’s job. A fourth is leaving the change process untouched, so that a security fix waits behind a freeze window designed for an entirely different risk.

How fast the fixes would land

• How long, at the median, does it take us to go from a credible critical finding to a deployed fix, for our own code, vendor code and open-source code separately?
• Do we have a fast lane for urgent security releases, and who can approve shipping during a freeze window?
• What do our contracts with core, digital and payment vendors say about patch timelines, and have we asked those vendors how they would handle a surge of fixes?
• Do we know which open-source components are in our own applications, and who upgrades them?
• How old are our oldest open critical findings, and what share did we close within policy last quarter?

With hindsight

Supervision moved in the months that followed, though not toward a single rule. In May, Bloomberg reported that the Federal Reserve and the OCC were pausing some cyber examinations of the largest banks to give them time to strengthen defenses against flaws exposed by the newest models. The OCC, the Office of the Comptroller of the Currency, supervises national banks; its pausing exams to free up time for defensive work was an unusual signal of priorities.

The April meeting mattered for who convened it. Senior Treasury and Federal Reserve officials briefing bank chief executives about a specific model put AI-driven cyber risk on the financial stability agenda, a different category from an ordinary security warning. It told boards that the issue had reached the people responsible for the system as a whole.

The OCC’s spring risk report warned that AI was lowering the barrier to entry for attackers: work that once needed a skilled specialist could increasingly be done by someone less capable with the right tools.

In July, the ECB, which directly supervises the significant euro-area banks, wrote to those banks asking for plans to counter AI-enabled cyber threats by October 31. It pointed them toward internet-facing systems, third-party software, open-source components and faster fixes. Read side by side with this article, that list is familiar: it is close to a checklist of the three parts of a bank’s software estate, plus the speed of remediation.

The public record on attackers gaining comparable capability remains thin, and we would not overstate it. The access gap and the remediation constraint are both well documented, and the ECB’s request reads almost as a list of the three parts above.

Whatever happens with any one model, discovery of flaws is getting cheaper. A bank’s safety increasingly depends on the unglamorous machinery of fixing them: inventories, contracts, testing, change processes and named owners. Those are management choices, and they are within every board’s reach.