1 Introduction

For most of the history of computing, finding a previously unknown and exploitable software vulnerability—a zero-day—was slow, expensive and the preserve of a small community of specialists. That scarcity shaped who could attack critical systems. The best-known example, Stuxnet, used four Windows zero-days and stolen code-signing certificates to sabotage uranium-enrichment centrifuges at Iran’s Natanz facility (Falliere et al. 2011; Langner 2013; Zetter 2014); it required resources available only to states. Banks have historically been attacked by cheaper means: stolen credentials, phishing, insiders and known but unpatched vulnerabilities.

Since 2024 that scarcity has eroded. Large language model (LLM) agents have moved from solving capture-the-flag exercises (Zhang et al. 2024) to exploiting known web vulnerabilities from their advisories (Fang et al. 2024; Zhu et al. 2024) and to finding new, real vulnerabilities in widely deployed software (Big Sleep team 2024; DARPA 2025). Frontier AI developers now operate dedicated vulnerability-research agents (OpenAI 2025; Google DeepMind 2025; Anthropic 2026a), and at least one threat report describes an espionage campaign in which an AI agent executed most tactical steps (Anthropic 2025). If the cost of discovering zero-days falls by an order of magnitude, the threat model for the financial system changes.

This paper asks six questions:

1. How much vulnerability discovery is now done with AI, by whom, and with what trajectory?

2. Which commercial software has been exploited as a zero-day, and how has exploitation changed?

3. Are hardware-wallet zero-days relevant to banks?

4. Where is the global banking system exposed, and would AI-discovered zero-days be used against it?

5. In Thailand, which groups of institutions are likely targets and which are most vulnerable?

6. Should central banks, including the Bank of Thailand (BOT), treat this as a priority, and what should they do?

We answer with four bodies of evidence. The first is the complete CVE List V5 (CVE Program 2026), from whose free-text credits we identify AI-credited discoveries using a transparent, auditable lexicon. The second is the CISA KEV catalogue (Cybersecurity and Infrastructure Security Agency 2026), which we turn into a panel of exploited vulnerabilities with product categories, disclosure-to-listing lags and a validated zero-day proxy. The third is a curated set of financial-sector incidents and hardware trust-anchor cases. The fourth is a group-level framework for Thailand together with a Monte Carlo model of shared-vendor contagion calibrated to KEV event rates.

1.0.0.1 Contributions.

(i) We provide what is, to our knowledge, the first census of AI-credited CVEs across the full CVE corpus, with a documented lexicon and its known false positives. (ii) We document a 2026 disclosure shock in commercial software and show that exploitation has grown more slowly than disclosure. (iii) We validate a simple KEV-based zero-day proxy against published industry counts. (iv) We connect vulnerability data to financial-sector exposure through a bank-weighted exploitation-pressure measure and an incident record. (v) We offer a reproducible scenario model and a ten-point policy agenda for central banks. All code and derived data accompany the paper.

1.0.0.2 Headline findings.

AI-assisted discovery is real, fast-growing and so far mostly defensive; exploitation of commercial perimeter and IT-management products is the main channel through which zero-days reach financial institutions; and the main systemic risk for a system such as Thailand’s is correlated exposure through shared vendors and service providers rather than a direct attack on the core payment infrastructure. Section 12 sets out why these findings justify central-bank attention now.

1.0.0.3 Roadmap.

Section 2 sets out concepts; Section 3 reviews related work; Section 4 describes data and methods. Sections 5–9 present results on disclosure, AI discovery, exploitation, hardware and financial exposure. Section 10 analyses Thailand, Section 11 reports the simulation, Section 12 discusses policy, and Section 13 states limitations.

2 Background and concepts

2.1 Zero-days, n-days and the exploitation window

A zero-day is a vulnerability exploited before the vendor has disclosed it or made a fix available; an n-day is exploited after disclosure, during the period in which users have not yet applied the fix. Figure 1 places both on a single timeline. The zero-day window runs from first exploitation to disclosure; the n-day window runs from disclosure until each user deploys the patch. Historical studies found that zero-day attacks often persisted for months before discovery (Bilge and Dumitraş 2012) and that stockpiled exploits had long expected lifetimes (Ablon and Bogart 2017). More recent industry reporting suggests that the time from disclosure to exploitation has collapsed to days (Mandiant 2024).

2.2 Levels of AI involvement

We distinguish five levels, because public debate often conflates them:

Public data observe L2 directly, L4 occasionally through threat reports, and L1 and L3 hardly at all. Our measurements are therefore lower bounds on AI involvement.

2.3 Why banks are exposed

Banks run the same commercial products as other large organisations. These include perimeter VPN and firewall appliances, managed file transfer (MFT), mail and collaboration servers, IT-management and remote-access tools, hypervisors, and enterprise applications. Banks also connect to shared infrastructures: real-time gross settlement (RTGS), retail payment switches, card networks, messaging networks and a small number of IT and cloud providers. A zero-day in a widely used product therefore produces correlated exposure across institutions, which is the mechanism through which an operational event becomes a financial-stability event (Kashyap and Wetherilt 2019; Eisenbach et al. 2022; Adelmann et al. 2020).

3 Related literature

3.0.0.1 Vulnerability lifecycle and economics.

