Resumen

  • La captura del índice oficial de la EEF del 30 de octubre muestra 370 registros de CVE con fecha de 2026 y nueve de 2025. El volumen publicado es unas 41 veces mayor; la cifra no cuenta reparaciones ni hallazgos atribuibles a la IA.
  • En RIPE 93, Alistair Woodman esperaba más de 500 CVE en 2026 y pidió a las empresas usuarias que contribuyan a pagar la seguridad de los paquetes.

Woodman cerró su charla en RIPE 93 con una petición para las empresas que usan paquetes de Elixir, Erlang y Gleam: ayuden a financiar el trabajo de seguridad. Tres días después, el índice público de la Erlang Ecosystem Foundation (EEF) ya mostraba 370 CVE fechados en 2026. Esa cifra deja claro el tamaño de la lista; no dice cuándo llega un arreglo a los paquetes que ejecutan los usuarios.

A las 08:59 UTC del 30 de octubre, la lista registraba 370 CVE publicados en 2026 y nueve en 2025. Son unas 41 veces más entradas. El índice no indica qué versión corrige cada vulnerabilidad ni cuánto tardó la verificación. La fecha del aviso está a la vista; el momento en que el paquete volvió a estar corregido, no.

Woodman había presentado su previsión el 27 de octubre, en el grupo de trabajo de Seguridad de RIPE 93. Según explicó, la EEF cubre más de 20.000 paquetes de Elixir, Erlang y Gleam, usados con regularidad por unas 100.000 personas y por al menos 5.000 empresas conocidas por la fundación. Estimó que el año anterior había producido cerca de diez CVE y esperaba superar los 500 en 2026. Describió una carga de trabajo más de cincuenta veces mayor. El índice cuenta avisos publicados; la previsión de Woodman contaba el volumen de trabajo que esperaba su equipo.

Woodman dijo que las vulnerabilidades ya existían y que el análisis asistido por IA facilitó encontrarlas. Después del hallazgo, alguien debe confirmar que el informe describe un fallo, cambiar el código, publicar una versión y comprobar que el arreglo funciona. El contador registra el aviso, no esa cadena de trabajo.

La CNA de la EEF tiene cinco responsables principales, dijo Woodman, pero dos personas realizaban la mayor parte del trabajo con CVE y de la investigación sobre IA. La fundación prueba agrupar descubrimientos por proyecto para que quienes mantienen el código reserven tiempo y atiendan varios problemas a la vez. Así, el informe deja de ser una interrupción aislada y entra en un bloque de trabajo que puede terminar en una versión concreta.

La política pública de la EEF fija dos plazos iniciales: confirmar la recepción en un máximo de dos días laborables y evaluar el informe dentro de los dos días laborables siguientes a esa confirmación. Para una vulnerabilidad no pública de un paquete Hex dentro del alcance de la CNA, si el mantenedor no responde en 14 días, la EEF dice que seguirá adelante con la publicación. La divulgación coordinada puede durar hasta tres meses. Son relojes para recibir y publicar el aviso; ninguno mide el tiempo hasta la versión corregida.

El índice público guarda el identificador, el título, los detalles y las fechas de publicación o actualización. No conecta cada CVE con la respuesta del mantenedor, la versión reparada y la fecha de verificación. Ese recorrido permitiría saber si el aumento de divulgaciones también reduce el tiempo durante el que los usuarios quedan expuestos a una versión vulnerable.

Woodman forma parte de la junta de la EEF y pidió a las empresas que aprovechan el ecosistema que paguen por su trabajo de seguridad. Las compañías usan paquetes mantenidos por otros; la verificación y el arreglo recaen en las personas que conocen el código. Publicar una CVE activa el aviso. Publicar y adoptar una versión corregida cierra el paso operativo. El índice ya cuenta la primera etapa; la siguiente cifra útil debe seguir la segunda.

Fuentes: sesión de RIPE 93; transcripción oficial; páginas de la EEF sobre la CNA, su alcance, la política de seguridad y el índice de CVE; junta de la EEF.