42 días del primer ataque al KEV: dónde estaba la señal

La primera señal pública no apareció en X ni en ningún servicio que vigile identificadores CVE. Apareció en el gestor de incidencias de GitHub del propio proyecto. El 11 de septiembre de 2026, un administrador de Nextcloud publicó registros de acceso que mostraban ataques contra la aplicación que integra el servidor de documentos de Collabora (nombre técnico richdocumentscode). Eso fue 32,5 días antes de que existiera un CVE público y 42,2 días antes de que la agencia estadounidense CISA incluyera el fallo en su catálogo de vulnerabilidades explotadas conocidas (KEV). El 26 de octubre de 2026, entre las 10:17 y las 10:56 (hora de Singapur, SGT), lanzamos 60 peticiones a EveryInfra, 52 de ellas cobradas, por un total de 0,029576 USD. Después cruzamos los resultados con el historial de cambios de NVD, la serie diaria de EPSS y otros 24 CVE que entraron en el KEV en las mismas cuatro semanas.

El resultado es claro. En X, una búsqueda por el identificador devolvió 106 publicaciones: ninguna antes del CVE y 80 después del KEV. Las etiquetamos una a una con una regla escrita de antemano (una sola pasada, sin segundo etiquetador) y el 93,4 % eran republicaciones, bots o promoción. El campo SSVC del registro, el que leen las máquinas, dijo «no explotada» durante 9 días, y EPSS se quedó en el 1,2 % durante 10 días. Para un equipo en España o en América Latina hay un dato más: a 26 de octubre, la ficha en español de INCIBE seguía con la descripción «Pendiente de traducción».

En este artículo, un «proceso auditable de la señal a la respuesta» significa lo siguiente. Cada día se consulta, por el nombre de los componentes que uno usa (no solo por el CVE), el gestor de incidencias del proyecto, el foro del fabricante y algunas redes sociales. Se guarda cada respuesta original con su hora, se cruza con el inventario de activos, se quita el ruido y se decide si actualizar, retirar o investigar. Cada paso queda registrado: quién, cuándo, con qué prueba y qué hizo. El proceso dice qué atender primero y por qué; no predice ataques ni sustituye los avisos del fabricante.

Qué dejamos fuera

Solo escribimos sobre vigilancia y respuesta. No describimos métodos de ataque, detalles de explotación ni formatos de petición. Cuando hablamos de una intrusión, solo contamos dónde la publicó un administrador, cuándo y qué dijo, para que se puedan comprobar las horas. Ocultamos los nombres de cuentas personales y solo nombramos cuentas institucionales (CISA, CERT.LV, el CSIRT de Italia, Censys) y a los mantenedores que hablan en nombre del proyecto. No juzgamos las decisiones de divulgación de ningún fabricante: solo ponemos en paralelo las horas de los registros públicos.

Para quien trabaja en Europa, el KEV no es una obligación legal, pero se ha vuelto una referencia práctica: muchas herramientas lo usan como filtro y muchos equipos solo abren ticket cuando un fallo entra en él. En Estados Unidos, la directiva BOD 26-04 da a las agencias federales un plazo calculado a partir del KEV, la automatización del ataque, el impacto técnico y la exposición a internet. Para este CVE el plazo fue de tres días con revisión forense, el más estricto de la directiva. Ese reloj empieza en el KEV, pero los ataques empezaron 42 días antes, y este artículo trata de ese hueco.

Los criterios que fijamos antes de la primera petición

El 26 de octubre a las 10:16 (hora de Singapur), antes de la primera petición, escribimos cinco criterios en nuestro registro de comprobación. A las 10:29 (hora de Singapur), antes de abrir los resultados del corte transversal, añadimos dos más. La tabla los pone junto a su resultado; cada cifra tiene su fuente en las secciones siguientes.

El criterio 2 necesita una aclaración. En X, las dos formas de buscar (por identificador y por «producto + síntoma») dieron cero resultados relacionados antes del CVE, así que X por sí solo no muestra la diferencia. La diferencia viene del gestor de incidencias y del foro, que no son redes sociales pero sí son públicos y se pueden vigilar por nombre de componente. En el criterio 6 escribimos «en lo formal» porque un día de ventaja y treinta días de ventaja no valen lo mismo para responder. Más adelante desglosamos esa cifra.

El caso principal: de la primera línea de registro al KEV

El fallo es el CVE-2026-110447. Según el aviso de seguridad de Collabora, solo afecta a una aplicación opcional de Nextcloud, «Collabora Online - Built-in CODE Server», la que ejecuta una copia del servidor de documentos dentro del propio servidor de Nextcloud. Los servidores Collabora Online independientes no están afectados, y el aviso del foro de Nextcloud añade que tampoco lo están las instalaciones con Docker o con paquetes de la distribución. La corrección es la versión 26.4.303, y el aviso insiste en que desactivar la aplicación no basta: hay que actualizarla o eliminarla. El registro de NVD dice que el fallo fue «explotado en el entorno real en septiembre y octubre de 2026».

Reunimos todas las horas que los registros públicos dan al segundo, siempre desde las API originales y no desde resúmenes. La API de incidencias de GitHub da el campo created_at de la incidencia y de cada comentario. El foro de Nextcloud funciona con Discourse (documentación de su API): basta añadir .json a la dirección del hilo para obtener la hora de cada mensaje. Las horas de reserva y publicación del CVE salen de la API del registro en CVE.org; los cambios de cada campo de NVD, de la API de historial de cambios; la hora del KEV, del campo dateReleased del JSON del catálogo. Todas las horas de la tabla están en UTC.

En esta tabla hay dos «70 minutos» y unos «0,7 segundos» que merecen detenerse. La versión 26.4.303 salió el 11 de septiembre a las 13:43. Setenta minutos después, el primer administrador afectado abrió la incidencia diciendo que desde el día anterior le estaban entrando en los sistemas. Pensamos que ninguna de las dos partes sabía de la otra en ese momento: las notas de la versión no hablaban de seguridad, y el administrador actualizó cuando alguien se lo pidió en la propia incidencia. Los otros 70 minutos son del 14 de octubre: CVE.org publicó el identificador a las 02:27 y la primera publicación en X con ese identificador llegó 69,8 minutos después.

Los 0,7 segundos están en la API de CVE.org. El campo dateReserved marca las 02:27:41.637 y datePublished las 02:27:42.315. Dicho de otro modo: durante los 33 días anteriores, el fallo no tenía ni siquiera un identificador reservado. Cualquier proceso que trabaje por CVE no tenía nada que buscar en esos 33 días, y ese es el núcleo del problema para todo equipo cuya entrada de trabajo empieza por un identificador.

