Vulnerabilidades de día cero: tipos, ejemplos y cómo defenderse de ellas

Principales conclusiones

• Un exploit de día cero es un código de ataque operativo para una vulnerabilidad para la que aún no existe una solución disponible públicamente.
• La explotación puede comenzar antes de que exista un parche, a menudo antes de que nadie ajeno al atacante se entere.
• El software al final de su ciclo de vida puede dejar nuevas vulnerabilidades sin que haya ninguna corrección prevista por parte de los desarrolladores originales.
• Lo que tú controlas es la rapidez con la que una solución llega a tu flota una vez que existe.

Tu escáner muestra un informe sin incidencias. Tu ciclo de parches está al día. Nada de eso sirve de nada cuando ya se está aprovechando una vulnerabilidad y ninguna distribución ha publicado aún un paquete corregido.

Se trata de un exploit de día cero: código de ataque para una vulnerabilidad para la que aún no existe ningún parche disponible públicamente. A veces, ese código permanece oculto durante meses. Otras veces, el exploit se publica en GitHub el mismo día, que es lo que ocurrió cuando Dirty Frag afectó a las distribuciones de Linux en mayo de 2026. En cualquier caso, el exploit es solo el primer paso. Gran parte del coste final que esto supone depende de cuánto tiempo permanezca abierta esa ventana de exposición después.

Vulnerabilidad de día cero, exploit y ataque

Una vulnerabilidad es un fallo. Un exploit es el código que lo aprovecha. Un ataque es ese código dirigido contra un objetivo real. Es posible mitigar el riesgo mucho antes de llegar a esa última fase, y la aplicación de parches es posible una vez que existe una solución. Una vez que comienza la explotación, la detección y la contención son lo que te permiten ganar tiempo.

Término	Qué es	¿Puedes hacer algo al respecto?
Vulnerabilidad de día cero	La vulnerabilidad del código, que puede ser conocida de forma privada, pero que aún no se ha hecho pública ni se ha corregido	No siempre. Hasta que no se identifique la vulnerabilidad, no hay nada concreto que corregir, y, una vez identificada, es posible aplicar medidas paliativas mientras se desarrolla una solución.
Vulnerabilidad de día cero	Código funcional que aprovecha esa vulnerabilidad de forma fiable	En parte. Las medidas de mitigación, las listas de bloqueo de módulos y el refuerzo de la seguridad pueden hacer que esta técnica no funcione.
Ataque de día cero	Una campaña activa que utiliza ese vulnerabilidad contra objetivos reales	Sí. La detección y la contención se aplican de inmediato, y las correcciones se instalan en cuanto se publica una solución.

 Una falla puede permanecer en el núcleo durante años sin que nadie presente un informe de incidente. La vulnerabilidad estuvo ahí todo el tiempo, aunque el riesgo real que suponía dependiera de si algo podía acceder a ella. Lo que cambia un exploit funcional son las probabilidades de que ese riesgo se materialice. Una vez que se conoce la falla o el exploit, las fases de respuesta se convierten en procesos que se pueden cronometrar, medir y acortar.

Tipos de vulnerabilidades de día cero

Las vulnerabilidades de día cero no se distribuyen de manera uniforme por toda la pila, y la forma más útil de clasificarlas es según dónde se producen. En su informe «Look What You Made Us Patch», el Google Threat Intelligence Group (GTIG) contabilizó 90 vulnerabilidades de día cero explotadas en la red durante 2025, lo que supone un aumento respecto a las 78 de 2024, aunque aún por debajo de las 100 registradas en 2023. Los sistemas operativos fueron la categoría de productos más explotada, con un 44 % del total, es decir, 39 vulnerabilidades. El software y los dispositivos empresariales, contabilizados como un grupo en lugar de como una sola categoría, sumaron 43 vulnerabilidades, es decir, el 48 %, lo que, según el GTIG, supone el máximo en ambos aspectos desde que comenzó a realizar el seguimiento.

Los ataques a los navegadores siguieron la tendencia contraria y cayeron a mínimos históricos. Por el contrario, los ataques a la infraestructura empresarial y a los dispositivos periféricos se mantuvieron en niveles elevados, a lo que contribuyó el hecho de que la mayoría de los dispositivos periféricos carecen de cobertura EDR estándar.

