Sala de seguridad con una pantalla que muestra una curva ascendente de vulnerabilidades

«Octubre negro»: las CVE publicadas en 2026 ya casi duplican todo 2025

La base de datos nacional de vulnerabilidades de Estados Unidos (NVD), que mantiene el NIST, ya ha publicado en 2026 más CVE que en todo 2025: 88.602 a 24 de octubre, frente a 49.972 en el año anterior. Las cifras, extraídas directamente de la API de NVD por David Carrero, editor de OpenSecurity y de carrero.es, ayudan a poner contexto a la expresión «octubre negro» que circula estos días por LinkedIn: no hay un pico especial en las últimas semanas, sino una curva que lleva meses disparándose.

Las claves del aumento de vulnerabilidades CVE en 2026 en 30 segundos

  • NVD suma 88.602 CVE publicadas en 2026 hasta el 24 de octubre, 1,8 veces las 49.972 de todo 2025.
  • Septiembre de 2026 marcó récord con 15.074 CVE en un solo mes, frente a 4.415 en enero de 2025.
  • El salto viene de meses atrás; las últimas 72 horas no muestran un pico especial.
  • La IA ya encuentra fallos a escala, y NIST prioriza qué CVE analiza.
  • PHP2Shell exige actualizar PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35.

La expresión «octubre negro» no es un nombre oficial ni responde a una campaña concreta. Agrupa una sucesión de incidentes de las últimas semanas, desde fallos críticos en software muy extendido hasta paquetes comprometidos en repositorios de código. Los datos de NVD sugieren que el problema de fondo es de volumen y no de un mes en particular. Carrero lo resumió en X con una frase: «No es una sensación. Es una curva».

Gráfico de CVE publicadas cada mes en la base de datos NVD entre 2016 y 2026, con récord de 15.074 en septiembre de 2026
Imagen: carrero.es

Lo que dicen los datos de NVD

El recuento se hace por fecha de publicación en NVD, en horario UTC, y refleja el estado de la base de datos en el momento de la consulta, el 24/10/2026 a las 10:56 (hora de Madrid). En 2025 se publicaron 49.972 CVE, unas 2,6 veces las 19.222 de 2020. Entre enero y septiembre de 2026 se publicaron 74.838, frente a 36.824 en el mismo periodo de 2025, es decir, algo más del doble.

La serie mensual muestra un crecimiento sostenido desde 2016, con algún pico aislado, y una aceleración clara a partir de mediados de 2026. Septiembre cerró con 15.074 CVE, el máximo histórico de la serie, y octubre sumaba 13.764 a falta de una semana. Para comparar, enero de 2025 se quedó en 4.415. Las últimas 72 horas no aportan un salto especial: el aumento viene de lejos.

Hay un matiz importante al leer estas cifras. Una CVE es un identificador para un fallo concreto, no un ataque. Muchas afectan a software poco usado o tienen una gravedad baja, y el número de registros también depende de cuántas organizaciones pueden asignar identificadores y de cómo trabajan. Más CVE no significa automáticamente más ataques, pero sí más trabajo para quien tiene que evaluar y aplicar parches.

La inteligencia artificial encuentra fallos a escala

Parte de la explicación está en las herramientas. En los dos últimos años se han acumulado los ejemplos de IA aplicada a la búsqueda de vulnerabilidades: el agente Big Sleep de Google encontró un fallo explotable en SQLite, OSS-Fuzz detectó con ayuda de modelos de lenguaje vulnerabilidades en OpenSSL, la plataforma autónoma XBOW llegó a lo más alto de la clasificación de HackerOne en Estados Unidos y DARPA celebró la final de su AI Cyber Challenge (AIxCC). Anthropic, por su parte, asegura haber comunicado 6.157 vulnerabilidades en 591 proyectos de código abierto, según sus datos a 2 de octubre de 2026.

El volumen tiene consecuencias. NIST ya ha reconocido que no puede analizar en detalle todas las CVE que llegan y prioriza cuáles enriquece con información de gravedad y productos afectados. Para los equipos de seguridad, eso significa que no todas las entradas de NVD llegarán con la misma calidad de datos y que conviene cruzarlas con los avisos de los propios fabricantes.

El caso más sonado de este mes es PHP2Shell: dos fallos críticos en el núcleo de PHP, identificados como CVE-2026-109618 y CVE-2026-109619 con una puntuación CVSS de 9,2, que afectan a versiones desde la 5.4 y que fueron encontrados con ayuda de modelos de IA por Wiz Research, OpenAI Codex Security y Calif. PHP publicó los parches el 21/10/2026. OpenSecurity contó cómo PHP corrigió dos fallos críticos que se filtraron antes del parche, WPDirecto explicó qué suponen para WordPress y qué hacer y Revista Cloud repasó qué distribuciones y paneles ya han parcheado PHP.

Qué hacer ahora

Para quien desarrolla o administra sistemas, la prioridad inmediata es actualizar PHP a las versiones 8.5.12, 8.4.27, 8.3.36 o 8.2.35, según la rama, y reiniciar los procesos de PHP-FPM o los workers que mantengan el intérprete cargado, porque un paquete actualizado no protege hasta que el proceso se reinicia. También conviene revisar las dependencias de los proyectos y, si se ha usado algún paquete comprometido en las últimas semanas, rotar claves, tokens y credenciales que hayan podido quedar expuestos.

Para el usuario corriente, las recomendaciones son las de siempre, y siguen siendo las que más protegen: cambiar las contraseñas repetidas en varios servicios, activar la verificación en dos pasos donde esté disponible y vigilar los cargos de la tarjeta. Carrero cerraba su análisis con una idea que resume el momento: «La IA encuentra fallos más rápido que nunca. Parchear sigue siendo cosa nuestra».

Preguntas frecuentes

¿Cuántas CVE se han publicado en 2026?

Según la base de datos NVD, 88.602 hasta el 24 de octubre de 2026, frente a 49.972 en todo 2025.

¿Qué es el «octubre negro» de la ciberseguridad?

Es una expresión que circula en redes para agrupar varios incidentes de octubre de 2026. No es un nombre oficial ni una campaña única.

¿Por qué hay tantas vulnerabilidades nuevas?

Entre otros motivos, porque las herramientas de IA ya encuentran fallos a gran escala. Anthropic, por ejemplo, dice haber comunicado 6.157 vulnerabilidades en 591 proyectos de código abierto.

¿A qué versión hay que actualizar PHP por PHP2Shell?

A PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, según la rama, y después reiniciar los procesos de PHP.

Fuentes:

Scroll al inicio