Encontramos además un punto donde una fuente secundaria no coincide con el registro original. El aviso de Censys del 16 de octubre dice que los registros del primer informante muestran la primera petición maliciosa el 16 de septiembre. Pero el cuerpo de la incidencia muestra líneas del 10 de septiembre a las 19:51 y del 11 de septiembre a las 09:56 (zona horaria +0200), y la incidencia se abrió el 11 de septiembre: no puede citar como «primera» una línea del día 16. Nos quedamos con el texto que devuelve la API de GitHub, porque en una ventana de 33 días una fecha mal copiada en un resumen supone un error de 6 días. Del mismo aviso tomamos las cifras de exposición: ese día Censys vio 19.454 servidores y 103.350 propiedades web con la aplicación instalada, y aclara que no todas están confirmadas como vulnerables; además, las dos cifras incluyen la versión ARM64 de la misma aplicación (1.001 servidores).

Por qué no hubo CVE durante 33 días

El KEV tiene tres requisitos firmes que CISA explica en su página de criterios: que el fallo tenga un identificador CVE, que haya pruebas fiables de explotación activa y que exista una medida de corrección clara. Este fallo cumplía el segundo y el tercero el 11 de septiembre, porque la incidencia ya tenía avisos de tres administradores y la corrección ya estaba publicada. Lo que lo frenó fue el primero. El KEV lo incluyó 9,7 días después del CVE, lo que por sí solo no es lento; lo que alargó el total hasta 42 días fueron los 32,5 días sin identificador.

El blog de Collabora del 14 de octubre pone dos hechos uno junto a otro: este año ha recibido muchísimos informes de seguridad hechos con ayuda de IA, y el tiempo para obtener y publicar un CVE a través de GitHub ha pasado de un día, más o menos, a varias semanas. El blog no dice que lo primero cause lo segundo; dice que Collabora está solicitando ser autoridad de numeración de CVE (CNA) para acortar la espera. El registro en CVE.org muestra que quien lo asignó al final fue MITRE y que la reserva y la publicación ocurrieron en el mismo segundo, lo que se parece más a MITRE actuando como asignador de último recurso que a una petición normal en cola. No encontramos ninguna explicación oficial de MITRE ni de GitHub sobre este caso, así que solo describimos la forma del registro.

Para el lector hispanohablante hay un detalle útil: el propio INCIBE es una de esas autoridades de numeración, y su web tiene una sección de asignación y publicación de CVE. Un proyecto español o latinoamericano que publique software libre puede pedir el identificador a una CNA cercana en lugar de esperar en una cola general. No sabemos si eso habría acortado este caso; sí sabemos que el cuello de botella de 32,5 días estuvo en la asignación, no en el análisis.

El caso no es raro. En octubre, la empresa de seguridad Second Security publicó el estudio The Patchless Window, que siguió 18.594 CVE de software libre de enero a agosto de 2026 hasta el primer commit público que corregía cada uno. La mediana entre «la corrección es pública» y «el CVE es público» fue de 5,1 días en enero y de 39,2 días en agosto. Los 32,5 días de Collabora quedan incluso por debajo de la mediana de agosto. En software libre, «primero la corrección, un mes después el identificador» se está volviendo lo normal. BleepingComputer citó este estudio el 15 de octubre; nosotros comprobamos las cifras en la web del propio estudio.

Hay un último contexto. Desde el 15 de abril de 2026, el NIST ya no enriquece todos los CVE: da prioridad a los del KEV, a los del software que usa el Gobierno federal de EE. UU. y al «software crítico», porque las solicitudes de CVE crecieron un 263 % entre 2020 y 2025. Cuando leímos este registro en la API de NVD el 26 de octubre, su vulnStatus seguía en Deferred (aplazado), solo con la puntuación CVSS 4.0 del asignador y el SSVC de CISA. El objetivo declarado del NIST es enriquecer las entradas del KEV en un día laborable, y ya habían pasado más de dos. Para el lector, esto significa que muchos campos de NVD pueden estar vacíos antes del KEV y durante un tiempo después, justo cuando más falta harían.

La versión en español llegó todavía más tarde

En Europa hay dos espejos públicos que muchos equipos consultan. La base de datos de vulnerabilidades de ENISA tiene la ficha EUVD-2026-100780, con la misma descripción en inglés y la fecha de publicación del 14 de octubre. Su campo exploitedSince (explotada desde) marca el 23 de octubre: es decir, toma como inicio de la explotación el día del KEV, no septiembre. Las dos referencias de la ficha son, precisamente, la incidencia de GitHub y el hilo del foro de Nextcloud, las dos fuentes que llevaban semanas avisando.

La ficha de INCIBE-CERT tiene fecha de publicación 14/10/2026 y última modificación 24/10/2026. Cuando la leímos el 26 de octubre, la descripción empezaba por «* Pendiente de traducción *» y seguía con el texto original en inglés. No es una crítica: INCIBE refleja miles de CVE y la traducción lleva su tiempo. Pero para un ayuntamiento o una pyme que solo lee avisos en español, la cadena de demoras se alarga un eslabón más.

En X pasó algo parecido. Buscamos Nextcloud en español desde el 1 de septiembre (lang:es) y obtuvimos 26 publicaciones, de las que 7 trataban este fallo. La primera llegó el 24 de octubre a las 03:30 UTC, 8,0 horas después del KEV; antes del KEV no hubo ninguna. La cuenta que más aparecía, con 8 publicaciones, era el asistente de IA de la propia X (9,2 millones de seguidores), que respondía a usuarios sobre la Raspberry Pi olvidada en un cajón y no decía nada del fallo. Otras dos publicaciones del 21 de octubre hablaban de PHP2Shell, otro fallo, y avisaban de que Nextcloud funciona sobre PHP.

Prueba 1: qué había en redes antes del CVE

Si alguien hubiera vigilado este componente en X, ¿lo habría visto antes? El 26 de octubre, entre las 10:24 y las 10:26 (hora de Singapur), hicimos tres búsquedas con la API de búsqueda de X (twitter/search), todas limitadas del 1 de septiembre al 14 de octubre. La primera usó el nombre técnico richdocumentscode; la segunda, el producto más palabras de síntoma, nextcloud (hacked OR webshell OR compromised OR backdoor); la tercera, solo nextcloud collabora.

Los resultados coincidieron. Las dos primeras búsquedas devolvieron 3 y 5 publicaciones, todas del 14 de octubre o posteriores, así que antes del CVE hubo cero. La tercera devolvió 16 publicaciones anteriores al CVE, y ninguna hablaba de un fallo ni de una intrusión: trataban de que la Administración federal suiza ofrecía herramientas ofimáticas libres a 3.000 empleados, de soberanía digital europea y de empresas de alojamiento que venden Nextcloud gestionado. Notamos también que las tres peticiones llevaban until:2026-10-14, pero devolvieron 3, 5 y 6 publicaciones del 14 de octubre o posteriores. El límite superior de fecha (en la ayuda de búsqueda avanzada de X, «antes de una fecha») no se aplicó de forma estricta, así que volvimos a filtrar por el campo posted_at de cada publicación.