Vulnerabilidades del sistema operativo y del núcleo

Los sistemas operativos constituyeron la categoría más amplia en los datos de GTIG para 2025, abarcando los de escritorio, móviles y servidores, y los fallos del núcleo de Linux muestran lo amplio que es el radio de acción del ataque. Un ataque exitoso en esa capa puede socavar las barreras entre aplicaciones, contenedores y usuarios, y exponer las credenciales que alberga el servidor.

 

Las vulnerabilidades de escalada de privilegios del núcleo de Linux de 2026 son un buen ejemplo de ello. «Copy Fail» (CVE-2026-31431, CVSS 7,8) llevaba presente en el módulo algif_aead de la API criptográfica del núcleo desde una optimización in situ realizada en 2017. Un usuario local sin privilegios podía reescribir la copia en la caché de página en memoria de un binario setuid, como su, cuatro bytes controlados a la vez, sin condiciones de carrera y sin necesidad de adivinar desplazamientos específicos para cada distribución. No se producía ningún cambio en el disco, por lo que la supervisión de la integridad de los archivos no detectaba nada.

Dirty Frag apareció una semana más tarde, combinando el CVE-2026-43284 de los módulos IPsec ESP con el CVE-2026-43500 de rxrpc. Se trata de dos rutas independientes que conducen a la misma escritura en la caché de páginas, en lugar de una cadena, y el exploit público prueba cualquiera de las dos que el host permita, por lo que cerrar una ruta no cierra la otra. 

TuxCare ha lanzado parches en tiempo real para el fallo de copia tras validar el conjunto completo de correcciones del desarrollador original frente al exploit publicado; posteriormente, lanzó parches «Dirty Frag» en las 24 horas siguientes a la divulgación del 7 de mayo. Cuando el exploit es público y la corrección requiere reiniciar mil hosts, el reinicio puede convertirse en el cuello de botella de la implementación. Cerrar esa brecha en concreto es precisamente lo que hace KernelCare .

¿Sabías que...? En septiembre de 2026, el catálogo de vulnerabilidades explotadas conocidas de la CISA contaba con 31 entradas correspondientes a fallos del núcleo de Linux. En ese mismo momento, un rastreador público contabilizaba más de 6.500 CVE del núcleo de Linux publicados durante 2026. Ambas cifras varían constantemente, así que compruébalas antes de citarlas en cualquier sitio.

Vulnerabilidades en los dispositivos perimetrales y los appliances empresariales

Los cortafuegos, los concentradores VPN, los dispositivos de transferencia de archivos y las plataformas de virtualización se encuentran entre los objetivos de ataques de «día cero» de mayor valor en la empresa, y el motivo es estructural. Se sitúan en el perímetro de la red, albergan credenciales privilegiadas y, en su mayoría, carecen de la cobertura estándar de EDR para terminales.

Desglose de proveedores de GTIG para 2025 sitúa a las grandes empresas tecnológicas en cabeza, seguidas de cerca por los proveedores de seguridad, y destaca a Cisco y Fortinet como objetivos habituales en materia de redes y seguridad, junto con Ivanti y VMware, donde el punto de interés es el acceso a VPN y a la virtualización. Otros 20 proveedores se vieron afectados por exactamente un «zero-day» cada uno, lo que da una idea del amplio alcance que están dispuestos a abarcar los atacantes. GTIG también informó de que los grupos de espionaje patrocinados por Estados continuaron dando prioridad a los dispositivos periféricos y a los equipos de seguridad, ya que algo más de la mitad de los ataques «zero-day» que atribuyó a dichos grupos se dirigieron a ese tipo de infraestructura.

El patrón se repite: ejecución remota de código previa a la autenticación, robo de credenciales o claves, y persistencia que perdura más allá de la aplicación del parche. Los atacantes de ToolShell extrajeron claves de máquina de ASP.NET de los servidores de SharePoint, lo que les permitió falsificar cargas útiles válidas mucho tiempo después de que el servidor se actualizara. La aplicación del parche corrigió la vulnerabilidad, pero cualquiera que ya dispusiera de esas claves conservó su acceso hasta que estas se rotaron. Si el inventario de tus dispositivos se encuentra en una hoja de cálculo trimestral, esa hoja de cálculo es la fuente de exposición.

