Un análisis de Terra Security encontró que la proporción de avisos de GitHub sobre parches fallidos dentro de 90 días pasó de cerca de 0,2% en 2019-2025 a 2,3% en 2026. La firma también detectó una mayor presencia de vulnerabilidades explotadas y advierte que corregir sin revisar la causa raíz puede dejar brechas abiertas o crear otras nuevas.
***
- Los avisos de GitHub sobre correcciones de seguridad eludidas dentro de 90 días subieron a 2,3% en 2026, frente a cerca de 0,2% anual entre 2019 y 2025.
- Terra Security halló que esos fallos de parche tenían unas cuatro veces más probabilidades de aparecer en la lista de vulnerabilidades explotadas de CISA.
- La firma señala riesgos particulares en parches contra SSRF y contaminación de prototipos, además de correcciones del kernel de Linux que pueden introducir nuevas fallas.
Un repunte en los parches que no resisten
Actualizar el software sigue siendo una medida esencial de seguridad, pero una corrección puede quedarse corta y permitir que un atacante rodee la defensa. Terra Security, una empresa especializada en pruebas de penetración con inteligencia artificial, observó un aumento marcado de avisos sobre parches fallidos durante 2026, después de varios años con cifras bajas. El hallazgo no significa que instalar actualizaciones haya dejado de ser útil; sí cuestiona la idea de que aplicar una corrección basta para cerrar un incidente.
La empresa revisó registros de CVE y avisos de GitHub para identificar casos en que una corrección fue seguida por reportes de que el parche podía eludirse. Entre 2019 y 2025, la proporción de correcciones de seguridad de GitHub que necesitaron un aviso de seguimiento por una falla de parche dentro de 90 días se mantuvo cerca de 0,2%. En 2026, esa proporción llegó a 2,3%, un salto que convierte un problema antes poco frecuente en una señal relevante para quienes desarrollan y mantienen software, informa The Register.
El patrón descrito por los investigadores no termina necesariamente con la primera actualización: se publica una corrección, alguien encuentra una forma de sortearla y el proveedor debe preparar otra. Esa secuencia importa porque cada parche pretende reducir una exposición, pero un arreglo incompleto puede prolongar el periodo de riesgo y exigir nuevas revisiones. Terra vinculó el fenómeno con la expansión de la búsqueda de vulnerabilidades y de la aplicación de parches mediante IA durante este año, aunque sus cifras describen una coincidencia temporal y no demuestran por sí solas una causa única.
La preocupación no se limita a contar correcciones que necesitaron una segunda versión. Según Terra, las vulnerabilidades cuyos parches fueron eludidos tenían alrededor de cuatro veces más probabilidades de figurar en la lista de Vulnerabilidades Explotadas Conocidas de la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) que otros errores de los mismos proveedores. Esa comparación sugiere que los fallos de parche pueden coincidir con riesgos prácticos de explotación, aunque no implica que cada corrección incompleta haya sido utilizada contra una víctima.
Windows y las clases de errores difíciles de cerrar
Un caso citado en el análisis involucra a espías cibernéticos del gobierno ruso y una falla de elusión de seguridad de Windows Shell, identificada como CVE-2026-21510. De acuerdo con la información recogida por la fuente, los atacantes explotaron la vulnerabilidad de día cero al menos un mes antes de que Microsoft publicara una corrección en febrero. El arreglo, sin embargo, no cerró por completo el problema: quedó una segunda vulnerabilidad relacionada con coerción de autenticación y explotación sin clic.
La falla secundaria recibió el identificador CVE-2026-32202 y también fue descubierta y utilizada antes de que Microsoft la corrigiera en abril. Akamai describió en su análisis “A Shortcut to Coercion: Incomplete Patch of APT28’s Zero-Day” cómo un parche incompleto derivó en una vulnerabilidad de cero clics que permite coerción NTLM. La secuencia ilustra cómo un parche puede atender un aspecto de una vulnerabilidad y dejar expuesta otra vía vinculada al mismo escenario, sin que eso convierta automáticamente todos los parches en inseguros. En este caso, el intervalo entre la explotación y las correcciones, junto con el segundo fallo, muestra por qué los equipos defensivos necesitan seguir evaluando una amenaza después de instalar una actualización.
Terra encontró que dos tipos de vulnerabilidad aparecen con una frecuencia desproporcionada entre los parches fallidos: la falsificación de solicitudes del lado del servidor, conocida como SSRF, y la contaminación de prototipos. Frente a su participación entre todos los CVE, los errores de contaminación de prototipos fueron unas 11 veces más comunes entre los casos de corrección fallida; los de SSRF, 4,6 veces más comunes. Esas proporciones no indican que todos los fallos de esas clases sean explotables, pero sí apuntan a desafíos recurrentes al diseñar mitigaciones.
La dificultad, según los investigadores, está en que algunas correcciones para estas clases de errores se apoyan en listas de bloqueo de entradas, como nombres de host, rutas o claves de objetos. Si la lista no contempla todas las formas en que puede codificarse una entrada maliciosa, un atacante podría buscar una variante que la evada. Por eso, una regla que rechaza ciertos valores puede frenar intentos conocidos sin necesariamente eliminar la causa raíz, y la revisión debe abarcar el comportamiento completo que originó la vulnerabilidad.
El costo de corregir sin revisar el efecto
El problema de las correcciones incompletas también aparece en los registros del kernel de Linux analizados por Terra hasta el 8 de octubre. Los investigadores señalaron que 3,2% de los CVE del kernel fueron introducidos por la corrección de otro CVE, lo que refleja que un arreglo puede generar una falla distinta además de tratar de remediar la original. En subsistemas con mucha actividad, como fs/smb y net/sched, la proporción rondó 10%, según los datos citados en el informe.
Esas cifras añaden una dimensión distinta al debate: no solo existe el riesgo de que un atacante encuentre una ruta para superar un parche, sino también que el cambio afecte otras partes del sistema. El dato no equivale a afirmar que cada actualización del kernel sea peligrosa ni permite concluir que todos los subsistemas tengan el mismo comportamiento. Sí respalda la necesidad de probar los cambios y revisar su alcance antes de desplegarlos, especialmente en componentes donde se acumulan correcciones y actividad de desarrollo.
La recomendación de Terra para los proveedores es abandonar la rutina de publicar un parche y dar el asunto por cerrado. Antes de distribuir una corrección, plantea tres preguntas: si resuelve la causa raíz, si cubre toda la clase de errores y si rompe algo más. La primera apunta a evitar soluciones limitadas a un síntoma; la segunda obliga a considerar variantes del mismo problema, y la tercera recuerda que el propio cambio puede introducir consecuencias no previstas.
Los administradores de sistemas y responsables de gestionar actualizaciones también deberían aplicar ese examen al recibir una corrección, aconseja la firma. Si el proveedor arregla un error que ya fue explotado, los defensores deben asumir que alguien puede estudiar el parche para buscar una manera de eludirlo, una advertencia que no reemplaza la instalación de actualizaciones. El cambio que propone Terra es pasar de una lógica de aplicación automática y cierre del caso a otra que combine rapidez, evaluación de la causa y seguimiento de posibles bypass.
Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.
Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
Energía
Geotermia submarina: una prueba logra energía neta positiva durante apenas 8,7 segundos
Bitcoin
MARA minó más Bitcoin, pero sus ingresos cayeron 27% y su apuesta por la IA sigue sin clientes
Empresas
Anthropic negocia con Nscale una compra de capacidad informática por USD $45.000 millones
IA