En Reddit, la API de búsqueda de Reddit (reddit/search) siempre cubre el último mes. Nuestra búsqueda del 26 de octubre abarcaba desde el 26 de septiembre, es decir, los 18 días anteriores al CVE. A las 10:42 (hora de Singapur), richdocumentscode ordenado por lo más reciente devolvió 14 publicaciones, todas sobre este fallo y ninguna anterior al CVE. La primera fue una republicación de noticias de seguridad del 14 de octubre a las 20:04, 17,6 horas después del CVE. La más valiosa llegó el 22 de octubre: un administrador de r/NextCloud contó cómo le habían entrado en el servidor a través de la aplicación integrada de Collabora, con 52 comentarios, y 13 segundos después la misma persona la publicó también en r/Malware.

Para Hacker News usamos la API de búsqueda de Algolia. richdocumentscode no dio resultados. Con nextcloud collabora desde el 1 de septiembre, lo primero relacionado fue un enlace del 15 de octubre a las 22:06, con 2 puntos y ningún comentario. La API de búsqueda de YouTube (youtube/search) devolvió 10 vídeos, todos con el identificador, y el primero llegó 2,5 días después del CVE. La API de búsqueda de LinkedIn (linkedin/search) devolvió 10 publicaciones, 8 con el identificador, la primera 4,0 días después.

También probamos la API de búsqueda de Weibo (weibo/search) con la consulta china equivalente a «vulnerabilidad de Nextcloud»: 9 de 10 resultados hablaban de PHP2Shell y el último era un resumen diario que mencionaba Collabora en una línea. La API de búsqueda de Threads (threads/search) devolvió 25 publicaciones, todas de las últimas 19 horas, así que no sirve para ver una primera aparición. La tabla resume cada plataforma.

La lógica de esta tabla se puede seguir paso a paso. Primero, todas las señales públicas anteriores al CVE salieron en sitios del propio proyecto: el gestor de incidencias y el foro de usuarios del fabricante. Segundo, quienes escribían allí eran administradores afectados y mantenedores, con registros y números de versión que se pueden comprobar, mientras las redes callaban. Tercero, las primeras publicaciones en redes llegaron después del CVE y desde cuentas de noticias de seguridad, que leen registros CVE y no gestores de incidencias. Por eso la vigilancia principal debe ser «incidencias y foros por nombre de componente»; las redes amplifican después y aportan testimonios de víctimas, pero en este caso no fueron una alerta temprana.

Esta conclusión tiene un límite. Aquí las víctimas eran organizaciones pequeñas que alojan sus propios servicios y que piden ayuda en el gestor de incidencias del proyecto. Si las víctimas son grandes empresas, la primera señal suele ir por el canal de soporte de pago del fabricante, y eso los datos públicos no lo ven. El patrón vale sobre todo para software libre que los equipos pequeños instalan por su cuenta.

Prueba 2: después del CVE, el volumen sigue al KEV

A las 10:26 (hora de Singapur) buscamos una vez CVE-2026-110447 en X, con límite 200 y orden por lo más reciente. La respuesta trajo 106 publicaciones, sin llegar al límite. Las repartimos en tres periodos. Antes del CVE hubo 0; en los 9,7 días entre el CVE y el KEV hubo 26; en los 2,3 días posteriores al KEV hubo 80, de ellas 49 solo el 24 de octubre. Las publicaciones de las primeras 48 horas tras el KEV fueron el 71,7 % del total.

La forma del gráfico dice una cosa con claridad: en X, el KEV es el altavoz, no la señal amplificada. El fallo se explotó en septiembre, la descripción del CVE ya decía «explotado en el entorno real» el 14 de octubre y las grandes cuentas de noticias de seguridad lo publicaron ese mismo día. Pero la ola de republicaciones solo llegó cuando CISA publicó el aviso del KEV. La razón es sencilla: muchas cuentas de noticias y muchos bots usan la actualización diaria del KEV como fuente, y muchas empresas solo abren ticket cuando algo entra en el catálogo. Para la vigilancia, esto significa que una alerta del tipo «sube de golpe el volumen de publicaciones de un CVE» habría saltado después del KEV.

El reparto por idiomas también enseña algo. De las 106 publicaciones, 68 estaban en inglés, 18 en japonés, 5 en francés, 4 en español, 3 en coreano y 1 en chino. La parte japonesa importa: la única publicación de primera mano sobre una intrusión antes del KEV estaba en japonés. Un filtro que solo guarde inglés y español la habría perdido. Si el equipo filtra por idioma para ahorrar lectura, conviene conservar los idiomas de todos los países donde se usa el software, no solo los del propio equipo.

Prueba 3: un 93,4 % de ruido, y qué aspecto tiene

Clasificamos las 106 publicaciones en 6 clases con una regla escrita de antemano. Hay que decir el límite: las 106 se etiquetaron una sola vez, con la regla, y ningún segundo etiquetador las revisó de forma independiente. Por eso el 93,4 % es el resultado de una sola pasada de etiquetado por reglas, con un margen de error desconocido. Antes de usarlo en un informe formal, conviene que otra persona vuelva a etiquetar las 106 con la misma regla y se publique el acuerdo entre las dos pasadas. Llamamos «señal» a lo que aporta un dato que no está en el registro CVE ni en el aviso del fabricante. El «ruido» tiene tres clases: republicaciones de avisos o noticias, bots con plantilla y resúmenes diarios, y promoción o contenido ajeno.

El resultado fue de 80 republicaciones, 12 bots y resúmenes y 7 de promoción o ajenas: 99 publicaciones, el 93,4 %. Entre las 7 señales, 4 eran avisos institucionales con datos propios: CERT.LV de Letonia, el CSIRT de Italia, el recuento de exposición de Censys y el aviso de CISA. Otras 2 eran datos nuevos de personas que habían revisado los registros: una señalaba que el SSVC contradecía la descripción y otra que NVD tenía puntuación CVSS 4.0 pero no 3.x. La última era un administrador japonés que, el 23 de octubre a las 08:29 UTC, contó que en uno de los servidores que gestiona le habían instalado un programa de minería a través de este fallo la semana anterior.

Solo 4 de esas 7 llegaron antes del KEV. Es decir, un equipo que hubiera leído todo lo publicado con el identificador antes del KEV habría leído 26 publicaciones para encontrar 4 útiles. Después del KEV la proporción empeora: 80 publicaciones y 3 útiles. El coste de leer crece con el KEV; el valor, no.

