All articles
CybersecurityAI SecurityBanking TechnologyVulnerability Management

AI vulnerability discovery in 2026: the patch gap, the ECB's October deadline and what banks must change

In late October 2026 AI vulnerability discovery stopped being a forecast. An open-weight model turned unreleased Firefox fixes into working exploits for about $1,000 each, Google limited its newest frontier model to cyber defenders, PostgreSQL 19 slipped after AI reviewers found more bugs than committers could fix, CVE volume more than doubled, and the ECB's deadline for bank action plans on AI-enabled cyber threats fell due on 31 October. What the evidence shows, why the patch gap is now the critical window, and a practical playbook for bank technology leaders.

By Yassineh Pourebrahim · · 10 min read

For most of this year, AI vulnerability discovery was discussed as something that was about to change security. In the last week of October 2026 the evidence arrived in a single cluster. Epoch AI showed that a freely available open-weight model could turn published but unreleased Firefox fixes into working exploits for about $1,000 per version. Google announced its strongest model, Gemini 4 Carbon, and made it available first only to vetted cyber defenders. PostgreSQL 19 was pushed to November after AI-assisted reviews surfaced more defects than the project's committers could fix in time. And on 31 October, the deadline the European Central Bank had set for significant banks to submit action plans on AI-enabled cybersecurity threats fell due. Read together, these events say that the bottleneck in security has moved: finding vulnerabilities is becoming cheap, and the scarce resource is now the capacity to triage, patch and contain them.

What happened in October 2026

An open-weight model exploited the Firefox patch gap

On 29 October, Epoch AI published research showing that GLM 5.3, an open-weight model released by Z.ai in August, could exploit the patch gap: the window between a security fix becoming public and that fix reaching users. The researchers gave the model basic tools and only information that was public at the time of each release, without internet access. It built a webpage that, when visited by a Firefox user, read a file from the visitor's computer and sent it to the attacker with no further interaction.

The model succeeded against all six Firefox releases between 17 September and 26 October (156.0 to 158.0.1). It had up to 48 hours per target; its fastest attempt took 12 hours. Once the harness was built, the marginal cost was about $1,000 per Firefox version at API prices, even though the total research spend exceeded $100,000. Three details matter for risk owners. First, the model recognised which code changes were security fixes even though such fixes are deliberately disguised as ordinary improvements. Second, every successful chain also relied on a separate, unpublished vulnerability that the model rediscovered on each attempt; Epoch disclosed it to Mozilla, which patched it in Firefox 159.0 on 27 October. Third, the researchers framed the work as a security exercise and triggered no refusals or safeguards from any provider. Equivalent attempts against Google Chrome, with about $100,000 more in API spend, had not succeeded at the time of publication, and Epoch is careful not to treat that as proof that Chrome is safe.

Epoch's conclusion is the sentence I would put in front of every change advisory board: once a vulnerability fix is in published code, assume attackers can and will use it to target the current release. It also notes that both Firefox and Chrome have started shipping updates every week, and advises against patching multiple vulnerabilities at the same time when they can be chained together.

The frontier labs restricted their own models

On 28 October Google DeepMind introduced Gemini 4 Carbon, which it described as its strongest model for cybersecurity and long-horizon work. Google reported 88.2% on SEC-bench Pro for finding vulnerabilities, 54.8% on ExploitGym for exploitation and 71.0% on CWE-bench for patching. Instead of a general launch, Google said Carbon would go first to a subset of cyber defenders, then to more trusted partners through its Fairwind Program, while it takes part in the US government's voluntary pre-release testing process. Fairwind, according to Google, already has more than 650 partners and prioritises governments, critical infrastructure operators, including financial networks, and core technology platforms. Partners must use phishing-resistant multi-factor authentication and may give access only to internal security, incident response or penetration testing teams.

This follows a pattern CERT-EU described in April: Anthropic distributed Claude Mythos Preview only through Project Glasswing, and OpenAI released a cyber-specialised model through a trusted-access programme. The Epoch result is the uncomfortable counterpoint. Restricting the strongest closed models gives defenders a head start, but capable open-weight models are already good enough for a specific, valuable class of attack.

PostgreSQL 19 slipped because AI found too many bugs