Vulnerabilidades en aplicaciones y en la cadena de suministro

La tercera categoría es el código que no has escrito tú y que, a menudo, ni siquiera has instalado a sabiendas. Log4Shell es el caso de referencia: una vulnerabilidad crítica en Log4j, una biblioteca de registro de eventos oculta varios niveles más abajo en el árbol de dependencias de miles de aplicaciones Java. En una configuración vulnerable, bastaba con que una cadena JNDI controlada por un atacante —por ejemplo, una proporcionada a través de un encabezado HTTP registrado— llegara a una ruta de llamada vulnerable de Log4j.

Las vulnerabilidades en las dependencias son más difíciles de abordar, ya que no se puede aplicar un parche a lo que no se puede identificar. Los equipos dedicaron semanas tras el incidente de Log4Shell simplemente a elaborar el inventario, y siguen apareciendo muchas más vulnerabilidades ocultas de Log4j años después. La confusión en las dependencias es algo totalmente distinto: se trata de un ataque a la cadena de suministro que introduce un paquete malicioso en lugar de encontrar un fallo en uno legítimo, pero que se aprovecha exactamente del mismo punto ciego.

La comprobación de los paquetes antes de que lleguen a la fase de compilación no detectará de forma fiable un fallo que aún nadie haya descubierto en una dependencia que, por lo demás, es legítima. Lo que sí puede detectar son paquetes maliciosos y aquellos que se han apropiado indebidamente de un nombre (typosquatting), y te proporciona el inventario de dependencias que, de otro modo, tendrías que recopilar en medio de un incidente. Esa es la laguna que SecureChain de TuxCare ha sido diseñado para subsanar en el ámbito del código abierto.

Ejemplos destacados de vulnerabilidades de día cero entre 2021 y 2026

La siguiente lista abarca desde un servidor de correo hasta una biblioteca de registro, pasando por una herramienta de transferencia gestionada de archivos, una plataforma de colaboración y el propio núcleo. Las vulnerabilidades de día cero no se limitan a una sola capa de la pila.

Año	Vulnerabilidad / CVE	Objetivo	¿Por qué se consideró un «zero-day»?
2021	ProxyLogon / CVE-2021-26855	Microsoft Exchange local	La explotación masiva comenzó antes de que se distribuyera el parche fuera de banda.
2021	Log4Shell / CVE-2021-44228	Apache Log4j 2	La vulnerabilidad se detectó días antes de que se hiciera pública y se solucionara.
2023	MOVEit / CVE-2023-34362	Avances en MOVEit Transfer	Cl0p sustrajo datos antes de que se publicara el aviso
2025	ToolShell / CVE-2025-53770	SharePoint Server en las instalaciones	Se ha explotado una vulnerabilidad CVSS 9.8 de ejecución remota de código (RCE) desde el 18 de julio, antes de que se publicara el parche de emergencia
2026	Dirty Frag / CVE-2026-43284, CVE-2026-43500	Kernel de Linux (ESP, rxrpc)	Se publicó un exploit público antes de que ninguna distribución lanzara una corrección

 Dos de ellas tienen una historia más compleja. La investigación en la que se basa ToolShell comenzó como una demostración en el Pwn2Own de Berlín en mayo de 2025, en la que se encadenaron las vulnerabilidades CVE-2025-49704 y CVE-2025-49706, y Microsoft corrigió ambas en julio de ese mismo año. La vulnerabilidad que aparece en la tabla no es esa. 

CVE-2025-53770 es una forma de eludir la corrección de julio, y ya se estaba explotando cuando Microsoft le asignó el número. «Dirty Frag» se encontraba bajo un acuerdo de divulgación coordinada hasta que alguien rompió el embargo y obligó a su publicación anticipada. En ninguno de los dos casos fue necesario que la investigación tuviera un origen malintencionado. Lo importante era que la explotación era posible antes de que los defensores dispusieran de una corrección completa.

Por qué los exploits de día cero son tan peligrosos

Un «zero-day» es peligroso no tanto por ser desconocido como por la diferencia de velocidad. Los atacantes pueden actuar en cuestión de horas. La respuesta de las empresas, limitada por las pruebas, el control de cambios y las ventanas de mantenimiento, suele tardar días o semanas. El informe M-Trends 2026 de Mandiant estima que el tiempo medio para explotar una nueva vulnerabilidad es de siete días negativos, lo que significa que, actualmente, la explotación suele comenzar antes incluso de que exista un parche. La propia línea de tendencia de Mandiant situaba esa misma cifra en 63 días entre 2018 y 2019.

 