Algunos tipos de ruido aparecen una y otra vez con otros fallos, así que conviene meterlos en las reglas de filtrado. Hubo publicaciones que usaban el titular para promocionar una criptomoneda y anuncios de productos del estilo «conecta un bot de IA a una dirección y recibe alertas». Hubo publicaciones de «trucos para cazarrecompensas» que enseñan a buscar y probar sistemas sin parchear; no ayudan a quien defiende, las quitamos y no repetimos lo que dicen. Y hubo un comentario general sobre que «cada semana parece que se cae el cielo», que solo apareció porque llevaba el identificador.

El ruido no está solo en X. En el hilo de 7 mensajes del foro de Nextcloud, los mensajes 3 y 6 eran de la misma cuenta recién creada y enlazaban a una página externa con un «autodiagnóstico gratis en 30 segundos»; el mensaje 7 era del responsable de la comunidad, que advertía de que eran dos enlaces casi idénticos y de que vigilan el spam. En Weibo, 8 de los 10 resultados eran el mismo texto sobre PHP2Shell publicado por 8 cuentas en 2 segundos, el patrón típico de una granja de cuentas. En Threads, 6 de los 25 resultados de «Nextcloud Collabora» eran publicaciones en italiano con el verbo «collabora» («colabora»).

Prueba 4: los campos para máquinas fueron más lentos que el texto

Muchas cadenas de procesamiento de vulnerabilidades no leen la descripción, sino campos estructurados. Uno son los tres puntos de decisión SSVC que CISA añade a los registros CVE con su proyecto Vulnrichment: si hay explotación, si se puede automatizar y el impacto técnico. Otro es la puntuación EPSS diaria de FIRST, que estima la probabilidad de que se observe actividad de explotación en los próximos 30 días. La directiva estadounidense BOD 26-04 usa el KEV, la automatización, el impacto técnico y la exposición para fijar plazos, y tres de esos datos los da CISA a través de Vulnrichment.

Con la API de historial de NVD sacamos cada cambio del SSVC de este registro, y con la API de EPSS la serie diaria. La descripción decía «explotado en el entorno real» desde las 03:17 del 14 de octubre. El SSVC, en cambio, evolucionó así:

Es decir, durante 9,7 días la descripción decía «explotada», pero los campos estructurados primero estaban vacíos y después dijeron «no explotada, no automatizable» durante 9 días enteros. Pasaron a «explotada» 47 minutos después del KEV. EPSS se quedó esos 10 días en el 1,2 % (en torno al percentil 68 de entonces) y solo llegó al 12,3 % el segundo día tras el KEV. Una regla como «abre ticket si SSVC es active o EPSS supera el 10 %» habría saltado entre 1 y 2 días después del KEV, 11 días después del texto de la descripción.

Una persona en X detectó la contradicción. El 23 de octubre a las 21:03 UTC publicó una actualización: unos 6 minutos después de su primer aviso sobre la contradicción, CISA había incluido el fallo en el KEV y el SSVC ya decía active. Pedía a quien tuviera el valor antiguo en su cadena de procesamiento que volviera a descargarlo y recordaba que el plazo federal vencía el 26 de octubre. Entre las 106 publicaciones, fue de las pocas con valor directo para una cadena automática.

Esto no quiere decir que SSVC y EPSS no sirvan. Las preguntas frecuentes de EPSS aclaran que no es una puntuación de riesgo completa, solo una probabilidad de actividad observada, y SSVC es el juicio de un analista de CISA que necesita pruebas. Nuestra observación es más estrecha: mientras la prueba solo existía en un gestor de incidencias, ninguno de los dos campos la recogió. Los campos estructurados sirven para ordenar, no como barrera; conviene añadir una regla de texto aparte para frases como «exploited in the wild» en la descripción.

Prueba 5: 24 CVE recientes del KEV y cuánto se adelantó X

Un caso no basta. Tomamos las 30 entradas que el KEV añadió entre el 26 de septiembre y el 23 de octubre. Seis tenían identificadores antiguos, de 2015 a 2025 (por ejemplo ProFTPD y BIND de 2015). Para las otras 24, buscamos cada identificador una vez en X con twitter/search entre las 10:28 y las 10:41 (hora de Singapur), con límite 200. Como hora del KEV usamos la primera marca del KEV en el historial de NVD, que llega entre minutos y horas después de la publicación de CISA: es una cota superior y hace que la ventaja de X parezca algo mayor. No es la misma hora que usamos en el caso principal, que toma el dateReleased del JSON del KEV de CISA (19:30 del 23 de octubre); la marca del KEV en NVD para ese mismo CVE llegó a las 20:17, 47 minutos después. Las versiones antiguas del catálogo no dan una hora por entrada, así que en el corte transversal usamos la marca de NVD para los 24, y el caso principal aparece ahí con 9,7 días según la misma regla.

El resultado: 23 de los 24 (95,8 %) tenían al menos una publicación en X con el identificador antes del KEV, lo que cumple en lo formal el criterio 6. Pero la ventaja mediana, calculada con los valores sin redondear, fue de unos 1,16 días (los valores 12.º y 13.º son 1,12 y 1,19 días), y solo 13 de los 24 se adelantaron más de un día. Más importante aún: en 17 CVE la primera publicación en X quedó a menos de 0,3 días de la publicación en NVD. La razón está en el hueco entre NVD y el KEV. En 12 de los 24, el KEV llegó el mismo día que NVD o al día siguiente, casi siempre en fallos de día cero confirmados por el fabricante (Citrix NetScaler, Fortinet, Ivanti). X solo parece adelantarse cuando ese hueco es largo, y esa ventaja sale casi entera de la propia publicación del CVE.

Si ordenamos el hueco entre NVD y el KEV por días naturales, la forma se ve mejor: 0 días en 9 CVE, 1 día en 3, 2 días en 2, 5, 6 y 9 días en uno cada uno, 10 días en 3 y 27 días en 4. La mediana es de 1,5 días.

Así que las entradas de este mes se dividen en dos grupos. En el primero, el fabricante confirma un día cero y el CVE y el KEV llegan casi juntos; ahí X ayuda a enterarse antes de un aviso urgente, con horas de ventaja. En el segundo, el CVE llevaba tiempo publicado y las pruebas de explotación llegaron después; ahí la ventaja de X depende de que alguien se fije en el CVE, y el caso de Plex muestra que puede no hacerlo nadie durante tres semanas. Además, 6 CVE tenían publicaciones en X con el identificador antes de que NVD los recogiera, casi siempre porque el aviso del fabricante dio el número primero. Al construir una cronología, no conviene tomar la hora de NVD como la hora en que el identificador se hizo público.

