Vulnerabilidades sin parchear: riesgos, causas y soluciones

Principales conclusiones

• Una vulnerabilidad sin parchear es aquella para la que ya existe una solución, pero que aún no se ha aplicado.
• Según el informe «M-Trends 2026» de Mandiant sitúa el tiempo medio hasta la explotación en menos siete días, por lo que, de media, los atacantes se adelantan al parche.
• El Informe DBIR de Verizon de 2026 reveló que solo el 26 % de las vulnerabilidades de KEV detectadas se habían corregido por completo, con una mediana de 43 días para lograrlo.

La mayoría de equipos de seguridad tienen la misma lista de tareas pendientes. En ella figuran los CVE que se clasificaron, se registraron, se programaron y, posteriormente, se aplazaron discretamente porque la ventana de mantenimiento coincidía con el cierre del trimestre. Se trata de vulnerabilidades sin parchear, y su explotación se ha convertido en la principal forma conocida que tienen los atacantes de obtener acceso inicial.

La brecha que realmente importa es la que existe entre el momento en que un parche está disponible y el momento en que ese parche se ejecuta realmente en producción. El resto de esta entrada analiza por qué sigue abierta y cómo cerrarla.

¿Qué se considera una vulnerabilidad sin parchear?

Una vulnerabilidad sin parchear es un fallo conocido para el que existe una solución, pero que sigue presente en un sistema en el que dicha solución no se ha aplicado. Se trata de tres elementos, todos ellos imprescindibles: un fallo conocido, una solución disponible y un sistema que aún no la tiene.

Esa parte central, la solución disponible, es lo que la diferencia de sus dos vecinas.

Una vulnerabilidad de día cero se aprovecha antes de que los defensores hayan tenido una oportunidad razonable de reaccionar, normalmente antes de que se haga pública o de que exista un parche. Hasta que se publique una solución, las medidas de mitigación son lo único con lo que cuentas. Nuestro análisis de cómo los exploits de día cero abarca ese caso.

Software al final de su ciclo de vida es el otro vecino. Es posible aplicar correcciones, pero el proveedor original ha dejado de ofrecerlas. CentOS 7, PostgreSQL 13, una rama de PHP en fin de vida útil : vulnerabilidades CVE reales, exposición real, sin soporte por parte del desarrollador original.

Sobre el papel, la vulnerabilidad sin parchear es la más evitable de las tres, ya que la solución ya existe y suele ser gratuita. En la práctica, un parche gratuito sigue suponiendo un coste en forma de tiempo de pruebas y una ventana de mantenimiento, lo cual constituye la mitad de lo que trata este artículo.

El plazo entre la revelación de una vulnerabilidad y su explotación es más corto de lo que suelen suponer la mayoría de los ciclos de parches, y no siempre se desarrolla de forma lineal.

Escenario	Cuando ocurre	¿Qué está pasando?
Se ha dado a conocer el CVE y se ha publicado el parche	El mismo día o con semanas de diferencia	Se suele combinar para el RCE crítico
Prueba de concepto pública o código de explotación	Desde antes de la divulgación hasta semanas después	GitHub, marcos de explotación, informes de investigación
Escaneo masivo en Internet	Pocas horas después de una prueba de concepto (PoC) funcional	Los atacantes identifican las instancias expuestas a gran escala
Explotación activa, inclusión en la lista KEV	Puede comenzar antes de la divulgación, y la inclusión en la lista de la KEV se produce después de que la CISA lo confirme.	Ahora es un vector de ataque confirmado y en uso

La gravedad y la probabilidad de explotación son indicadores distintos. Un CVSS de 9,8 en un servicio que no está expuesto puede ser menos peligroso que un CVSS de 6,5 en tu perímetro. Consulta nuestra guía sobre las novedades de CVSS v4.0.

El coste real de las vulnerabilidades sin parchear

Empieza con una cifra que deberías dejar de repetir: «las vulnerabilidades sin parchear causan el 60 % de las filtraciones». Esa cifra se remonta a una encuesta realizada en 2019 por el Ponemon Institute para ServiceNow, y ya no debería citarse como una cifra actual y válida para todo el sector.

Los datos actuales ofrecen una imagen más clara. Según el informe DBIR de Verizon de 2026, el 31 % de las filtraciones se originaron a raíz de la explotación de vulnerabilidades, frente al 20 % del año anterior. Esto lo convirtió, por primera vez en la historia del informe, en el principal vector de acceso inicial conocido en el conjunto de datos de Verizon. Las filtraciones también se encarecieron. El Informe sobre el coste de una filtración de datos de IBM de 2026 sitúa el el coste medio global de una filtración en 4,99 millones de dólares, lo que supone un récord.