Empirical work has measured vulnerability disclosure and patching (Frei et al. 2006; Arora et al. 2010), the hidden lifetime of zero-days (Bilge and Dumitraş 2012), and the economics of exploit stockpiles (Ablon and Bogart 2017). Exploitation-prediction models such as EPSS (Jacobs et al. 2021) and catalogues of known-exploited vulnerabilities (Cybersecurity and Infrastructure Security Agency 2021) reflect a shift from severity-based to evidence-based prioritisation. Annual reviews by Google Project Zero, Google’s Threat Intelligence Group and Mandiant count in-the-wild zero-days (Stone 2022; Mandiant 2023; Google Threat Analysis Group and Mandiant 2024; Google Threat Intelligence Group 2025) and document a concentration of exploitation on enterprise and perimeter products.

3.0.0.2 AI offensive and defensive capability.

Benchmarks measure LLM capability on security tasks (Bhatt et al. 2023; Zhang et al. 2024; Zhu et al. 2025). Agent studies show exploitation of one-day (Fang et al. 2024) and, with coordinated agent teams, zero-day web vulnerabilities (Zhu et al. 2024). On the defensive side, Google’s Big Sleep reported an exploitable SQLite bug before release (Big Sleep team 2024). DARPA’s AI Cyber Challenge showed cyber-reasoning systems finding and patching real open-source bugs (DARPA 2025), and AI developers have launched agentic security researchers (OpenAI 2025; Google DeepMind 2025) and restricted-access defensive programmes (Anthropic 2026a). Threat-intelligence reports document misuse, ranging from reconnaissance and scripting (Microsoft Threat Intelligence and OpenAI 2024) to largely autonomous intrusion operations (Anthropic 2025). Most of this work measures capability in controlled settings; we add population-level evidence from the CVE corpus.

3.0.0.3 Cyber risk and financial stability.

A macro-financial literature models how cyber events propagate: through payment-system impairment (Eisenbach et al. 2022), runs (Duffie and Younger 2019), common exposures and concentration (Kashyap and Wetherilt 2019; Healey et al. 2018), and loss distributions (Bouveret 2018; Aldasoro et al. 2022). The IMF identified cyber risk as a growing macro-financial concern (International Monetary Fund 2024; Adelmann et al. 2020). Standard setters have issued guidance on financial market infrastructure (FMI) resilience (CPMI–IOSCO 2016), a common lexicon (Financial Stability Board 2018) and incident-reporting convergence (Financial Stability Board 2023, 2025). Supervisors have run cyber stress tests (European Central Bank 2024) and introduced oversight of critical third parties (European Parliament and Council 2022; Bank of England et al. 2024). This literature rarely uses vulnerability-level data; we connect the two.

3.0.0.4 Hardware security.

Research on payment cards (Murdoch et al. 2010; Basin et al. 2021), secure elements (Nemec et al. 2017; Roche 2024), TPMs (Moghimi et al. 2020), HSMs (Campana and Bédrune 2019) and hardware wallets (Datko et al. 2018; Kraken Security Labs 2020) supplies the material for our discussion of hardware trust anchors.

4 Data and methods

4.1 CVE List V5

We downloaded the official bulk release of the CVE List V5 (CVE Program 2026) as of 12 November 2026 (425,189 files; 405,375 records in PUBLISHED state). For each record we extract dates, the assigning CVE Numbering Authority (CNA), the first affected vendor and product, the first CWE, the maximum CVSS base score across containers, the CISA ADP SSVC “Exploitation” field, and the free-text credits. Only 43.4% of records published in 2026 carry any credit. Several of the largest commercial CNAs—Microsoft, Google Chrome, Apple, Oracle, SAP, Fortinet and the Linux kernel CNA—recorded none (Table 1).

4.2 Identifying AI-credited discoveries

We apply a lexicon of case-insensitive regular expressions to the credit text (Appendix Table 16). Tier 1 records name an AI model, agent or tool as finder or co-finder (for example “Google Big Sleep”, “XBOW”, “Claude Security”, “OpenAI Codex Security”, “Fluid Attacks’ AI SAST Scanner”). Tier 2 records credit an AI-native security organisation or an AI laboratory without naming a model (for example AISLE, depthfirst, ZeroPath, Horizon3.ai, or “OpenAI” as an organisation). We reviewed random samples of matches for every pattern. This review led to three exclusions: a human researcher whose given name is Claude, a username containing “gpt”, and the brand name of an established human bug-bounty programme whose name contains the letters “AI” (76 false matches before exclusion). Tier 2 is a proxy: AI tooling is likely but not certain for each record. Because credit coverage is incomplete and AI assistance at level L1 is rarely credited, all counts are lower bounds. We also classify the affected software into domains with keyword rules on vendor, product and CNA.

4.3 KEV exploitation panel

The KEV catalogue (Cybersecurity and Infrastructure Security Agency 2026) lists vulnerabilities with reliable evidence of in-the-wild exploitation. We map each entry to one of 15 product categories with ordered keyword rules (Appendix 16); 7.1% remain unclassified. We merge the CVE publication date and compute the listing lag $$\begin{equation} \ell_i = d^{\text{KEV}}_i - d^{\text{pub}}_i \quad\text{(days)}. \end{equation}$$ The catalogue opened on 3 November 2021 with a back-filled list, so we use lags only for CVEs published on or after that date ($n=898$).

4.3.0.1 Zero-day proxy.

We call an entry early-listed if $\ell_i \le 7$. A vulnerability that is already exploited when it is disclosed is typically listed within days, whereas n-days are listed after weeks or months. We benchmark annual counts of early-listed vulnerabilities against published industry counts of in-the-wild zero-days (Section 7).

4.3.0.2 Right-censoring.