La excepción son los 4 CVE de Plex Media Server. NVD los publicó el 23 de septiembre, pero la primera publicación en X con esos identificadores llegó el 18 de octubre, 24,9 días después y solo 2,2 días antes del KEV; lo vemos en la sección siguiente. Dos avisos más: en el CVE-2026-88771 y el CVE-2026-102764 la búsqueda devolvió las 200 publicaciones del límite, así que las más antiguas pueden haberse quedado fuera y nuestra primera aparición es una cota inferior. Y la búsqueda de X devuelve una muestra ordenada por la plataforma, no todas las publicaciones.

Con SSVC la conclusión es más sencilla. Ninguna de las 30 entradas tenía exploitation: active antes del KEV, así que en esta muestra el «active» de SSVC es un reflejo del KEV. De los 12 CVE con dato de EPSS el día anterior al KEV, los 12 estaban por debajo del 10 %. En esta muestra, ninguno de los dos campos avisó antes que el catálogo.

Tres casos de contraste: NetScaler, Plex2Shell y PHP2Shell

Para ver si hay un patrón en dónde aparece la primera señal, comparamos tres sucesos del mismo periodo. Buscamos cada uno una vez en X y alineamos sus horas de primera mano, con la publicación del CVE como día 0.

NetScaler: X se adelantó, pero con rumores. A las 10:54 (hora de Singapur) buscamos NetScaler del 26 al 28 de septiembre y obtuvimos 176 publicaciones. La primera, del 26 de septiembre a las 15:07 UTC, era de una cuenta grande que decía que un día cero desconocido de Citrix NetScaler, ya explotado, estaba obligando a gobiernos e instituciones a apagar equipos. NVD recibió el CVE-2026-88771 el 27 de septiembre a las 17:16, y para entonces X ya tenía 77 publicaciones. Varias de las primeras decían que el rumor había salido de conversaciones de administradores de sistemas en Reddit.

CISA lo incluyó hacia las 20:16 de ese día y publicó una alerta aparte que pedía comprobar si había intrusión antes de parchear; Citrix publicó su boletín ese mismo día. Es el patrón de gran fabricante, día cero y equipo de borde: las víctimas son grandes organizaciones y la noticia corre primero entre profesionales como «algo va mal». Después, fabricante, CVE y KEV llegan en un solo día. X se adelantó 26 horas, pero con rumores sin confirmar: bastan para activar un protocolo de «revisar registros primero», no para sacar conclusiones.

Plex2Shell: el fabricante avisó pronto, pero nadie lo oyó. Plex publicó un aviso en su foro el 1 de septiembre a las 18:30 UTC: la versión 1.43.3 corregía varios problemas de seguridad y los CVE estaban solicitados. El aviso lleva hoy 86.684 visitas, pero en X la búsqueda plex "security update" del 1 al 22 de septiembre solo encontró 1 publicación. Los CVE (como el CVE-2026-96652) salieron el 23 de septiembre y, según el aviso de la ACN (la agencia italiana de ciberseguridad), cada uno tiene por separado una puntuación modesta, como 4,3 y 6,5 en CVSS 3.1. Casi nadie les prestó atención.

El giro llegó el 16 de octubre, cuando un investigador publicó el análisis completo de cómo se encadenan los 4 fallos. El 17 de octubre, el señuelo de otro investigador ya registró explotación (su blog). La primera publicación en X con «Plex2Shell» llegó el 18 de octubre a las 15:59 y CISA incluyó los CVE el 20 de octubre. El patrón: el riesgo combinado de fallos con puntuación baja solo se vio cuando se publicó un análisis, y la primera señal pública fue el aviso del propio fabricante. La vigilancia tiene que saber leer frases como «actualización de seguridad importante, detalles más adelante». El testimonio de una víctima en Reddit (r/unRAID, 109 comentarios) llegó el 21 de octubre, ya después del KEV.

PHP2Shell: lo que más ruido hizo en X y sigue fuera del KEV. El 20 de octubre, el equipo de PHP anunció que publicaría correcciones para dos fallos críticos. La primera publicación en X con el CVE-2026-109618 llegó el 20 de octubre a las 18:56 UTC, unas 19 horas antes de la corrección y del CVE (13:48 UTC del 21 de octubre, según CVE.org). Antes de que terminara el embargo, a las 14:00 del 21 de octubre, nuestra única búsqueda ya tenía 68 publicaciones. El equipo de inteligencia de amenazas de AWS contó en su blog que su red de señuelos vio intentos de explotación el 17 de octubre, 4 días antes de la divulgación. El CERT-EU lo recogió en su aviso 2026-018.

Pero cuando leímos el KEV el 26 de octubre, seguía en la versión 2026.10.23 y no incluía esos identificadores. Nuestra búsqueda de las 10:52 (hora de Singapur) devolvió las 200 publicaciones del límite solo entre el 20 y el 23 de octubre, y de nuevo el límite superior de fecha no se aplicó de forma estricta. Este caso muestra que la atención en redes y la inclusión en el KEV no van de la mano: el KEV exige pruebas fiables de explotación real, y los intentos contra señuelos pueden no bastar. Con un fallo como PHP2Shell, no conviene esperar al KEV; hay que programar la corrección según la exposición propia.

Si se ponen los cuatro casos juntos, la conclusión no es que las redes no sirvan. La primera señal aparece donde hablan las primeras víctimas. Las organizaciones pequeñas que alojan sus servicios van al gestor de incidencias y al foro de usuarios; los profesionales de grandes organizaciones se preguntan entre ellos en redes; los fabricantes avisan con discreción en sus foros y notas de versión; los investigadores publican en blogs y repositorios. Una suscripción por CVE solo cubre lo que viene después de todo eso.

De la señal a la respuesta: un proceso que se ejecuta una vez al día

La estación 1 es vigilar las fuentes. La lista no es de identificadores CVE, sino de los nombres de los componentes que de verdad se usan, como richdocumentscode, Plex Media Server o NetScaler. Cada componente tiene tres tipos de fuente: el gestor de incidencias y las versiones del proyecto (GitHub tiene una API gratuita para incidencias y versiones nuevas), el foro del fabricante o su página de avisos (muchos usan Discourse, que devuelve JSON) y la búsqueda por palabra clave en algunas redes. El JSON del KEV y la descripción del CVE también se leen a diario, pero sirven para confirmar y fijar plazos, no como punto de partida. En este caso, quien leyera cada día las incidencias de richdocumentscode habría visto «Hack» en un título el 11 de septiembre, un mes antes que cualquier suscripción por identificador.

La estación 2 es guardar las pruebas. Cada respuesta original se guarda sin tocar, con los parámetros de la petición, la hora UTC y un hash del archivo. Hay dos motivos. El primero es poder contestar después a «¿cuándo lo supimos?», una pregunta que aparece en la revisión forense que pide la BOD 26-04 y en muchos informes de incidentes. El segundo es que el contenido de las plataformas cambia: se borran publicaciones, se editan comentarios y los resúmenes se equivocan. La discrepancia de fechas de Censys solo la vimos porque volvimos al texto guardado de la incidencia.