El ransomware es la excepción. Según la encuesta «Estado del ransomware en 2026» de Sophos, solo el 18 % de las víctimas de ransomware atribuyó el ataque a una vulnerabilidad explotada, lo que supone un descenso respecto al 32 % del año anterior, ya que los correos electrónicos maliciosos y el phishing se convirtieron en las principales causas. La aplicación de parches sigue siendo importante en este caso. Simplemente, ya no es la única vía de acceso.

Los perjuicios se traducen en riesgos normativos, extorsión mediante ransomware y tiempo de inactividad, incumplimientos normativos y un lastre reputacional que perdura más allá de todo ello. Nuestro desglose de los costes reales de no aplicar parches a una CVE crítica profundiza en cada uno de ellos.

Tres casos de violación de la seguridad ilustran cómo se desarrolla esto, cada uno de forma ligeramente diferente.

Incidente	CVE	Hay un parche disponible	Explotación	Repercusiones
Equifax	CVE-2017-5638 (Apache Struts 2)	Marzo 7, 2017	El portal fue analizado y se detectó una vulnerabilidad el 10 de marzo de 2017; se accedió a datos personales a partir del 13 de mayo, lo cual se detectó el 29 de julio.	147 millones de personas, además de un acuerdo entre la FTC, la CFPB y los estados por un importe mínimo de 575 millones de dólares
MOVEit Transfer	34362	May 31, 2023	La explotación masiva de Cl0p como vulnerabilidad de día cero tuvo lugar entre el 27 y el 28 de mayo de 2023, y los servidores sin parches siguieron siendo objeto de ataques durante semanas después.	2.773 organizaciones, aproximadamente 95,8 millones de personas (Emsisoft)
Log4Shell	44228	Log4j 2.15.0, 10 de diciembre de 2021, con correcciones posteriores unos días después	Análisis a partir del 1 de diciembre de 2021: explotación masiva a las pocas horas de la divulgación	Casi 40 millones de descargas vulnerables de Log4j solo en 2025, lo que supone aproximadamente el 13 % del total de ese año (Sonatype)

Equifax es el caso claro de una vulnerabilidad sin parchear. La corrección se publicó el 7 de marzo, los atacantes empezaron a sondear el portal tres días después y el robo masivo de datos comenzó 67 días después de que el parche estuviera disponible. MOVEit y Log4Shell comenzaron como vulnerabilidades de día cero, pero se convirtieron casi de inmediato en casos de vulnerabilidades sin parchear, una vez que existían las correcciones y muchas instalaciones seguían ejecutando la versión vulnerable de todos modos.

Por qué no se corrigen las vulnerabilidades (las razones que los equipos rara vez admiten)

Cada una de estas decisiones es racional a nivel local, pero, en conjunto, dan lugar a un resultado irracional en el conjunto de la organización.

Motivo	Cómo se ve	¿Qué lo elimina?
Miedo a los tiempos de inactividad	El kernel CVE necesita un reinicio, y el servidor es de estado y no dispone de conmutación por error	Parcheo del kernel sin reinicio
Software en fin de vida útil, sin parches de origen	Servidor CentOS 7 en el que se ejecuta una aplicación que no se compila en versiones más recientes	Soporte ampliado respaldado por el proveedor o una fecha de migración financiada
Parches que nunca llegan	La automatización registra un índice de éxito del 98 %. El 2 % restante se encuentra en una situación delicada.	Conciliación entre los datos de las plantillas de parcheo y los escaneos independientes
Activos desconocidos	Una máquina virtual de prueba de 2021, un contenedor de un contratista, un subdominio olvidado	Detección continua y permanente
Coste de las pruebas	Cada parche se somete a pruebas de regresión con un monolito que nadie entiende del todo	Pruebas clasificadas por niveles de riesgo, con correcciones de seguridad críticas que se implementan de forma prioritaria mediante despliegues por fases
Hay más CVE que tiempo para clasificarlos	48 185 CVE publicados en 2025. Tres personas no pueden leer eso.	Filtrado basado en la vulnerabilidad

 El volumen por sí solo ya es una razón. El investigador en seguridad Jerry Gamblin sobre los datos de CVE de 2025 registró 48 185 registros publicados, aproximadamente 132 al día, mientras que la propia página EPSS de FIRST sugiere que solo un porcentaje bajo, de un solo dígito, de los CVE publicados es objeto de explotación en un periodo de 30 días cualquiera. La mayor parte de la lista no será objeto de un ataque este mes. Lo difícil es saber qué pequeña parte sí lo será.