Recent CVEs have had less time to be exploited and listed. For trend comparisons we therefore use a censoring-robust cohort: CVEs published from 2022 up to 180 days before the snapshot, counting only listings within 180 days of publication.

4.4 Bank-weighted exploitation pressure

Not every product category matters equally to banks. We assign a banking-relevance weight $w_c\in[0,1]$ to each category (Appendix Table 18). Perimeter devices and MFT score 1.0; consumer routers and IoT 0.2; industrial control 0.1. Exploitation pressure is $\Pi_c = n_c w_c$, where $n_c$ is the number of post-launch KEV entries in category $c$; we split $\Pi_c$ into zero-day-like and later-listed parts. Because the weights are judgemental, we report the rank stability of $\Pi_c$ under 2,000 random perturbations of $\pm0.3$ and under uniform weights.

4.5 Curated case data

We coded 33 financial-sector incidents from 2011 to 2025 (Table 20) and 11 hardware trust-anchor cases (Table 7) from public reporting. The incident list is a purposive sample of well-documented cases chosen to span victim types (commercial banks, central banks, supervisors, FMIs, payment and crypto firms), regions and vectors. Shares computed from it are descriptive, not estimates of population frequencies.

4.6 Thai group framework

We score 12 groups of Thai financial-system participants on five 1–5 dimensions: attractiveness $A$, systemic importance $S$, exposure $E$, shared-vendor concentration $K$ and defensive capacity $D$. From these we form a target index $T=(A+S)/2$, a vulnerability index $V=(E+K+(6-D))/3$, and a risk score $$\begin{equation} R = \frac{T\cdot V}{25}\in[0.04,1]. \end{equation}$$ Robustness is assessed over 10,000 draws that shift each score by $-1/0/{+1}$ (probabilities 0.25/0.5/0.25) and draw component weights from a Dirichlet(5) distribution. The scores are structured judgements about groups; they say nothing about any individual institution.

4.7 Shared-vendor contagion model

We simulate one year of exploited-vulnerability events against a stylised system of 67 nodes whose group structure follows Thailand. The groups are 6 D-SIBs, 8 other domestic banks, 12 foreign banks, 6 specialised financial institutions (SFIs), 3 virtual banks, 25 payment and e-money providers, 5 shared IT providers and 2 payment FMIs (Table 11). Each node runs one of five vendors in each of six enterprise technology layers; vendors are drawn according to market shares $\mathbf{s}$. Events arrive per layer as $N_l\sim\text{Poisson}(\lambda_l m_d (1-\phi))$, where $\lambda_l$ is the KEV event rate for publication years 2023–2025 (Table 12), $m_d$ is an AI offence multiplier and $\phi$ is the share of bugs pre-empted by defensive AI. Each event hits vendor $j$ with probability $s_j$, and each user of that vendor runs the affected product with probability $\rho$.

A share $p^{zd}_l$ of events (the early-listed share for that layer) start with a zero-day phase. In that phase, mass campaigns (probability $p_{\text{mass}}$) compromise each exposed node with probability $c_{\text{mass}}\,s_g\,\delta$. Targeted campaigns choose $\text{Poisson}(k\,m_o)$ victims weighted by attractiveness, where $m_o$ scales attacker operational throughput. In the n-day phase, copycat exploitation begins after a time-to-exploit $\tau$ for zero-days, or after $\kappa$ times an empirical KEV lag for n-days. Node $i$ is then exposed until its patch time $P_i\sim\text{LogNormal}(\ln(\beta\,\bar P_g),0.9)$ and is compromised with probability $$\begin{equation} 1-\exp\!\big(-h\,m_o\,s_g\,\delta\,\max(0,P_i-\tau)\big). \end{equation}$$ A compromised shared provider passes compromise to each of its eight clients with probability 0.25. A compromise disrupts payments with a group-specific probability. An event is systemic if it disrupts at least 10% of system payment value or any payment FMI. Scenario parameters are listed in Table 13. The model is comparative: absolute levels depend on assumptions, so we emphasise relative risks and test them over a grid of the two least-anchored parameters, $\rho$ and $c_{\text{mass}}$.

4.8 Reproducibility

The pipeline consists of nine scripts (s01–s09) that download, extract, classify, analyse, simulate and produce every table and figure. Every number quoted in the text is written to outputs/key_numbers.json. Random seeds are fixed. The complete pipeline runs in under ten minutes on one CPU core with 3 GB of memory.

5 Results I: the 2026 disclosure shock

Figure 2 shows that CVE publication grew steadily from about 6,500 a year in 2015–2016 to 39,924 in 2024 and 48,150 in 2025. It then broke trend in 2026. Between January and October 2026, 89,845 CVEs were published, 2.27 times the 39,638 published over the same months of 2025. Monthly volume rose from 4,274 in October 2025 to 17,051 in October 2026, and the acceleration began around March 2026. By 12 November, 96,498 CVEs had been published in 2026.

The surge is not confined to open-source projects. Table 1 and Figure 3 show that vulnerabilities assigned by large commercial vendors’ own CNAs rose by factors of 33 (Google Chrome), 13 (Oracle), 4 (Microsoft) and 2 (Apple). For banks, this matters more than the total: these vendors supply the browsers, operating systems, office software, databases and middleware on which every bank runs. The patch workload of a bank’s IT function scales with these counts. A doubling or quadrupling of vendor advisories in a single year is an operational shock even before any vulnerability is exploited.

5.0.0.1 What caused the shock?