La estación 3 es cruzar con los activos. El inventario se cruza por nombre de componente y no por CVE, porque la mediana de agosto en el estudio de The Patchless Window fue de 39,2 días sin identificador. El cruce tiene que llegar al tipo de instalación: este fallo solo afecta a la aplicación CODE integrada, y Collabora independiente no está afectado. Un cruce del tipo «¿usamos Collabora?» genera muchas falsas alarmas y, peor, puede esconder entre ellas el único servidor afectado de verdad.

La estación 4 es quitar el ruido. Cada elemento recibe una de las 6 clases de la prueba 3. Republicaciones, bots, promoción y trucos de ataque quedan fuera de la cola de respuesta, pero se conservan en el archivo para revisarlos después. En esta prueba se quitó el 93,4 % de la búsqueda por identificador en X y el 100 % de la búsqueda por producto antes del CVE. Las reglas deben cubrir también las coincidencias entre idiomas (el «collabora» italiano), las granjas de cuentas (8 cuentas en 2 segundos) y los enlaces de «autodiagnóstico gratis» en los foros.

La estación 5 es responder. El aviso de Collabora dice que hay que actualizar a la 26.4.303 o eliminar la aplicación, porque desactivarla no basta; quien use Nextcloud 29 o anterior, ya sin soporte, debe actualizar Nextcloud o eliminar la aplicación. El mensaje 4 del foro de Nextcloud dio una comprobación práctica: tras la actualización, la verificación de integridad de Nextcloud señaló un «archivo de más» en la carpeta de la aplicación. El CSIRT de Italia habló de instalación de webshells y robo de credenciales. Por eso, para cualquier instancia expuesta desde el 10 de septiembre, sugerimos además pasar la verificación de integridad, revisar los registros de acceso y cambiar las contraseñas de base de datos y de aplicación que pueda leer el usuario del servidor web.

Solo describimos estas acciones defensivas, no el aspecto de las peticiones de ataque. La verificación de integridad importa porque un parche no borra los archivos que un atacante ya dejó: un servidor parcheado puede seguir teniendo una puerta trasera. Por eso la entrada del KEV pide revisión forense además de la corrección.

La estación 6 es cerrar el caso. Cada caso tiene que responder a cuatro preguntas: quién lo atendió, cuándo, con qué prueba (un enlace a la respuesta original archivada) y qué hizo. Cuando el fallo entra en el KEV, se compara su fecha límite con la hora de cierre. La tabla muestra los campos mínimos que proponemos; todos los usamos en esta prueba.

Las cuentas: 50 componentes durante un mes

El 26 de octubre a las 10:13 (hora de Singapur) leímos el catálogo de capacidades; la referencia es la página de precios. twitter/search, reddit/search, youtube/search, linkedin/search y threads/search cuestan 0,000556 USD por petición, y weibo/search, 0,000806 USD. Se paga por petición, no por resultado. Además hicimos 3 búsquedas de EveryInfra en el nivel quick (0,000694 USD cada una) en la web y en foros, buscando publicaciones anteriores al CVE; las 3 devolvieron 0 resultados.

Pensemos en un equipo pequeño con 50 componentes expuestos a internet y una búsqueda diaria en X y otra en Reddit por componente. Son 100 peticiones × 0,000556 USD = 0,0556 USD al día, o 1,668 USD en 30 días. La API de incidencias de GitHub, los foros con Discourse, NVD, CVE.org, el KEV y EPSS son API públicas gratuitas y no entran en la cuenta. Los resultados vacíos y los errores no se cobran: de nuestras 60 peticiones, 6 chocaron con el límite de frecuencia (estado 429), 1 tenía un parámetro mal escrito (estado 422) y 1 volvió vacía, y ninguna de esas 8 se cobró. Se cobraron 52 peticiones, 0,029576 USD en total; la imagen de portada y una ilustración costaron otros 0,06 USD.

¿Merece la pena pasarlo cada hora? Con los mismos 50 componentes, un ciclo por hora son 2.400 peticiones al día: 1,3344 USD al día y unos 40,03 USD al mes, 24 veces el ciclo diario. A cambio, la señal se ve como mucho menos de un día antes. En este caso la primera señal llegó 32,5 días antes del CVE, así que a esa escala la diferencia entre diario y por horas no importa. La vigilancia por horas tiene sentido para los días cero de equipos de borde como NetScaler, donde CVE y KEV llegan en un solo día; esa lista suele ser corta y puede ir aparte, dejando la lista completa en diario.

Obtener los mismos datos con código o con un cliente de IA

Una petición con curl que busca en X por identificador (la clave es un marcador):

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer <API Key>" \
  -H "Content-Type: application/json" \
  -d '{"platform":"twitter","action":"search","params":{"keyword":"CVE-2026-110447","sort":"latest","limit":200}}'

Comprobamos cada campo de respuesta que usa este artículo contra los response_fields de twitter/search en el catálogo.

En Reddit, reddit/search usa los parámetros keyword y sort (newest, relevance y otros), y los campos más útiles son community, comment_count y posted_at. Su rango es siempre el último mes, así que si hace falta más de 30 días de historia hay que archivar los resultados en su momento.

En Claude Code, primero se crea una clave con el inicio rápido y después se añade el servidor MCP remoto:

claude mcp add --transport http everyinfra https://api.everyinfra.com/mcp \
  --header 'Authorization: Bearer ${EVERYINFRA_API_KEY}'

Después basta con pedirlo en una frase: «Usa everyinfra_call_api para buscar en X richdocumentscode y CVE-2026-110447, ordena por posted_at, cuenta cuántas publicaciones hay antes y después de la publicación del CVE (2026-10-14 02:27 UTC) y separa las cuentas institucionales de las personales».

Errores y cobros, tal como los vimos en la prueba. Al poner en Reddit sort con el valor oldest, que no existe, la respuesta fue 422 invalid_value, con la lista de valores permitidos y la frase «Nothing was charged». Cuando otras peticiones con la misma clave de prueba agotaron el límite de 10 por minuto, la respuesta fue 429 rate_limited con un valor retry_after en segundos, tampoco cobrada; tras esperar ese tiempo más 10 segundos, todos los reintentos funcionaron. Un resultado vacío síncrono devuelve 200 con count 0 y billing.reason igual a empty_result_refunded, sin cobro; para conciliar línea a línea, véase devoluciones por fallo y conciliación. Cuando una búsqueda en X devuelve justo el límite, las publicaciones más antiguas pueden quedar fuera sin que la respuesta lo indique: hay que comparar count con el límite.

Cambios de los últimos 60 días e investigación relacionada