Luego está la acumulación. Los parches pospuestos se acumulan y se convierten en deuda de seguridad, del mismo modo que las refactorizaciones pospuestas se acumulan y se convierten en deuda técnica, y el «interés» se manifiesta en forma de incidente. El ruido de los escáneres empeora la situación, porque los equipos que pierden semanas persiguiendo un falso positivo pierden la credibilidad que necesitan cuando aparece uno real. El fin de la vida útil del sistema operativo forma parte de ese mismo ciclo continuo de detección.

Una situación habitual en las empresas medianas no es que un equipo decida no aplicar los parches. Se trata de que una herramienta de coordinación informe de que todo va bien en un servidor que, meses antes, había dejado de estar conectado al agente de gestión de la configuración sin que nadie se diera cuenta. Nadie mintió. La capa de generación de informes midió lo que no debía.

Cómo aprovechan los atacantes las vulnerabilidades sin parchear

Piénsalo desde el punto de vista del atacante. Un «zero day» supone tiempo de investigación, o una cantidad de seis cifras o más en un mercado de intermediarios. Un «n-day», es decir, un fallo con una solución pública, puede costar poco más que una consulta en Shodan, siempre que haya una prueba de concepto que funcione y suficientes objetivos expuestos a los que dirigirlo. Los atacantes recurren a los «zero days» cuando no les queda más remedio y a los «n-days» siempre que pueden, y el proceso de divulgación repone el inventario de «n-days» cada día.

El informe «M-Trends 2026» de Mandiant ofrece una cifra concreta sobre hasta qué punto se ha reducido esa brecha. El tiempo medio hasta la explotación se estima ahora en siete días negativos, lo que significa que, de media, la explotación comienza antes de que se publique el parche. Los exploits han ocupado el primer puesto como vector de infección inicial más común durante seis años consecutivos, y ahora representan el 32 % de las intrusiones en las que Mandiant pudo identificar el punto de entrada.

El catálogo de vulnerabilidades explotadas conocidas de la CISA es el marcador público de los fallos que han pasado de ser teóricos a ser utilizados activamente, y crece cada semana. Los plazos que establece para las agencias civiles federales de EE. UU. cambiaron en 2026. La directiva BOD 22-01, que desde 2021 concedía a las agencias dos semanas para corregir las entradas del KEV (seis meses para los CVE más antiguos), fue sustituida, junto con la anterior BOD 19-02, por la la BOD 26-04, «Priorización de las actualizaciones de seguridad en función del riesgo», publicada el 10 de junio de 2026.

En lugar de un plazo único y fijo, la nueva directiva puntúa cada vulnerabilidad en función de cuatro factores: ¿Está el activo expuesto públicamente? ¿Se trata de un fallo en KEV? ¿Se puede automatizar su explotación? ¿Otorga al atacante un control total del sistema, o solo parcial? Las respuestas determinan el plazo. Las combinaciones más arriesgadas tienen tres días, y los casos de KEV de mayor riesgo con control total también requieren una evaluación forense para comprobar si el sistema ya estaba comprometido. Todo lo demás dispone de 14 o 60 días, y las fallas que no cumplen ninguno de los cuatro factores pueden esperar a la próxima actualización programada del activo.

Muchas de las vulnerabilidades más explotadas son fallos que permiten la ejecución remota de código en servicios conectados a Internet y dispositivos periféricos, y a veces el sistema vulnerable ni siquiera es de tu propiedad para que puedas aplicar el parche. MOVEit es el ejemplo más claro de los últimos tiempos. Una vulnerabilidad en un producto de transferencia de archivos muy utilizado provocó miles de víctimas en la cadena de distribución.

En el caso de los organismos civiles federales, el límite máximo para el nivel más grave es ahora de tres días, y un comité asesor de cambios semanal no puede alcanzarlo. Si tu respuesta más rápida posible ante un RCE expuesto a Internet y que está siendo explotado activamente RCE expuesta a Internet y que está siendo explotada activamente, eso supone una deficiencia en el proceso que conviene subsanar antes de que aparezca la siguiente.

Cómo evitar que se acumulen las vulnerabilidades sin parchear

Se trata de un problema de proceso con cinco elementos, y pasar directamente a establecer prioridades antes de haber elaborado un inventario solo significa dar prioridad a un subconjunto que no puedes definir por completo.

Detecta primero todas las vulnerabilidades sin parchear