The data cannot attribute the surge to AI on their own. The CNAs with the largest increases (Microsoft, Chrome, Oracle) publish no credits, so their records do not say who or what found the bugs. Three observations nevertheless point to AI-assisted discovery as a major contributor. First, the timing coincides with the deployment of agentic security researchers and restricted-access defensive programmes in late 2025 and 2026 (OpenAI 2025; Google DeepMind 2025; Anthropic 2026a). Second, among CNAs that do publish credits, AI-credited records rose from almost none to hundreds per month over the same period (Section 6). Third, the CNAs that publish credits and grew fastest—Apache (+177 AI-credited CVEs in 2026), Red Hat (+176), Mozilla (+95) and OpenSSL (+30)—have substantial AI-credited shares. Other factors, including CNA process changes and the expansion of CNAs such as VulnCheck and GitHub, also contribute. We treat AI as a likely but unquantified driver of the commercial-vendor surge.

6 Results II: AI in vulnerability discovery

6.1 Scale and trajectory

We identify 1,598 AI-credited CVEs: 665 in Tier 1 (an AI system named) and 933 in Tier 2 (an AI-native organisation credited). Seven appear before 2025, 151 in 2025 and 1,440 in 2026. The first Tier 1 credit in our data is dated 20 March 2025 (XBOW, an autonomous penetration-testing system, credited on an Apache CVE). Figure 4 shows that monthly counts grew at about 18.6% per month (s.e. 3.8 percentage points) between July 2025 and October 2026, a doubling time of about 4.1 months. In October 2026, AI-credited CVEs were 4.1% of all CVEs that carry any credit and 2.0% of all CVEs. Because the largest commercial CNAs publish no credits, the true share is higher.

6.2 Who is credited and what they find

Table [tab:developers] and Figure 5(a) show a concentrated field. Credits naming Anthropic’s Claude models and agents (510) and the AI-native firm AISLE (438) dominate, followed by OpenAI (196, of which 74 name Codex Security or a GPT model), ZAST.AI (171) and a long tail of smaller AI security firms. Google’s Big Sleep appears on 18 CVEs. These include CVE-2025-6965 in SQLite, which the vendor described as otherwise known only to threat actors—an example of AI pre-empting exploitation (Table 19).

The affected software is mostly open-source infrastructure: Java and web middleware (largely Apache projects), operating-system components, media parsers, browsers, and business and collaboration applications (Figure 5b). One domain stands out for banking: 111 AI-credited CVEs affect cryptographic, TLS and PKI libraries. These comprise 52 in Bouncy Castle, the dominant Java cryptography provider in enterprise and banking software; 33 in OpenSSL; and 25 in wolfSSL/wolfSSH, which is widely embedded in devices. Cryptographic libraries are the software layer of the trust anchors discussed in Section 8.

6.2.0.1 Severity.

AI-credited vulnerabilities are not trivial. In 2026, Tier 1 CVEs had a mean maximum CVSS score of 7.07, with 56.8% rated high or critical, against 6.98 and 51.3% for human-credited CVEs (Table 3). The difference between all AI-credited and human-credited CVEs is not significant ($p=0.66$). AI systems find vulnerabilities of the same severity as human researchers.

6.3 From AI discovery to exploitation

Fifteen AI-credited CVEs have entered the KEV catalogue (Table 4). Three features stand out. First, the median lag from publication to KEV listing is 17 days; these were exploited as n-days after disclosure rather than as zero-days. Second, seven of the fifteen were found by Horizon3.ai, an offensive-security firm that focuses on enterprise products attackers prize, so the apparent exploitation rate of AI-credited CVEs (9.4 per 1,000, against 1.5 for human-credited CVEs over 2023–2026) reflects what these firms look at more than how they find it. Third, only one Tier 1 CVE (Brotli, credited to OpenAI Codex Security) has been exploited, and none of the 86 Tier 1 CVEs in the censoring-robust cohort was listed within 180 days. Products in this set—SolarWinds Web Help Desk, SimpleHelp, JFrog Artifactory, Apache ActiveMQ and Tomcat, Palo Alto Expedition, Langflow and PHP—are typical of enterprise estates, including banks.

6.3.0.1 Answer to RQ1.

AI-credited discovery went from negligible to roughly 2–4% of credited CVEs in eighteen months and is doubling every four months. The publicly visible activity is overwhelmingly defensive or coordinated: AI developers, AI-native security firms and open-source maintainers disclosing and fixing bugs. Offensive use is documented in threat reports (Microsoft Threat Intelligence and OpenAI 2024; Anthropic 2025), but does not appear in vulnerability records, because attackers do not credit themselves. The number of people “using AI to hunt for zero-days” therefore cannot be counted directly. The observable footprint is large and growing, and the capability it reveals is available, with some lag, to attackers.

7 Results III: exploitation of commercial software

7.1 What gets exploited

Of the 1,779 KEV entries, 263 vendors appear among additions since 2022; the ten most frequent (led by Microsoft, Cisco, Adobe, Apple, Google and Oracle) account for 51.8%. Figure 6 shows how the composition of additions has shifted. Enterprise perimeter and network infrastructure—VPN, firewall, application-delivery and router platforms from vendors such as Fortinet, Palo Alto Networks, Citrix, Ivanti, Cisco and SonicWall—rose from 14.6% of additions in 2022 to 21.0% in 2026. IT-management and remote-access tools rose to 14.6% in 2026, from 1.8% in 2022. Browsers and plug-ins declined. A new category appeared: AI and automation platforms (for example Langflow and LiteLLM), with 12 entries, 11 of them added in 2026. The Herfindahl index of exploitation across vendors fell from 0.114 in 2022 to 0.035 in 2026: attackers now exploit a wider range of vendors.