1. No hay ningún parche cuando lo necesitas

La mayoría de los procesos de gestión de vulnerabilidades dan por hecho que existe una corrección del proveedor. Durante el periodo previo al parche de una vulnerabilidad de día cero, se recurre en su lugar a controles compensatorios: desactivar una función, restringir la exposición a la red, modificar la configuración o, en Linux, incluir un módulo del kernel en la lista negra y endurecer los perfiles de seccomp. Estas medidas reducen la exposición, pero algunas de ellas también limitan funcionalidades legítimas, por lo que es necesario someterlas a pruebas antes de aplicarlas a toda la flota. En el caso de Dirty Frag, la solución provisional del CERT/CC consistió en incluir en la lista negra esp4, esp6 y rxrpc, descargarlos y vaciar la caché de páginas. Esto también inhabilita IPsec y AFS, por lo que nunca fue una solución definitiva.

Imagina que un equipo que gestiona una plataforma de Kubernetes de 300 nodos recibe ese aviso a mitad de semana, con un exploit público ya adjunto. Para incluir los módulos en la lista de bloqueo, primero hay que demostrar que ningún nodo de la flota necesita IPsec, y esa demostración lleva más tiempo del que necesita un atacante en un host al que ya tiene acceso.

2. La detección basada en firmas parte en desventaja

Tanto los antivirus basados en firmas como los análisis basados en CVE se basan en elementos que ya han sido identificados y catalogados por alguien. Una vulnerabilidad de día cero totalmente nueva aún no cuenta con una firma específica de CVE ni con ninguna comprobación del escáner que la detecte.

La detección basada en el comportamiento cubre parte de esa laguna y es mucho mejor de lo que era hace cinco años. Sin embargo, también presenta falsos positivos, y las vulnerabilidades del núcleo de 2026 pusieron de manifiesto cuáles son sus límites. «Copy Fail» solo afectó a la caché de páginas en memoria, por lo que el archivo en el disco se mantuvo idéntico al nivel de byte y la supervisión de la integridad de los archivos no detectó nada. Al reiniciar el sistema, se recargó la página limpia y ese artefacto concreto desapareció con ella.

A todo esto se suma el problema del escáner. Los equipos se ven desbordados por falsos positivos debido a retroportaciones mal identificadas dejan de leer con atención los resultados de los análisis, y es precisamente en ese momento cuando un hallazgo real pasa desapercibido y se descarta como ruido.

3. Los sistemas al final de su ciclo de vida pueden dejar vulnerabilidades «zero-day» sin parchear de forma indefinida

En un sistema compatible, un «zero-day» es un intervalo de tiempo que suele cerrarse una vez que se dispone de una solución o de una medida correctiva viable. En un versión al final de su ciclo de vida , ya no se recibe nada más del desarrollador original para esa versión, por lo que la ventana permanece abierta hasta que se encuentre otra forma de cerrarla.

Eso se convierte en una deuda de seguridad más que en un incidente aislado. Cada vulnerabilidad recién revelada que afecte a esa versión, sea de día cero o no, añade otro elemento sin parchear, y estos se van acumulando.

Los equipos siguen utilizando sistemas operativos al final de su ciclo de vida (EOL) por motivos reales: pilas de aplicaciones certificadas, limitaciones de hardware y ciclos de validación que se miden en trimestres. El servicio «Endless Lifecycle Support» de TuxCare está pensado precisamente para esa situación, ya que proporciona parches de seguridad para los sistemas y el software en fin de vida útil cubiertos por el servicio, mientras la migración se lleva a cabo según el calendario que la propia empresa establezca. Se trata de un problema distinto al de una vulnerabilidad de «día cero», en la que se espera una solución pero aún no se ha lanzado. En un parque de equipos obsoleto, ambos problemas se agravan mutuamente.

Cómo protegerse contra los ataques de día cero