En este caso, la amplitud es más importante que la sofisticación. Un modelo de priorización perfecto que cubra el 70 % de tu patrimonio te resulta menos útil que una clasificación básica que lo abarque todo.

Elabora tu inventario desde más de un punto de vista, ya que cada fuente omite algo diferente. La gestión de la configuración y el inventario de agentes no detectan todo lo que se ha desvinculado del agente. Las API de los proveedores de servicios en la nube no detectan los sistemas locales ni las cuentas ocultas. El escaneo de red autenticado no detecta los hosts que estaban apagados durante el periodo de escaneo. El DNS y la detección de la superficie de ataque externa son los que detectan el subdominio que nadie recuerda que le pertenece.

A continuación, compara ambas listas. La parte útil es aquella en la que las listas no coinciden. Un host que aparece en tu inventario en la nube pero no en los resultados de tu escáner es precisamente el tipo de laguna que te expone a una brecha de seguridad. Una vez que la lista de activos esté en orden, compara los paquetes y versiones instalados en cada host con los avisos de seguridad que les corresponden, para saber cuáles de esos hosts son realmente vulnerables.

Comprueba también que los parches notificados se hayan aplicado realmente. El hecho de que haya un paquete del núcleo más reciente en el disco no significa que el núcleo en ejecución esté protegido. A menos que el servidor se haya reiniciado con ese paquete o haya recibido un parche en tiempo real para ese CVE, se trata de una vulnerabilidad que lleva la etiqueta de «corregida».

Priorizar según la explotabilidad real

El recuento bruto de CVE mide la carga de trabajo. Para evaluar el riesgo real se necesitan tres datos más.

Empieza por KEV. Una inclusión en la lista significa que se ha confirmado su explotación en el mundo real, así que, si afecta a tus activos, aplícale el parche ahora mismo, independientemente de la puntuación CVSS. A continuación, comprueba la puntuación EPSS, una probabilidad actualizada diariamente entre 0 y 1 de que un CVE publicado sea explotado en el mundo real durante los próximos 30 días. Es gratuita, legible por máquina y está diseñada precisamente para tomar esta decisión. Por último, evalúa por separado la exposición y la importancia para el negocio. ¿El activo está expuesto a Internet o es accesible desde sistemas en los que un atacante ya podría encontrarse? ¿Almacena datos sensibles o sujetos a normativa?

Las propias comparaciones de FIRST demuestran claramente la eficiencia de este enfoque. Una regla general que aplique el CVSS 7 o superior lleva a que una gran parte de la cola pase a la fase de corrección, mientras que un umbral basado en el EPSS detecta una gran parte de lo que realmente se explota con solo una pequeña fracción del trabajo. Sin embargo, no existe un umbral universal que se pueda copiar. El umbral adecuado depende de tu propia cola.

Si tu equipo cuenta con recursos insuficientes, empieza por KEV y la exposición, y ve incorporando EPSS más adelante. Si ya aplicas los parches de KEV de forma fiable, EPSS es lo que te proporcionará el siguiente nivel de reducción de riesgos.

Aplica los parches rápidamente y elimina los motivos por los que no puedes hacerlo.

La rapidez se consigue eliminando la fricción del proceso. Automatiza la implementación para que la aplicación de parches se realice como un proceso continuo en lugar de como un proyecto puntual, ya que un parche cuya programación depende de una persona tiende a retrasarse.

A continuación, aborda directamente la dependencia del reinicio. Los reinicios son una de las razones más habituales por las que los parches del núcleo quedan sin aplicar. Obligan a abrir una ventana de mantenimiento, crear un ticket de cambio y que alguien esté despierto a las 2 de la madrugada para confirmar que el servidor ha vuelto a ponerse en marcha. La aplicación de parches sin reinicio, a veces denominada «parches en vivo», aplica la corrección al núcleo que se está ejecutando en memoria, de modo que, para las vulnerabilidades compatibles, la brecha se cierra sin interrupción del servicio.

KernelCare lo hace en las principales distribuciones de Linux para empresas, por lo que un entorno mixto no necesita una herramienta distinta para cada sistema operativo, y las cargas de trabajo 24/7 dejan de sacrificar el tiempo de actividad a cambio de la exposición a vulnerabilidades CVE.

Incluir el software al final de su ciclo de vida (EOL) para el que no haya parches del fabricante

Todo lo anterior parte de la base de que el proveedor sigue ofreciendo una solución. En el caso de los componentes al final de su ciclo de vida (EOL), el proveedor original no lo hace, y el consejo habitual de simplemente actualizar pasa por alto la razón por la que el sistema sigue funcionando en primer lugar.