7.2 How fast exploitation follows disclosure

Table 5 and Figure 7(a) report listing lags. In the censoring-robust cohort, the median lag has been between 4 and 6 days for every publication year since 2022. Between 51.5% and 64.9% of listed vulnerabilities were listed within a week, and 28–39% were listed on or before the day the CVE was published. We find no further compression after 2022 (Kendall’s $\tau=0.035$, $p=0.20$). Industry studies report that the average time-to-exploit fell from about a month to a few days during 2021–2023 (Mandiant 2024); our data suggest that the compression has since plateaued at that low level. This does not support the stronger form of our hypothesis H2 (continuing compression). The weaker form holds: the window is already too short for monthly patch cycles.

$^a$ November–December 2021 only. $^b$ CVEs published to mid-May 2026. “Proxy” counts all early-listed post-launch entries by publication year. “Reported”: industry counts of in-the-wild zero-days as reported by Mandiant (2022) and Google (2023, 2024) (Mandiant 2023; Google Threat Analysis Group and Mandiant 2024; Google Threat Intelligence Group 2025). Google Project Zero’s own count for 2022 was 41. Benchmark figures should be verified against the original reports.

7.2.0.1 Validating the zero-day proxy.

Early-listed counts by publication year were 51, 87 and 78 for 2022–2024, against reported in-the-wild zero-day counts of 55, 97 and 75—a mean absolute deviation of 7.2% (Figure 7b). The two series measure overlapping but not identical sets, so the agreement supports using the proxy for levels and trends, not for individual classification. On this proxy, zero-day-like exploitation rose to 97 in 2025 and 128 in 2026 to date, the highest in the series.

7.3 Exploitation has grown more slowly than discovery

KEV additions rose from 186 in 2024 to 245 in 2025 and 295 in 2026 to 10 November. Disclosure grew much faster, so the share of new CVEs that are exploited fell (Table 6). In the censoring-robust cohort, an average of 3.89 of every 1,000 CVEs published between 2022 and 2025 were listed within 180 days, against 2.62 per 1,000 in the first half of 2026. If the disclosure shock is substantially AI-driven, the defenders’ side of AI is currently ahead: vulnerabilities are being found and fixed faster than attackers are converting them into exploitation. This is our hypothesis H1. The same numbers carry a warning. A falling exploitation rate on a quadrupling base still means more exploited vulnerabilities in absolute terms, and the defenders’ patch workload has multiplied.

7.3.0.1 Answer to RQ2.

The commercial products exploited most often, and most often as zero-days, are perimeter devices (59.9% zero-day-like), operating systems (61.8%), browsers (93.2%), mobile platforms (70.8%) and managed file transfer (64.7%). Products with the heaviest ransomware association are mail and collaboration servers (37.2%), MFT (35.3%) and IT-management tools (29.3%) (Table 8). Well-known named campaigns in these categories—MOVEit, GoAnywhere, Accellion FTA, Exchange ProxyLogon, Citrix NetScaler, Ivanti Connect Secure, Fortinet FortiOS, SharePoint and Oracle E-Business Suite—are the specific products behind these aggregates.

8 Hardware trust anchors and hardware wallets

RQ3 asks whether zero-days in hardware wallets matter for banks. Table 7 summarises 11 cases. Hardware wallets share their building blocks with banking infrastructure: secure elements, microcontrollers, firmware and cryptographic libraries. These same blocks protect payment cards, PIN and payment HSMs, FIDO keys used by bank staff, TPMs in servers, and the secure enclaves of the phones that run mobile banking.

Three lessons follow. First, six of the eleven cases require physical access to the device: glitching, side channels, or a USB connection to a boot ROM. Such attacks do not scale to a remote campaign against a bank, but they matter for stolen tokens, insider threats and supply-chain tampering. Second, the remote cases are the dangerous ones, and they sit in software around the hardware. ROCA was a flaw in key generation in a secure-element library, exploitable from a public key alone (Nemec et al. 2017). The Ledger Connect Kit incident was a compromised software dependency. The 2025 Bybit theft manipulated the transaction-display layer of a multisig signing workflow, so that signers approved a transfer they did not intend. The banking analogue of this last case is the maker–checker approval screen for high-value payments. Third, AI discovery is now active in exactly this software layer: 111 AI-credited CVEs affect cryptographic libraries (Section 6).

8.0.0.1 Answer to RQ3.

Hardware-wallet zero-days are relevant to banks less through the wallets themselves than through common components and patterns. These are secure-element libraries (ROCA-type flaws), HSM firmware (Campana and Bédrune 2019), payment-card protocols (Murdoch et al. 2010; Basin et al. 2021) and transaction-display integrity in signing workflows. Banks and central banks that hold or plan to hold digital assets, issue tokenised deposits or pilot CBDC with offline hardware wallets inherit these risks directly.

9 Financial-sector exposure

9.1 Bank-weighted exploitation pressure

Weighting KEV categories by their relevance to bank estates (Figure 8, Table 8) puts enterprise perimeter infrastructure first ($\Pi=162$, of which 97 zero-day-like), followed by operating systems and identity (91.7), enterprise applications and web frameworks (81.6), IT-management and remote-access tools (73.8), and mail and collaboration (70.2). The ranking is robust to the weights: across 2,000 random perturbations of $\pm0.3$, the median Kendall rank correlation with the baseline is 0.88 (5th percentile 0.80), and it is 0.83 under uniform weights.