The same shift is visible on the defensive side, and it is not painless. PostgreSQL 19, normally expected in September or early October, is now planned for general availability on 19 November, and between eight and ten features have been reverted to PostgreSQL 20. Peter Eisentraut, a leading committer, told The Register that LLM-assisted review had uncovered a long tail of edge-case issues that would previously have been found over years: "you're staring at a list of forty defect reports... and then you run out of time." In his words, "the effective quality bar has been raised after the time the feature was written and committed."

Percona's Zsolt Parragi added the security dimension. By his count PostgreSQL fixed 7 security issues in 2025 and 44 in 2026 so far, 28 of them in August alone. Where one or two committers used to handle security fixes for a minor release, ten did in August. The project is discussing more frequent minor releases, every one and a half to two months, to get fixes to users faster.

CVE volume doubled; confirmed exploitation did not

The numbers behind the "vulnpocalypse" label need careful reading. An analysis by Iru, published on 2 November, counts about 88,700 CVEs in the National Vulnerability Database between 1 January and 29 October 2026, roughly 2.3 times the same period of 2025. Over the same window, CISA's Known Exploited Vulnerabilities (KEV) catalogue grew by about 31%, from 212 to 278 additions. Google's threat intelligence group puts the share of 2026 CVEs seen exploited at about 0.23%. Microsoft's October Patch Tuesday fixed a record number of vulnerabilities, roughly 1,400 depending on the count, and exactly one was confirmed exploited.

The exploited minority is concentrated and fast. Of the 38 KEV additions between 21 September and 20 October, 15 were firewalls, VPNs, gateways or remote-access tools. In the PHP2Shell case, exploitation attempts were reported from 17 October, four days before the 21 October patch. Trend Micro reported in July that CISA had replaced its flat 14-day KEV remediation deadline with a risk-based model that can require action in as little as three days. CERT-EU, citing Google's M-Trends 2026, puts the mean time to exploit newly disclosed vulnerabilities at an estimated minus seven days, against 63 days in 2018, while enterprise patch cycles typically still run 30 to 60 days.

Why the ECB letter matters for every bank, not only in Europe

On 7 July 2026 the ECB's Supervisory Board chair, Claudia Buch, wrote to the CEOs of all significant institutions. The letter states that emerging AI models can identify vulnerabilities and generate functioning exploits "at unprecedented speed", and calls this "a long-term shift in the threat landscape rather than a temporary phenomenon or a risk tied to any single tool." It places responsibility on management bodies and asks banks to revisit ICT investment, resource allocation and risk tolerance frameworks.

Each significant bank had to submit an action plan to its Joint Supervisory Team by 31 October 2026. In the short term the ECB asked banks to:

  • accelerate vulnerability and patch management at scale;
  • enhance monitoring, detection and AI-enabled defensive capabilities;
  • verify that third-party risk management is fit for purpose, given the role of ICT providers in critical supply chains;
  • prioritise perimeter technologies and internet-facing assets, including third-party software and open-source components.

The structural measures are longer term: defence in depth, zero-trust principles, replacing or protecting legacy and end-of-life technology, and tested response and recovery that covers high-speed, high-volume attack scenarios. Two practical details stand out. The ECB wants risk appetite frameworks to include metrics and tolerance thresholds for things such as patching frequency, and it expects change management and supplier service level agreements to support rapid, risk-based remediation. To free up capacity, it moved the annual IT Risk Questionnaire deadline from September 2026 to February 2027, and it will run a horizontal analysis of all submitted plans. The ESRB published a warning on systemic cyber risks from frontier AI models on the same day.

For banks outside the euro area, the letter is still the most concrete supervisory checklist published so far for AI-enabled cyber threats in banking. It turns a technology trend into board accountability, budget and measurable thresholds.

What has really changed

Put side by side, the October evidence points to three shifts.

  1. The cost of turning a fix into an exploit has collapsed. A thousand dollars and a basic harness are within reach of far more actors than the specialist teams that used to do patch diffing. Every published fix in software you run is now a signal to attackers.
  2. The defenders' bottleneck is human capacity, not detection. PostgreSQL did not lack findings; it lacked committer hours. Your security operations, change management and application teams face the same arithmetic.
  3. Volume is not risk, but speed is. Most new CVEs will never be exploited. The few that are, especially on edge devices, are exploited within days or before a patch exists. Prioritisation, not coverage, decides outcomes.

My view: rebuild vulnerability patch management around hours, not cycles