Por lo general, el problema radica en que el hardware no es compatible con un kernel más reciente, en que el proveedor de una aplicación solo ha certificado una versión del sistema operativo, en que la validación normativa habría que volver a realizarla desde cero o en que la capacidad de ingeniería ya está comprometida para las tres cuartas partes del año. Un correo electrónico severo sobre las fechas de fin de vida útil no resuelve ninguno de estos problemas.

Eso nos deja tres opciones viables.

Opción	Ideal para cuando	Estad atentos a
Migrar ahora	La aplicación es portátil y tienes capacidad este trimestre	Los deslizamientos son normales, y la exposición continúa durante el deslizamiento.
Solo controles de compensación	Totalmente aislado, sin rutas de entrada no fiables	El aislamiento se va deteriorando poco a poco. Basta con un cambio en el cortafuegos para que vuelva a abrirse.
Soporte ampliado ofrecido por el fabricante	Necesitas que se solucionen los CVE mientras realizas la migración según tu propio calendario	Confirma exactamente qué paquetes del sistema operativo, entornos de ejecución y bibliotecas están incluidos

Esa tercera vía es la que se encarga el servicio «Endless Lifecycle Support» de TuxCare de TuxCare. Proporciona parches de seguridad para los entornos de ejecución, las bibliotecas, los marcos de trabajo y las aplicaciones que ya no cuentan con soporte por parte del desarrollador original, junto con las distribuciones de Linux en fin de vida útil (EOL) en las que se basan, a través de la gestión estándar de paquetes. Los sistemas cubiertos siguen recibiendo correcciones de seguridad, con la correspondiente documentación, mientras que la migración se lleva a cabo en un plazo que la empresa puede realmente financiar.

Verificar las medidas correctivas y demostrarlo

Aplicar parches sin verificarlos es una forma de pensar. Hay dos razones por las que resulta difícil confiar en el estado de los parches.

El primero es un fallo silencioso. El paquete se instaló, pero el servicio nunca se reinició, o el host revertió los cambios, o la actualización se aplicó a la imagen base y no al contenedor en ejecución. El segundo es un falso positivo. Un escáner lee una cadena de versión, no detecta una corrección retroportada y marca un CVE cerrado como si aún estuviera abierto.

Una buena verificación aporta varios resultados concretos. Se obtiene la confirmación, directamente del sistema en funcionamiento, de que el código corregido se ha cargado realmente, además de una conciliación entre el informe de tu herramienta de parches y un análisis independiente. Cada host y cada CVE cuenta con un registro fechado y exportable, listo para ser presentado a un auditor. Además, en tus tickets, el estado «corregido» se considera confirmado, mientras que «intentado» se registra como un estado independiente.

La verificación que tiene en cuenta las adaptaciones hacia versiones anteriores es el punto débil de Linux, ya que los escáneres genéricos suelen interpretar erróneamente los paquetes en los que la distribución ha adaptado una corrección hacia una versión anterior, manteniendo el número de versión del desarrollador original. Sea cual sea el escáner que utilices, compara sus resultados con los avisos de seguridad de la propia distribución antes de dedicar un sprint a un CVE que ya esté cerrado.

Cómo TuxCare reduce la brecha

La brecha entre «parche disponible» y «parche en ejecución» es donde se producen muchas brechas de seguridad. Equifax disponía de la solución desde hacía 67 días antes de que comenzara el robo de datos. En el caso de Log4Shell, los atacantes ya estaban activos antes de que existiera el primer parche. Los equipos que logran cerrar esa brecha suelen ser aquellos que han eliminado las causas estructurales del retraso, a saber: los callejones sin salida por fin de vida útil (EOL), los paquetes vulnerables que siguen colándose en las compilaciones y los reinicios.

El enfoque de TuxCare se ajusta directamente a esos tres aspectos. Soporte de ciclo de vida ilimitado abarca los entornos de ejecución, los marcos de trabajo, las aplicaciones y los sistemas operativos que sus proveedores originales ya han dejado de mantener. SecureChain sustituye los registros públicos por uno gestionado por TuxCare, con paquetes seleccionados y actualizados continuamente para JavaScript, Python, Java, Go y PHP, lo que ayuda a mantener las versiones con vulnerabilidades conocidas fuera de las nuevas compilaciones. KernelCare se encarga de aplicar parches al núcleo sin necesidad de reiniciar en entornos Linux mixtos. Elige la opción que mejor se adapte a tu perfil de riesgo.

Empieza por hacer un inventario en el que confíes. A continuación, decide qué arreglar primero.

Preguntas frecuentes