9.2 What the incident record shows

Table 9 and Figure 9 summarise the 33 curated incidents (full list in Table 20). About half (17) began with stolen credentials, fraud, social engineering or misconfiguration, as in Bangladesh Bank 2016, JPMorgan Chase 2014 and Capital One 2019. Five involved a zero-day. In every one of the five, the zero-day was in a widely used commercial product rather than in banking software. Three were in MFT appliances (Accellion FTA, which reached the Reserve Bank of New Zealand; GoAnywhere; MOVEit), one was in on-premise Exchange (the European Banking Authority) and one was in a document reader, used against a security vendor serving banks (RSA, 2011). Three cases were supply-chain compromises (NotPetya, SolarWinds Orion, Bybit), and three exploited known n-days in perimeter devices or browsers (for example Travelex through an unpatched Pulse Secure VPN). One, the 2024 CrowdStrike update failure, was a non-malicious common-mode failure; it shows how a single shared component can disrupt banks and payment services worldwide within hours.

Seven of the 33 cases hit central banks or supervisors. Their pattern is instructive: the RBNZ and EBA intrusions came through file-transfer and mail systems—commodity corporate IT—not through settlement systems. Bangladesh Bank was compromised in the environment around its payment-messaging interface. Bank Indonesia and the Bank of Zambia suffered ransomware.

9.3 Would AI-discovered zero-days be used against banks?

The evidence supports four statements. (i) Financial institutions are attractive targets for both financially motivated and state-linked actors. Some state-linked groups have a long record of attacks on banks and crypto firms (Bangladesh Bank, Bybit), and the AI-orchestrated campaign reported in 2025 reportedly included financial institutions among its intended targets (Anthropic 2025). (ii) Zero-days reach banks through the commercial products that banks share with every other sector. An attacker does not need a “banking zero-day”; an MFT or VPN zero-day reaches hundreds of banks at once. (iii) As AI lowers the cost of discovery, the scarcity that limited zero-day use to a few actors weakens. Mass-exploitation crews of the MOVEit type are the actors most likely to benefit, because their business model already converts one zero-day into many victims. (iv) We found no publicly documented case, up to our snapshot, of an AI-discovered zero-day used against a bank. Given the lags in public reporting and attackers’ incentives not to disclose methods, this absence is weak evidence of safety.

9.3.0.1 Answer to RQ4.

The global banking system is exposed mainly through perimeter devices, MFT, IT-management tools, mail and collaboration servers, and shared service providers. AI-discovered zero-days are likely to be used against banks through these products. The likeliest form is mass exploitation and data extortion. Destructive attacks on payment systems are possible but less likely, because they require deeper access and invite a strong state response.

10 Thailand

10.1 Institutional setting

Thailand’s financial system combines a concentrated commercial banking sector, in which a small number of domestic systemically important banks (D-SIBs) account for most deposits and payments, with state-owned specialised financial institutions (SFIs) that serve retail, rural, housing and SME segments. A large non-bank payment and e-money sector operates under the Payment Systems Act B.E. 2560 (2017) (Kingdom of Thailand 2017). Virtual banks were licensed in 2025 under a framework issued in 2024 (Bank of Thailand 2024), and digital-asset exchanges and custodians are supervised by the securities regulator. The core payment infrastructure comprises the BOT-operated RTGS system (BAHTNET), the retail real-time payment system (PromptPay and related services operated by National ITMX) and card switching. The Cybersecurity Act B.E. 2562 (2019) designates the banking and financial sector as critical information infrastructure (Kingdom of Thailand 2019), and the Thai Bankers’ Association operates a sector CERT (TB-CERT).

The four Thai cases in our incident set—ATM malware at a state-owned bank (2016), web-application data leaks at two large banks (2018), a card-not-present fraud wave (2021) and remote-access malware on customers’ phones (2022–2023)—involved no zero-day. Thai institutions nevertheless run the same commercial perimeter, MFT, mail, IT-management and virtualisation products that appear in the KEV catalogue, so they sit in the path of the same global mass-exploitation waves.

10.2 Targets and vulnerable groups

Table 10 and Figure 10 report the group framework. Groups with the highest target index are the D-SIBs, payment FMIs, shared IT and cloud providers, the BOT’s corporate and supervisory IT, and SFIs. Groups with the highest vulnerability index are retail customers and their devices, payment and e-money providers, virtual banks, shared providers, digital-asset firms and non-bank lenders. Combining the two, three groups rank highest: shared IT and cloud providers ($R=0.72$; in the top three in 86% of robustness draws), D-SIBs (0.67; 73%) and SFIs (0.59; 52%). Digital-asset exchanges and custodians (0.56) and non-bank payment providers (0.52) follow.

Three findings are robust to the perturbations. Shared providers rank at or near the top because they combine one-to-many access with concentration: a single compromised outsourcer, cloud tenant or core-banking vendor creates correlated exposure across several banks, as the SolarWinds, MOVEit (via service providers) and CrowdStrike cases illustrate. D-SIBs are the main target but not the most vulnerable: their defensive capacity offsets their exposure, yet their size makes any successful intrusion systemically relevant. Payment FMIs are high-value but low-vulnerability: limited internet exposure and strong controls place them tenth, which is consistent with the absence of documented intrusions into core RTGS platforms in our incident set.

