Summary

  • EEF’s official CVE index contained 370 records dated 2026 and nine dated 2025 in the 30 October snapshot. That is about 41 times as many published records, not a count of fixes or AI discoveries.
  • At RIPE 93, Alistair Woodman said the EEF expected more than 500 CVEs in 2026. He described the expensive step after discovery: getting package maintainers to assess, repair and verify code.

The number is climbing. The repair clock is not public.

The Erlang Ecosystem Foundation’s machine-readable CVE index held 370 records with 2026 publication dates at 08:59 UTC on 30 October. It held nine from 2025. That is roughly a 41-fold increase in records. It does not say how many affected packages shipped a verified fix, or how long maintainers took to get there.

Woodman gave the forecast three days earlier at the RIPE 93 Security Working Group. The EEF, he said, covers more than 20,000 Elixir, Erlang and Gleam packages. He estimated about 100,000 regular users and at least 5,000 corporate users known to the foundation. The group had counted about ten CVEs the previous year; he expected the 2026 total to pass 500. He called that a fifty-fold rise in load and said the vulnerabilities had been present before AI-assisted analysis made them easier to find.

The EEF is a CVE Numbering Authority. Its security working group assigns identifiers and coordinates disclosure for in-scope projects. Woodman described a team of five principals, with two people handling most of the CVE work and AI research. The tools can turn up findings quickly. A maintainer still has to decide whether the report describes a real flaw, write a correction, publish a release and make sure the correction addresses the problem.

That last sequence is where a count stops being a security result. Woodman said the EEF was experimenting with batching reports by project. Instead of interrupting a maintainer each time a new issue arrives, the team can set aside a focused period to work through a group of findings. It is a practical response to a labor problem: discovery can be parallelized; a project’s repair work remains attached to the people who know its code.

The EEF’s published policy gives vulnerability reports a two-business-day acknowledgement target and a two-business-day assessment target. For a non-public vulnerability in an in-scope Hex package, the CNA says it will proceed with publication if maintainers do not respond within 14 days; coordinated disclosure may run for up to three months. Those rules put dates around intake and disclosure. They do not report the time from a finding to a fixed release.

The EEF index records each CVE identifier, title, details and publication or update date. Its public data does not supply a per-record maintainer response, fixed version or verification time. That missing repair record would show whether the surge is closing exposure as quickly as it creates disclosures.

Woodman sits on the EEF board and asked companies that rely on the ecosystem to help fund security work. The request follows the arithmetic: thousands of organizations can depend on open packages, while only a small group of people carries much of the disclosure and research work. A public CVE is a useful alert. The next useful number is the one attached to the release that fixes it.

Sources: RIPE 93 session; official transcript; EEF CNA overview, scope, security policy and CVE index; EEF board members.