2026-10-23: CISA incluye el CVE-2026-110447 con plazo de tres días y revisión forense. Véase la alerta de CISA. Para el lector: el campo forensicTriage: Yes de una entrada del KEV merece una regla propia, porque significa «después de parchear, comprueba si te entraron».

2026-10-21: PHP2Shell se hace público y AWS dice que la explotación empezó 4 días antes. Véanse los casos de contraste. Para el lector: al investigar, hay que contar hacia atrás desde la primera explotación conocida, no hacia delante desde la fecha del aviso.

2026-10-20: CISA añade seis fallos de golpe y cuatro son Plex2Shell. Para el lector: fallos con puntuación baja pueden entrar en el KEV cuando se encadenan, y un filtro por puntuación CVSS individual los deja pasar.

2026-10-14: Collabora atribuye el retraso a la cola de solicitudes de CVE y pide ser CNA. Para el lector: cuando los proyectos libres sean CNA, los identificadores llegarán antes; mientras tanto, una suscripción por CVE puede llegar un mes tarde.

Octubre de 2026: Second Security publica The Patchless Window. En agosto, la mediana entre corrección pública y CVE público fue de 39,2 días. Para el lector: el software libre hay que vigilarlo por sus commits, versiones e incidencias, sin esperar al identificador.

2026-09-25: un artículo en arXiv propone GPM, un indicador de prioridad basado en las estrellas, bifurcaciones y usuarios de repositorios con exploits en GitHub, y dice que se integró en la versión 5 de EPSS (arXiv 2609.31004). Para el lector: la actividad pública en repositorios ya entra en las puntuaciones formales, pero la señal de este caso fue el testimonio de una víctima en un gestor de incidencias, no código de explotación, así que este indicador no la recoge.

2026-08-19: un estudio mide un grafo de conocimiento de amenazas frente a 10.000 publicaciones sociales sobre amenazas (revista Information). El grafo ya contenía el 96 % de las vulnerabilidades accionables de esas publicaciones y las recogía al menos igual de rápido; las redes solo se adelantaban en la alerta temprana de explotación activa. Para el lector: coincide con lo que vimos aquí, el valor de los datos sociales está en unos pocos testimonios y rumores, no en la cobertura de identificadores.

2026-08-14: STINER, un corpus para extraer inteligencia estratégica de X, analiza el panorama europeo del primer semestre de 2025 (arXiv 2608.14418). Sus autores destacan un perfil de visibilidad distinto para los ataques en España. Para el lector: lo que se ve en X depende del país y del idioma, y un filtro solo en inglés deja fuera parte de la señal. Como contexto de método, un artículo de USENIX Security de 2015 ya intentaba usar publicaciones de Twitter para predecir qué vulnerabilidades se explotarían de verdad.

Límites de este artículo

Primero, solo hay un caso principal, y cada caso de contraste lo buscamos una sola vez. No tenemos un grupo de control con fallos que no se explotaron, así que no podemos calcular una tasa de falsas alarmas ni decir que toda incidencia de «me han hackeado» corresponda a un fallo real. La señal de la incidencia era creíble aquí porque traía registros, varias personas vieron lo mismo y un mantenedor respondió en 3 días; otras incidencias pueden no reunir las tres cosas.

Segundo, la búsqueda de X devuelve una muestra ordenada por la plataforma. Nuestra búsqueda por identificador trajo 106 publicaciones sin llegar al límite, pero no podemos demostrar que no existan otras más antiguas. El límite until no se aplicó de forma estricta en ninguna de las 4 peticiones que lo usaban, por lo que refiltramos por posted_at. La búsqueda de Reddit solo cubre el último mes, así que no pudimos revisar Reddit entre el 10 y el 25 de septiembre; una búsqueda web general limitada a reddit.com y anterior al 14 de octubre solo devolvió dudas antiguas de instalación, sin ningún aviso de intrusión.

Tercero, el ruido se etiquetó una sola vez con una regla escrita de antemano y no hubo segundo etiquetador, y la frontera entre «señal» y «republicación» tiene algo de criterio personal: por ejemplo, una publicación que reescribía el aviso como lista de tareas la contamos como republicación, y otra persona podría contarla como señal.

Cuarto, lo observado sobre SSVC y EPSS vale para una situación concreta: cuando la descripción ya dice que el fallo está explotado. No conviene generalizarlo a «estos campos siempre van lentos». EPSS estima una probabilidad; su objetivo no es repetir el KEV.

Preguntas frecuentes

¿Qué es el catálogo KEV de CISA?

Es la lista de vulnerabilidades que la agencia estadounidense CISA considera explotadas en el entorno real. Para entrar, un fallo necesita un identificador CVE, pruebas fiables de explotación y una corrección clara. Las agencias federales de EE. UU. deben corregirlas en el plazo de cada entrada; en este caso, tres días con revisión forense. El KEV siempre llega después del CVE: aquí, 9,7 días después del CVE y 42,2 días después del primer aviso público. (Pregunta tomada de la sugerencia de búsqueda «cisa kev que es».)

¿Qué es EPSS en ciberseguridad?

Es una puntuación diaria de FIRST que estima la probabilidad de que se observe actividad de explotación de un CVE en los próximos 30 días. No es una puntuación de riesgo completa. En este caso se quedó en el 1,2 % durante los 10 días anteriores al KEV, y en nuestra muestra los 12 CVE con dato estaban por debajo del 10 % el día antes de entrar en el KEV. Sirve para ordenar, no como barrera. (Pregunta tomada de la sugerencia de búsqueda «que es epss en ciberseguridad».)

¿Puede haber una vulnerabilidad explotada sin CVE?

Sí. En este caso hubo 33 días de explotación, con registros publicados en GitHub, sin ningún identificador ni siquiera reservado. El estudio The Patchless Window midió una mediana de 39,2 días entre la corrección pública y el CVE en agosto de 2026. Por eso conviene vigilar por nombre de componente y no solo por CVE. (Pregunta tomada de la sugerencia de búsqueda «vulnerabilidad sin cve».)

Lecturas relacionadas

• Páginas de plataforma: API de X (Twitter), API de Reddit, API de Weibo
• Páginas de capacidad: API de búsqueda de X, API de búsqueda de Reddit, API de búsqueda de YouTube, API de búsqueda de LinkedIn, API de búsqueda de Threads, API de búsqueda de Weibo
• De la misma serie: La inteligencia de vulnerabilidades como producto, Señales sociales de los grupos de bombeo y descarga, Datos sociales como muestra de investigación

Referencias