No se puede realizar una comprobación de CVE sobre algo que aún nadie ha identificado, así que no bases todo el plan en eso. Hay dos objetivos que cobran especial relevancia en este contexto: acortar el tiempo que transcurre entre la creación de una corrección y su implementación efectiva, y limitar el alcance de un exploit una vez que se produce. La detección, la respuesta ante incidentes y el control de acceso siguen siendo importantes, pero es en esos dos aspectos donde la mayoría de los equipos tienen mayor margen de maniobra.

 

Reducir el tiempo necesario para aplicar un parche una vez que existe una solución

No puedes controlar cuándo realiza el envío el proveedor. Lo que sí puedes controlar es el plazo de implementación posterior y, para muchas organizaciones, es en ese plazo —y no en el parche— donde se pierden las semanas.

La aplicación de parches sin reinicio elimina la limitación a nivel del núcleo. Si tu parque informático puede soportar reinicios a lo largo de un día, la aplicación de parches convencional puede ser perfectamente adecuada. Si un reinicio del núcleo implica un plazo de implementación de tres semanas, la aplicación de parches sin reinicio puede reducir drásticamente ese lapso de implementación sin que tengas que aceptar tres semanas de vulnerabilidad mientras tanto.

Reduce el radio de la explosión antes de que sea necesario

Las decisiones sobre medidas de mitigación que se toman bajo presión son malas decisiones. Tómalas cuanto antes.

Esto implica incluir en la lista de bloqueados los módulos del kernel que no se utilizan en tu flota, de modo que la vía de acceso quede cerrada antes incluso de que se revele. Implica aplicar perfiles seccomp a cargas de trabajo no fiables, ejecutores de CI y nodos multitenant. El perfil predeterminado de Docker deniega «unshare», lo que bloquea la configuración del espacio de nombres de usuario y de red que necesita el exploit publicado xfrm/ESP Dirty Frag, y las pruebas realizadas en EKS, GKE y Talos revelaron que «RuntimeDefault» era suficiente para bloquear esa vía de acceso en un kernel que, por lo demás, era vulnerable. Las mismas pruebas revelaron que dejar seccomp sin configurar no equivale a «RuntimeDefault» en EKS o GKE, y que los pods que se ejecutaban sin perfil fueron vulnerados hasta llegar a la raíz del contenedor; por lo tanto, esto solo resulta útil cuando «RuntimeDefault» se aplica realmente, en lugar de darse por supuesto. Cabe señalar que el mismo control no sirvió de nada frente a «Copy Fail», donde AF_ALG seguía siendo accesible incluso con la seguridad de pod restringida. Esto implica mantener el código no fiable alejado de los hosts que albergan credenciales de producción y, a continuación, segmentar los dispositivos para que un concentrador de VPN comprometido no pueda acceder al nivel de la base de datos.

Tanto «Copy Fail» como «Dirty Frag» requieren la ejecución de código local. El riesgo se concentra en cualquier lugar donde un atacante pueda conseguirlo: entornos de CI compartidos, granjas de compilación de contenedores, Kubernetes multitenant o cualquier host al que se pueda acceder tras conseguir un punto de acceso inicial.

Averigua qué es lo que realmente ejecutas y qué es lo que realmente está actualizado

La rapidez de respuesta depende de la precisión del inventario. Un equipo que disponga de una visión en tiempo real de qué servidores ejecutan los núcleos afectados puede aplicarles los parches antes, lo cual es fundamental cuando la vulnerabilidad ya se ha hecho pública. Un equipo que no disponga de esa información se pasa todo el incidente creando una hoja de cálculo.

Hay dos aspectos importantes en este sentido. En primer lugar, un inventario preciso de los activos y las versiones, incluidos los contenedores y los dispositivos. En segundo lugar, una verificación de los parches que refleje el sistema en ejecución, en lugar de los metadatos de los paquetes; es precisamente aquí donde los escáneres que deducen el estado a partir de las cadenas de versión suelen cometer errores al aplicar correcciones retroactivas y sin reinicio.

Realiza el simulacro de exposición antes de que lo necesites. Un martes cualquiera, con un CVE ficticio, y comprueba cuánto tiempo se tarda en determinar qué hosts se ven afectados y si ya se han solucionado. Las lagunas en el inventario suelen ser lo primero que sale a la luz.

Las mejores herramientas para protegerse contra los ataques de día cero