10.2.0.1 Answer to RQ5.

The likely targets in Thailand are the D-SIBs, payment infrastructure, digital-asset platforms and the BOT itself. The groups most at risk are shared IT providers, D-SIBs and SFIs. The most vulnerable entry points are smaller non-bank payment firms, new virtual banks with concentrated cloud dependence, and customers’ devices—the last mainly as a fraud channel that seldom needs zero-days. Whether Thai banks “survive” depends less on whether a Thailand-specific zero-day exists than on how quickly Thai institutions close exposure to global ones, and on whether a compromise at one shared provider can be contained.

11 Scenario simulation

Tables 11–13 give the model’s structure, calibration and scenarios. The base event rate of 86.7 exploited-vulnerability events per year across six enterprise layers comes from KEV. Edge and VPN products carry the highest rate (28.3 per year) and, with MFT, the highest zero-day share (0.61 and 0.67). For n-days, the median empirical KEV lag in these layers is 64 days. Scenario S0 represents conditions before 2022 (fewer zero-days, a 32-day time-to-exploit). S1 represents current conditions. S2 triples zero-day discovery and attacker throughput and shortens time-to-exploit to one day. S3 adds AI-enabled defence: patch times cut by 65%, attack success reduced by 40% through detection, and 30% of bugs pre-empted. S4 adds vendor concentration to S2. S5 combines S3 with diversified vendor shares.

11.1 Results

Table 14 and Figure 11 report 4,000 simulated years per scenario. Under current conditions (S1), the model gives about 5.5 compromised institutions per year, a 26.6% annual probability that at least one D-SIB is compromised, a 3.0% probability of an FMI compromise and a 5.0% probability of a systemic event. The absolute levels depend on assumptions. The comparisons across scenarios are the informative part:

• AI offence multiplies systemic risk. S2 raises the probability of a systemic event to 24.9%, 5.0 times S1. Across the robustness grid (Table 15), the ratio ranges from 4.0 to 6.8.

• AI defence recovers most of the loss. S3 cuts the S2 probability to 9.8%. Across the grid, defence removes 50–75% of the systemic probability under AI offence (S3/S2 between 0.25 and 0.50).

• Concentration amplifies. With a dominant vendor holding 60% of each layer, S4 reaches 35.2%, 36–64% above S2 across the grid.

• Diversification helps less once defence is strong. The S5/S3 ratio ranges from 0.67 to 1.15, so its benefit is not robust when defence is already effective.

Figure 12 varies the offence multiplier and the patch-time factor jointly. Offence dominates: at today’s patch speed, the probability of a systemic event rises from 6% to 45% as the multiplier goes from 1 to 5. Faster patching alone has a modest effect. At a multiplier of 5, cutting patch times by 75% lowers the probability only from 45% to 40%. When copycat exploitation starts within a day of disclosure and most damaging events begin as zero-days, the decisive defences act before disclosure: pre-emptive discovery, smaller internet-facing exposure, detection and segmentation. This is the main operational lesson of the model.

12 Implications for central banks and the Bank of Thailand

12.1 Should central banks pay attention?

Yes, and the reason is specific to the evidence. Central banks meet this risk in three roles. As prudential supervisors, they face a population of banks whose exposure is correlated through shared commercial products and providers, and whose patch workload has multiplied. As operators and overseers of payment infrastructure, they run or supervise the nodes whose impairment turns an operational event into a systemic one (CPMI–IOSCO 2016; Eisenbach et al. 2022). As targets, they hold sensitive supervisory and market data on the same commodity corporate IT that was compromised at the RBNZ and the EBA. AI changes each role: it multiplies discovery, shortens the effective response window, and gives defenders tools that are only effective if deployed sector-wide.

12.1.0.1 Is the BOT exposed?

The BOT’s core settlement infrastructure scores low on vulnerability in our framework. Its corporate and supervisory IT, however, has a high target value and a moderate exposure profile (rank 9 of 12, risk 0.43), and it follows the pattern of the documented central-bank intrusions. The probability that the BOT experiences an intrusion through a commercial-product vulnerability over a multi-year horizon is not negligible. The probability that such an intrusion disrupts settlement is much lower, provided segmentation and contingency arrangements hold.

12.2 Ten implications

1. Supervise patch latency on internet-facing products. Treat time-to-remediate for known-exploited vulnerabilities in perimeter, MFT, mail and IT-management products as a prudential metric, with sector-wide reporting of patch-latency distributions and remediation targets measured in hours to days, not patch cycles.

2. Build a shared-vendor concentration register. Map which products and providers each institution uses in critical layers, compute concentration, and require substitution and isolation plans for dominant vendors. The model shows that concentration amplifies AI-driven risk by 36–64%.

3. Oversee critical third parties directly. Shared IT and cloud providers rank highest in the Thai framework. Regimes for critical ICT third parties in other jurisdictions (European Parliament and Council 2022; Bank of England et al. 2024) offer templates for direct oversight, testing and incident obligations.

4. Move defence before disclosure. Because patch speed alone has diminishing returns, prioritise reducing internet-facing exposure, segmenting corporate IT from payment operations, detecting exploitation, and pre-emptive discovery in the software banks depend on.

5. Pool AI-enabled defensive capacity. Few Thai institutions can run frontier-model vulnerability research on their own. A sector capability—for example through TB-CERT with BOT support—could apply AI-assisted review to commonly used banking software, mobile-banking SDKs and cryptographic dependencies, and could coordinate access to restricted defensive programmes offered by AI developers (Anthropic 2026a). Access to frontier models can itself be affected by foreign policy decisions: in June 2026 access to two frontier model families was temporarily suspended to comply with U.S. export controls and restored on 1 July (Anthropic 2026b). Contingency for such dependencies belongs in the plan.

