Some say that vulnerability discovery is the bread and butter of cyber security, so most professionals keep a pulse on the various databases for Common Vulnerabilities and Exposures (CVEs), such as CVE.org or CISA almost like a professional trader watching candlesticks to decide where to invest his money.
If you are a CISO and you are affected by any vulnerability released you will have to patch fast or given the current median exploitation time nearing almost the second scale - the time it takes an attacker to use a software vulnerability against your company- it’s important to react fast.
So naturally when you see this spike in July as found out by Epoch AI in this suggestive blogpost (Epoch AI's analysis of the CVE severity spike)[1] everybody starts to panic and this case our human brains start to look for an explanation and we look for culprits an easy one would be the only obvious: it must be the Mythos LLM release from Anthropic that has incredible cyber offensive capabilities.
Now at Polybridge the old adage stays the same: correlation doesn’t imply causation, sometimes it does but most of the time it doesn’t.
We are currently writing a full thorough analysis of the impact of AI models on CVE vulnerabilities - that article is coming soon - and so we are using the same methodology here plus we also did some deep down analytics to figure out WHY and WHAT caused that spike.
Step1: reproduce the graph
Yes there are some important details here to reproduce it: there are only 21 vendors here and only critical and high level vulnerabilities are considered, we are not going to question the cherry picking of such vendors and criticality for now, we just want to go with their criterias.
Instead of using CVE.org which has some data quality problems we use the most reliable VulnCheck free database to build a similar chart as you see in Figure 2.
We actually found a larger spike
| Severity | epoch.ai (cve.org) | Us (VulnCheck) | Difference |
|---|---|---|---|
| Critical | 371 | 391 | +20 (+5.4%) |
| High | 1,175 | 1,247 | +72 (+6.1%) |
| Total | 1,546 | 1,638 | +92 (+5.9%) |
So: VulnCheck found 92 more Critical+High CVEs than Epoch's CVE.org-sourced figure for June 2026 — about 6% higher across the board so actually this should even be more positive on the hypothesis of a large spike caused by AI![2]

Let’s unwrap a few key things that Epoch AI has missed:
- A pre-existing, multi-year secular growth trend in CVE disclosure volume, already mentioned in our other article: the whole ecosystem's CVE count has been climbing since well before 2026, driven partly by more CNAs entering the ecosystem (e.g., Linux becoming its own CNA in 2024 alone added 9,067 CVEs) and partly by increased reporting activity generally. Fitting a negative binomial interrupted time series, correcting for overdispersion reveal a trend break that best fit the data is November 2025 which is 5 months before the Mythos April 2026 preview announcement.
- Of July's 3,000 crit+high total, Oracle alone contributes 747 (25%) - a 128× jump over Oracle's own 2025 monthly average. We checked the raw records directly: these are genuine, distinct product CVEs (Oracle E-Business Suite, Fusion Middleware, PeopleSoft, WebLogic, etc.), published on Oracle's routine quarterly Critical Patch Update day (2026-07-21)
- With or without you (like the song) as in Oracle the trend was already started in November 2025 as described in Figure 2.b

So it is clear that there was already a pre-existing trend in November 2025 but there is additionally a larger than usual spike in Oracle vulnerabilities for July, so this is important to investigate as it may lead us to somewhere interesting.
The Oracle has spoken
Oracle's own history shows a stable ~15–30 crit/high per quarter for four straight years before this. Meanwhile 5 of the 21 organizations (Google, Intel, AMD, Qualcomm, OpenSSL) show flat or declining counts over the same window - not what a broad, industry-wide capability effect should look like.
Keep in mind that Oracle alone accounts for 25% of July 2026's Critical+High CVE total across the 21-organization set as described in Figure 3.[2]

Oracle's fixed quarterly release cadence (Jan/Apr/Jul/Oct) has made these months seasonally higher every year since 2022, and the July-over-June ratio has been climbing steadily for years (0.67× in 2022 → 1.03× → 1.54× → 1.77× → 1.83× in 2026). So a July bump is normal and has been growing on its own trend — 2026 continues that pattern rather than inventing it. What the trend doesn't explain is the absolute size of this particular jump, which overshoots it.
Attack of the CWE clones?
Comparing the CWE (bug-class) composition of the spike against the 2022–2025 historical baseline: same categories, same rough proportions - buffer overflows, path traversal, injection, cross-site scripting, all in similar shares. No new or unusual cluster of vulnerability types emerged. This argues against "AI found a fundamentally new kind of bug" and for "more of the ordinary kinds, at higher volume."
Unfortunately Oracle in their wisdom they never have tagged their vulnerabilities with CWE in every period we checked so this is why this chart does not include Oracle, we simply don’t have the time to classify those into CWE for now but if you do let us know in the comments.
Anyway in Figure 4 you can see there is nothing unusual about the distribution of CWE over time that may hint to some clever AI discovery spike.

And if you are not familiar with the CWE nomenclature here’s a table
| CWE ID | Name | Plain description |
|---|---|---|
| CWE-416 | Use After Free | Code keeps using a piece of memory after it's been freed/released, which can crash the program or let an attacker run their own code in that memory space. |
| CWE-122 | Heap-based Buffer Overflow | A program writes more data into a heap-allocated memory buffer than it was sized for, overwriting adjacent memory — a classic route to crashes or code execution. |
| CWE-22 | Path Traversal | An attacker manipulates a file path (e.g. ../../etc/passwd) to access files outside the directory the application intended to restrict them to. |
| CWE-79 | Cross-Site Scripting (XSS) | User-supplied input gets rendered into a web page without proper sanitization, letting an attacker inject scripts that run in other users' browsers. |
| CWE-94 | Code Injection | An application lets attacker-controlled input get interpreted as code (not just data), letting them run arbitrary logic on the server. |
| CWE-20 | Improper Input Validation | A catch-all: the software doesn't properly check that input is well-formed, correctly typed, or within expected bounds before using it. |
| CWE-918 | Server-Side Request Forgery (SSRF) | An attacker tricks the server into making HTTP requests to an unintended destination (e.g. internal-only services) on the attacker's behalf. |
| CWE-78 | OS Command Injection | Similar to CWE-94 but specifically: unsanitized input reaches a system shell command, letting an attacker run arbitrary OS commands. |
These are all long-established, well-known bug classes - nothing here is a novel or unusual category. That's exactly the point the chart is making: the June–July 2026 spike is made of the same kinds of bugs the ecosystem has always found, just more of them, not evidence of some new class of AI-discovered vulnerability.
Reserve your ticket on the CNA cho-cho train!
Every CVE normally moves through the same lifecycle: someone (a researcher, a vendor's own engineer, an automated tool) finds a vulnerability and reports it to a CNA - a CVE Numbering Authority, which for a vendor like Oracle or Apache is often the vendor itself. The CNA reviews the report and, once satisfied it's real, reserves a CVE ID for it; at this point the ID exists and its reservation date is logged, but the technical details are usually kept private while a fix is developed. Only later - once a patch is ready, or a disclosure deadline is reached - does the CNA publish the full record, and that publish date is what every count elsewhere in this document is measuring.[5]

That gap matters for a specific reason: publication date isn't discovery date, and a batch of old, quietly held issues suddenly published all at once (a "backlog dump") could look identical, on a chart of publish dates alone, to a genuine new wave of discovery. The reserved date is the earliest point in that lifecycle we can actually see publicly, so it's the closest available proxy for "when this entered the pipeline" and re-checking the spike meant that 88% of the spike batch was reserved within about three weeks of its own publication, so there's no hidden months-old backlog being dumped.
Oracle's July batch, though, shows an almost perfectly uniform 13-day reserve-to-publish lag across essentially all 1,108 of its records - a textbook signature of bulk ID reservation immediately before a scheduled release, not staggered organic discovery.
What’s happening in Oracle!
Since Oracle has provided the largest spike of 25% then what is the most likely reason?
Oracle's July 2026 Critical Patch Update covered 1,235 unique CVEs (1,449 total patches across 32 product families) - by a wide margin its largest CPU release ever (228 Critical, 613 High, 332 Medium, 62 Low, per Tenable's count; our own independent extraction found 747 crit+high, roughly 10–15% lower, likely a methodology/timing difference in CVSS-source preference worth flagging rather than resolving here).[4]
Oracle E-Business Suite (410 patches) and Fusion Middleware (355 patches) accounted for over half the release, with a large share remotely exploitable without authentication.[4]
The Register's coverage (2026-07-23) reports the actual mechanism directly: Oracle announced in April 2026 that it would use AI internally to find security flaws, and only 64 of the 1,449 patches (4.4%) came from external researchers - meaning the vast majority were found by Oracle's own internal (AI-assisted) auditing.[3]
Security researchers quoted in the piece frame this as an industry-wide shift, not an Oracle-specific event: Matei Badanoiu (Pentest-Tools.com) said "bumper batches of security updates are likely to become the norm, owing mainly to AI-assisted bug hunting," and Microsoft separately warned in July 2026 that customers should expect higher patch volumes "due to AI-enhanced vulnerability detection." Oracle also introduced monthly Critical Security Patch Updates starting May 2026, a process change to handle the increased throughput.[3]
Why this matters for the Mythos claim specifically: this is real evidence that AI is contributing to the vulnerability-disclosure increase - but through a defensive mechanism (a vendor auditing its own code more aggressively), not an offensive one (attackers or researchers using Mythos's capability to find more bugs in other people's software).
Oracle's April 2026 AI-tooling announcement is not confirmed to involve Anthropic or Claude at all - the reporting doesn't name a specific model - and it lands in the same month as Mythos's own preview announcement, which makes the two easy to conflate but doesn't establish either caused the other.
It also doesn't resolve the November 2025 timing problem: Oracle's own AI-tooling announcement (April 2026) is itself several months after the point where the broader 21-org trend statistically starts accelerating.
Lessons learned
Well in all honesty, Epoch.AI wasn't far off but conflated and ignored various data trends:
- There was already a trend of growing vulnerabilities from November 2025 across all 21 vendors.
- For Oracle, there was a change in their patch lifecycle, and they did publish more CVEs in July via a bulk release.
- Oracle did use, as described in a public announcement, AI tools for vulnerability discovery (not patching): this is a defender-side effect, not an attacker-side one!
References
- Epoch AI. “Disclosure of serious cyber vulnerabilities spiked around the release of Claude Mythos Preview.” July 2, 2026. View source
- VulnCheck. Vulnerability intelligence database. View source
- The Register. “Oracle drops 1,449 security patches like it's the new normal.” July 23, 2026. View source
- Tenable. “Oracle July 2026 Critical Patch Update Addresses 1235 CVEs.” View source
- CVE Program. CVE process. View source