I have spent much of my career running critical banking systems where a change window was a carefully negotiated event. That model assumed attackers needed weeks to weaponise a public fix. They no longer do. Here is the vulnerability patch management playbook I would use with a bank's leadership team.

  1. Know your exposed estate, precisely. Maintain a live inventory of internet-facing assets, edge devices, third-party software and open-source components, with an owner for each. The ECB lists this first for a reason: you cannot patch in hours what you cannot find in minutes.
  2. Split patching into two lanes. Keep the normal cycle for most fixes, and create an emergency lane for KEV-listed or actively exploited flaws on exposed systems, with pre-approved change procedures and a target measured in hours to days.
  3. Watch the patch gap of your critical vendors. Track when fixes for your key open-source and commercial components become public, not only when releases ship, and pre-stage compensating controls such as WAF rules, virtual patching and access restrictions for that window.
  4. Write the numbers into the risk appetite. Time to remediate exposed critical vulnerabilities, share of the edge estate on supported versions and time from KEV listing to mitigation belong on the board dashboard, as the ECB now expects.
  5. Put patch speed into supplier contracts. Ask outsourcers, cloud providers and core vendors how they handle accelerated disclosure and what remediation times they commit to. Under the ECB's framing, the bank remains fully accountable for outsourced ICT risk.
  6. Use AI on your own code, with human validation. Run AI-assisted review on internal applications and integration code before attackers run it for you. Treat its findings like any other tool's output: validated, triaged and measured, the same discipline I argued for in AI agent benchmarks in 2026.
  7. Retire or isolate end-of-life systems. Unsupported platforms will never receive the fix that an AI system eventually finds. As I discussed in Core banking modernization in 2026, legacy cores can be wrapped and modernised step by step, but anything that cannot be patched must be segmented and closely monitored.
  8. Staff and rehearse for the wave. Budget for more frequent patching, exercise high-volume and zero-day scenarios, and join trusted information-sharing arrangements. Banks that qualify should also evaluate defender access programmes such as Fairwind, under the governance those programmes require.

There is a familiar pattern here. In Post-quantum cryptography in 2026 I described how a cryptographic inventory and crypto-agility turn a distant threat into a manageable programme. The ECB's letter makes the same link, saying that the adoption of post-quantum cryptography "must start now" and that a separate letter on quantum risk will follow. Asset inventory, fast and safe change, and accountable ownership are the common foundation for both.

Closing thought

October 2026 did not prove that AI has handed attackers a permanent advantage. Discovery is accelerating on both sides, and much of what AI is surfacing is decades of security debt that is finally being paid down. What it did prove is that the time between a fix being published and an exploit existing can now be measured in hours and dollars, not weeks and specialist teams. The banks that come through this well will not be those with the most scanners. They will be the ones that can find their exposed assets quickly, decide in hours, change safely and show their supervisors the numbers.

References

Related articles

Post-Quantum CryptographyBanking SecurityQuantum ComputingCryptographic Agility

Post-quantum cryptography in 2026: why banks are moving their migration deadlines forward

Google and Cloudflare now target 2029, a US executive order sets 2030 and 2031 deadlines, and payment bodies are sending vendor questionnaires. What changed in 2026, what the quantum threat really means for banking systems, and a staged post-quantum migration plan a technology leader can take to the board.

· 9 min read

Core BankingAI AgentsBanking TechnologyAI Governance

Core banking modernization in 2026: AI agents on legacy cores, runtime guardrails and the wrap-or-replace decision

In October 2026 four announcements reframed core banking modernization. Sutherland and FlowX.AI offered to run more than 220 AI agents on top of the cores banks already own, Emprise Bank chose an AI-native core from Maximum, SBS put sovereign generative AI inside its core platform, and BBVA said it will explore NVIDIA's OpenShell Reference Architecture for governing agents at runtime. What each path means for legacy core banking systems, where the risks sit, and a practical playbook for bank technology leaders.

· 10 min read

AI AgentsAI Agent EvaluationBenchmarksBanking Technology

AI agent benchmarks in 2026: why leaderboards mislead and how banks should evaluate AI agents

In October 2026 Stanford, Salesforce AI Research and a Tencent-led consortium published new research on AI agent benchmarks, while Santander and TD described how they test agents before production. What the new results say about leaderboard reliability, long-horizon work and partial credit, and a practical AI agent evaluation playbook for banks and enterprises.

· 8 min read