Arreglan Linux, pero aumentan las vulnerabilidades: los parches fallidos se multiplicaron por 11

Un parche puede cerrar una vulnerabilidad y, al mismo tiempo, indicar a los atacantes el camino hacia la siguiente. Terra Security descubrió que en 2026 las correcciones de software de código abierto requirieron con mucha más frecuencia trabajos adicionales. La empresa analizó los registros públicos de CVE y las notificaciones de GitHub, y la historia del núcleo de Linux mostró cómo la corrección de un defecto genera otro.

En 2019–2025 alrededor del 0,2% de las correcciones notificadas en GitHub en un periodo de 90 días recibieron una nueva advertencia de eliminación incompleta de la vulnerabilidad. En 2026 la proporción alcanzó el 2,3%, lo que, según los valores redondeados, equivale a un aumento de aproximadamente 11 veces. La propia Terra estima el incremento en aproximadamente ocho veces, por lo que el múltiplo exacto depende de la metodología y de las cifras iniciales.

En Linux el problema se manifiesta de otra manera. Según los registros de errores del núcleo a fecha del 8 de octubre, el 3,2% de las vulnerabilidades surgieron en código añadido para corregir otra vulnerabilidad. En subsistemas que se modifican activamente, fs/smb y net/sched, la proporción alcanza aproximadamente el 10%. No se trata de cada décimo parche fallido, sino del origen de las vulnerabilidades en subsistemas concretos del núcleo.

Un ejemplo fue la cadena de errores en los sockets Unix de Linux. Un cambio de 2023 rompió el conteo de descriptores de archivo al transmitir mensajes especiales. La corrección del defecto encontrado pudo provocar un bloqueo del núcleo, y la siguiente modificación también resultó incompleta debido al orden de los elementos en la lista. A cada defecto se le asignó un número CVE distinto, aunque la cadena surgió de un mismo mecanismo.

Con mayor frecuencia se esquivan los parches contra SSRF y la contaminación de prototipos de JavaScript. SSRF hace que el servidor se dirija a direcciones ajenas, y la contaminación de prototipos modifica las propiedades de los objetos del programa. Entre las correcciones que fallan, esos defectos aparecen respectivamente 4,6 y 11 veces más a menudo de lo que correspondería por su proporción entre todos los CVE. La causa suele ser controles de entrada demasiado restrictivos.

Los desarrolladores a veces prohíben una dirección peligrosa conocida, pero permiten su notación alternativa. En Roundcube el parche de marzo bloqueó 127.0.0.1, pero no las variantes 127.1 y 0x7f000001, ni los nombres de dominio que apuntan a la misma dirección. Más tarde se publicaron tres parches adicionales. En agosto se descubrió un caso similar de elusión del parche de PaperCut menos de veinticuatro horas después de la primera actualización.

Para las vulnerabilidades ya explotadas, Terra detectó un aumento de aproximadamente cuatro veces en la probabilidad de que el parche fuera eludido posteriormente, en comparación con otros defectos de los mismos proveedores. La IA acelera el análisis de las correcciones. En septiembre los especialistas analizaron el parche de MikroTik con la ayuda de IA en una hora. Sin embargo, la coincidencia de las dos tendencias no prueba que la IA sea la causante del aumento en el número de correcciones fallidas.

Terra aconseja comprobar los parches antes de su publicación en busca de formas alternativas de explotación, corregir la causa del error y buscar efectos secundarios. A los administradores se les recomienda no considerar la instalación de la actualización como una garantía plena de seguridad, especialmente después de ataques reales. Las pruebas repetidas deben demostrar si se han cerrado todas las vías de elusión, y no solo el escenario inicial.