1. CollaboraOnline/richdocumentscode, incidencia #354 de GitHub «Security issue - Hack», 2026-09-11, https://github.com/CollaboraOnline/richdocumentscode/issues/354
2. CollaboraOnline/richdocumentscode, versión 26.4.303, 2026-09-11, https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303
3. GitHub, documentación de la API REST de incidencias, consultada el 2026-10-26, https://docs.github.com/en/rest/issues/issues
4. Foro de la comunidad de Nextcloud, «To Collabora Built-in User: Update ASAP», 2026-10-03, https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516
5. Discourse, documentación de la API, consultada el 2026-10-26, https://docs.discourse.org/
6. Programa CVE, registro CVE-2026-110447, 2026-10-14, https://www.cve.org/CVERecord?id=CVE-2026-110447
7. API de CVE Services, metadatos del registro CVE-2026-110447, consultada el 2026-10-26, https://cveawg.mitre.org/api/cve/CVE-2026-110447
8. NIST NVD, ficha del CVE-2026-110447, publicada el 2026-10-14 y modificada el 2026-10-24, https://nvd.nist.gov/vuln/detail/CVE-2026-110447
9. NIST NVD, API de historial de cambios de CVE, consultada el 2026-10-26, https://nvd.nist.gov/developers/vulnerability-change-history
10. Collabora Online, aviso de seguridad GHSA-g3vx-3m76-fghh, 2026-10-14, https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh
11. Collabora Online, «Stay Safe: Upgrade Everything Regularly», 2026-10-14, https://www.collaboraonline.com/blog/stay-safe-upgrade-everything-regularly/
12. Censys, «Oct 16 Advisory: Collabora Online Built-in CODE Server OS Command Injection», 2026-10-16, https://censys.com/advisory/cve-2026-110447/
13. CISA, catálogo Known Exploited Vulnerabilities, consultado el 2026-10-26, https://www.cisa.gov/known-exploited-vulnerabilities-catalog
14. CISA, JSON del catálogo KEV (versión 2026.10.23), consultado el 2026-10-26, https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
15. CISA, «Reducing the Significant Risk of Known Exploited Vulnerabilities» (criterios del KEV), consultado el 2026-10-26, https://www.cisa.gov/known-exploited-vulnerabilities
16. ENISA, base de datos europea de vulnerabilidades, ficha EUVD-2026-100780, 2026-10-14, https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-100780
17. INCIBE-CERT, ficha de vulnerabilidad CVE-2026-110447, 2026-10-14 (modificada el 2026-10-24), https://www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/cve-2026-110447
18. Second Security, «The Patchless Window», 2026-10, https://thepatchlesswindow.com/
19. BleepingComputer, «Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers», 2026-10-15, https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/
20. NIST, «NIST Updates NVD Operations to Address Record CVE Growth», 2026-04-15, https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth
21. Hacker News, API de búsqueda de Algolia, consultada el 2026-10-26, https://hn.algolia.com/api
22. Hacker News, enlace «Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers», 2026-10-15, https://news.ycombinator.com/item?id=50111052
23. Reddit r/NextCloud, testimonio de un administrador «Nextcloud compromised via the built-in Collabora app», 2026-10-22, https://www.reddit.com/r/NextCloud/comments/1xcsjlx/nextcloud_compromised_via_the_builtin_collabora/
24. cisagov, repositorio Vulnrichment, consultado el 2026-10-26, https://github.com/cisagov/vulnrichment
25. FIRST, preguntas frecuentes de EPSS, consultadas el 2026-10-26, https://www.first.org/epss/faq
26. CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, 2026-06-10, https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
27. FIRST, EPSS «Get the Data» (con la API), consultada el 2026-10-26, https://www.first.org/epss/data
28. CISA, «Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway», 2026-09-27 (actualizada el 2026-10-09), https://www.cisa.gov/news-events/alerts/2026/09/27/critical-zero-day-vulnerabilities-exploited-citrix-netscaler-adc-gateway
29. Citrix, boletín de seguridad CTX697096, 2026-09-27, https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697096
30. NIST NVD, ficha del CVE-2026-88771, 2026-09-27, https://nvd.nist.gov/vuln/detail/CVE-2026-88771
31. Foro de Plex, «Important Security Update for Plex Media Server v1.43.2 and earlier», 2026-09-01, https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
32. Agenzia per la Cybersicurezza Nazionale (ACN), «Plex Media Server: rilevato sfruttamento in rete delle catena di attacco Plex2Shell», 2026-10, https://www.acn.gov.it/portale/w/plex-media-server-rilevato-sfruttamento-in-rete-delle-catena-di-attacco-plex2shell
33. boredhackerblog, «Plex vulnerabilities being exploited in the wild to drop a cryptominer», 2026-10-17, https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html
34. CISA, «CISA Adds Six Known Exploited Vulnerabilities to Catalog», 2026-10-20, https://www.cisa.gov/news-events/alerts/2026/10/20/cisa-adds-six-known-exploited-vulnerabilities-catalog
35. NIST NVD, ficha del CVE-2026-96652, 2026-09-23, https://nvd.nist.gov/vuln/detail/CVE-2026-96652
36. AWS Security Blog, «Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot», 2026-10-21, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
37. CERT-EU, aviso de seguridad 2026-018 «Critical Vulnerabilities in PHP», 2026-10-20, https://cert.europa.eu/publications/security-advisories/2026-018
38. NIST NVD, ficha del CVE-2026-109618, 2026-10-21, https://nvd.nist.gov/vuln/detail/CVE-2026-109618
39. CISA, «CISA Adds One Known Exploited Vulnerability to Catalog» (CVE-2026-110447), 2026-10-23, https://www.cisa.gov/news-events/alerts/2026/10/23/cisa-adds-one-known-exploited-vulnerability-catalog-0
40. Akhoundali et al., «GitHub Engagement Signals for CVE Prioritization: The GitHub Popularity Metric (GPM)», arXiv 2609.31004, 2026-09-25, https://arxiv.org/abs/2609.31004
41. «Time-Series and Social-Media Threat Analytics over a Deployed Cyber-Threat Knowledge Graph», Information 17(8):794, 2026-08-19, https://www.mdpi.com/2078-2489/17/8/794
42. Ech-Chammakhy et al., «STINER: Automated Extraction of Strategic Cyber Threat Intelligence from X», arXiv 2608.14418, 2026-08-14, https://arxiv.org/abs/2608.14418
43. Sabottke, Suciu y Dumitraș, «Vulnerability Disclosure in the Age of Social Media: Exploiting Twitter for Predicting Real-World Exploits», USENIX Security 2015, https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/sabottke
44. Centro de ayuda de X, «How to use advanced search», consultado el 2026-10-26, https://help.x.com/en/using-x/x-advanced-search
45. CISA, Stakeholder-Specific Vulnerability Categorization (SSVC), consultado el 2026-10-26, https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
46. NIST NVD, documentación de la API de CVE, consultada el 2026-10-26, https://nvd.nist.gov/developers/vulnerabilities