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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- AI can turn security fixes into working exploits before users receive an update, Aiden Ament, Yafah Edelman, Alexander Barry, Timothée Chauvin, Lee Bousfield and Jaeho Lee, Epoch AI, 29 October 2026
- Gemini 4 Carbon: our next frontier model, Koray Kavukcuoglu, Google, 28 October 2026
- Fairwind Program, Google DeepMind
- Postgres 19 delayed after AI reviewers find more bugs than humans can fix, Lindsay Clark, The Register, 16 October 2026
- Apologies for delaying Postgres 19, Zsolt Parragi, Percona Community, 15 October 2026
- Black October: The haystack doubled… but what about the needles?, John Crooks, Iru, 2 November 2026
- Volume Is Not Risk: Making Sense of the 'Vulnpocalypse', Johnny Hand, Trend Micro, 21 July 2026
- AI is changing the economics of vulnerability discovery. Defenders should adapt now, CERT-EU, 21 April 2026
- Addressing AI-enabled cybersecurity threats (SSM-2026-0301), Claudia Buch, ECB Banking Supervision, 7 July 2026
- ECB urges banks to draw up action plans addressing AI-enabled cybersecurity threats, Austrian Financial Market Authority (FMA), 7 July 2026