6. Prepare for the volume shock. With advisories quadrupling, institutions must triage by exploitation evidence (KEV-type catalogues, exploitation prediction) rather than by severity scores alone (Jacobs et al. 2021). A Thai or ASEAN exploited-vulnerability catalogue, mapped to products used locally, would help.

7. Stress-test payment infrastructure for correlated impairment. Scenario exercises should assume that several RTGS and retail-payment participants are impaired at once by a shared-product compromise, test offline and contingency settlement, and rehearse the kind of manual workaround used after the 2023 ICBC Financial Services incident.

8. Harden the central bank’s own corporate IT. Apply the lessons of the RBNZ and EBA cases: minimise on-premise exposure of file-transfer and mail systems, enforce zero-trust access for supervisory data exchange, and keep settlement systems isolated from corporate networks.

9. Govern AI platforms inside banks. LLM gateways and workflow-automation tools became a KEV category in 2026. Banks should inventory them, treat internet-facing deployments as critical, and apply the same patch and access controls as for other perimeter software.

10. Improve data and international coordination. Adopt common incident-reporting formats (Financial Stability Board 2023, 2025), collect Thai patch-latency and incident data to calibrate models like ours, and share threat intelligence through regional and BIS channels. Plan for hardware trust anchors as well: inventory HSM, secure-element and cryptographic-library dependencies and build crypto-agility into digital-asset, tokenisation and CBDC projects.

12.2.0.1 Answer to RQ6.

Central banks should treat AI-accelerated vulnerability discovery as a financial-stability issue now. The aim is not to predict a specific attack. Under plausible parameters, the combination of a disclosure shock, correlated vendor exposure and AI-scaled offence raises systemic risk several-fold, and most of that increase can be offset only by coordinated, sector-wide defence.

13 Limitations

• Measurement of AI involvement. Credits are incomplete (43% coverage in 2026) and absent for the largest commercial CNAs. Tier 2 is a proxy. AI assistance at level L1 is invisible. We cannot attribute the disclosure surge to AI causally.

• KEV as ground truth. KEV is curated by a U.S. agency, focuses on vulnerabilities relevant to U.S. federal systems, and lists exploitation when evidence becomes available. Listing lag is not the date exploitation began. Thai-specific exploitation may differ.

• Classification. Product categories and software domains come from keyword rules. About 7% of KEV entries and a larger share of AI-credited CVEs are unclassified.

• Curated cases and benchmarks. The incident and hardware sets are purposive and author-coded from public reporting, and the industry zero-day counts used as benchmarks were taken from secondary reporting. All should be verified against primary sources.

• Thai framework. The scores are structured judgements at group level, made without confidential supervisory data. They should be replaced with supervisory evidence where available.

• Simulation. The model is stylised. Payment shares, patch speeds, success and disruption probabilities are assumptions, and only event rates are calibrated to data. Results are comparative across scenarios, not forecasts.

• Timing. The data are a snapshot as of 12 November 2026. Rapid change in AI capability may make the trajectory estimates obsolete quickly.

14 Conclusion

The economics of zero-days are changing. In 2026, vulnerability disclosure in major commercial software rose several-fold, AI systems were credited on more than a thousand CVEs, and the credited share doubled every few months. So far, exploitation has grown more slowly than discovery, which suggests that defenders are capturing much of the early benefit. The incident record shows that zero-days reach banks through the commercial products and service providers they share with everyone else. For a system such as Thailand’s, the main systemic vulnerability is therefore correlated exposure through shared vendors and providers, not a bespoke attack on core payments. Our scenarios suggest that AI-scaled offence could multiply systemic risk several times over, and that coordinated AI-enabled defence, reduced exposure and attention to concentration can recover most of that loss. Central banks are positioned to organise that coordination, and the evidence argues for starting now.

14.0.0.1 Data and code availability.

All scripts, curated datasets, derived tables and figures are provided in the accompanying repository. Raw inputs are public: CVE List V5 (CVEProject/cvelistV5) and CISA KEV (cisagov/kev-data).

14.0.0.2 Acknowledgement of tools.

Data processing, analysis and drafting were assisted by an AI system; the author is responsible for the content.

15 AI-credit lexicon

Patterns are matched case-insensitively against the concatenated credit strings of each CVE record after removing the exclusion patterns (a human researcher whose given name is Claude; a username containing “gpt”; the brand name of a human bug-bounty programme containing the letters “AI”). When several patterns match, the lowest tier wins.

16 KEV category rules and banking-relevance weights

17 AI vulnerability-discovery milestones

18 Curated financial-sector incidents

19 Reproducing the results

1. bash run_all.sh downloads the two public inputs (CVE List V5 bulk release; CISA KEV JSON) and runs src/s01–s09.

2. s01 flattens CVE records; s02 flags AI-credited CVEs; s03 builds the KEV panel; s04 produces the empirical tables and outputs/key_numbers.json; s05 summarises the curated cases; s06 scores the Thai groups; s07 runs the simulation; s08 draws figures; s09 writes the LaTeX tables.

3. cd paper && latexmk -pdf main.tex compiles the paper.

Results for a later snapshot will differ, because both sources are updated continuously. Seeds are fixed, so a given snapshot reproduces exactly.