Ninguno de ellos puede garantizar que se detecte una vulnerabilidad desconocida antes de que comience su explotación. Lo que hacen es acortar el margen de tiempo posterior y permitirte comprobar en qué estado te encuentras realmente.

1. TuxCare

TuxCare aborda tres aspectos distintos del problema de los vulnerabilidades de día cero, y esto es algo deliberado y no se debe a una proliferación de productos, ya que las intrusiones no respetan los límites entre el núcleo, el espacio de usuario y el software de origen que ya ha sido abandonado.

KernelCare aplica parches al núcleo de Linux en ejecución sin necesidad de reiniciar el sistema ni de una ventana de mantenimiento, en una amplia gama de las principales distribuciones empresariales, lo cual resulta importante en entornos mixtos en los que el uso de herramientas específicas para cada sistema operativo implica contratos distintos y lagunas de seguridad separadas. LibCare amplía este mismo enfoque a las bibliotecas del espacio de usuario, como glibc y OpenSSL. Soporte de ciclo de vida ilimitado proporciona parches de seguridad para sistemas operativos, entornos de ejecución, bibliotecas y marcos de trabajo cubiertos que han alcanzado el final de su vida útil (EOL) a través de la gestión estándar de paquetes, mucho después de que el desarrollador original haya dejado de ofrecer soporte.

2. Catálogo de vulnerabilidades explotadas conocidas de la CISA

Gratuito, fiable y la forma más rápida de distinguir entre lo que es «teóricamente explotable» y lo que «se está utilizando contra la gente en este mismo momento». El catálogo KEV enumera los CVE cuya explotación en el mundo real se ha confirmado, y las agencias civiles federales del Poder Ejecutivo tienen plazos vinculantes para la corrección de cada entrada.

Úsalo como filtro de clasificación. Un CVE que llega a KEV pasa al principio de la cola, independientemente de su puntuación CVSS. La clave está en el momento, ya que el KEV es un indicador rezagado y un «zero-day» ya se está explotando mucho antes de que aparezca allí. «Copy Fail» se añadió el 1 de mayo, dos días después de su divulgación, y el exploit público llevaba ya esos mismos dos días circulando. Sigue siendo una de las señales públicas más sólidas para dar prioridad a las explotaciones confirmadas.

3. EDR basado en el comportamiento y detección en tiempo de ejecución

Las herramientas de punto final y de tiempo de ejecución que supervisan el comportamiento en lugar de las firmas pueden detectar ataques sin necesidad de contar con una detección específica para cada vulnerabilidad, y ese es precisamente su objetivo. Las herramientas de tiempo de ejecución como Falco, o tu propia eBPF , pueden señalar los patrones de llamadas al sistema en los que se basan los exploits, como las secuencias de «préstamo de páginas» basadas en splice que utilizaba el código publicado de Dirty Frag para acceder a su primitiva de escritura en la caché de páginas.

Hay que tener en cuenta dos cosas. La detección no es sinónimo de prevención, por lo que, para que una alerta surta efecto, sigue siendo necesario que haya alguien despierto que actúe en consecuencia. Además, muchos electrodomésticos y dispositivos de red simplemente no pueden ejecutar un agente, lo cual explica en parte por qué GTIG contabilizó 14 vulnerabilidades «zero-day» en dispositivos periféricos en 2025 y señaló que es probable que esa cifra subestime la verdadera magnitud del problema.

Protege tus sistemas contra las vulnerabilidades de día cero con TuxCare

Las vulnerabilidades de «día cero» no van a desaparecer. La posibilidad de que se empiecen a explotar antes de que haya un parche disponible es una característica inherente al funcionamiento del software, y volverá a producirse sin previo aviso.

Lo que sí puedes controlar es cuánto tiempo permanece abierta la ventana de mantenimiento. La aplicación de parches al núcleo sin necesidad de reiniciar elimina la ventana de mantenimiento de la ecuación. La asistencia técnica ampliada restablece una vía de aplicación de parches para los sistemas en fin de vida útil (EOL) cubiertos. La verificación precisa de los parches te indica qué hosts están realmente solucionados, en lugar de cuáles solo parecen estarlo.

Si utilizas Linux a gran escala y la aplicación de parches al núcleo sigue dependiendo de un calendario de reinicios, soluciona primero ese problema. KernelCare se ha diseñado precisamente para eso.

Preguntas frecuentes