Las actualizaciones de seguridad son esenciales para proteger software y usuarios, pero paradójicamente también pueden actuar como un mapa que indica a los hackers por dónde atacar vulnerabilidades aún no corregidas o surgir nuevas. Esta preocupante conclusión proviene de un estudio del laboratorio Terra Security.
Según Oren Yomtov, investigador de Terra Security, los parches de seguridad no solo cierran errores, sino que revelan exactamente dónde estaba el fallo original y de qué manera el desarrollador intentó solucionarlo. Esa información es un recurso valioso para los ciberdelincuentes, quienes observan las correcciones para identificar «lagunas» que el parche no abordó completamente y explotarlas en ataques sucesivos.
Terra Security ha detectado que la tasa de parches que requieren a su vez un nuevo parche debido a fallos detectados posteriormente se ha multiplicado por ocho desde principios de 2026. Aunque el informe no atribuye este incremento de forma directa a la inteligencia artificial, señala que coincide con la aparición de nuevos modelos de seguridad basados en IA, como Claude Mythos de Anthropic y GPT-5.5-Cyber de OpenAI, que aún se distribuyen de forma restringida. 
El auge de la inteligencia artificial, sin embargo, ha impulsado notablemente la detección de fallos de seguridad. Este incremento ha contribuido a descubrir vulnerabilidades que antes pasaban desapercibidas, pero también ha aumentado la complejidad a la hora de aplicar parches definitivos.
El desafío de identificar «parches rotos»
Durante el último año, Terra Security ha registrado un patrón preocupante: parches que rápidamente son sorteados por atacantes, lo que obliga a lanzar arreglos adicionales. Para comprobar que no se trataba de una experiencia aislada, los investigadores analizaron la base de datos CVE (Common Vulnerabilities and Exposures) y los avisos de seguridad publicados en GitHub.
El aumento no es exclusivo de Terra. Según Yomtov, el porcentaje de parches que requerían correcciones adicionales en proyectos de código abierto en GitHub se mantuvo constante y baja durante años, hasta que en 2026 se disparó aproximadamente ocho veces. Las cifras muestran que los reportes de parches que precisaron un arreglo en un plazo de 90 días crecieron de menos del 0,5% a un 2,3% en pocos meses, a partir de marzo de 2026.
Este patrón también está reflejado en la base de datos CVE, con una cobertura más amplia que confirma la misma tendencia en ese mismo año. Además, resulta especialmente preocupante que los parches dirigidos a vulnerabilidades conocidas y explotadas tengan cuatro veces más probabilidades de ser considerados «rotos» en comparación con otros fallos del mismo proveedor.
La explicación principal es que las vulnerabilidades explotadas atraen más atención de investigadores y atacantes, quienes analizan el parche en busca de fallos no cubiertos o nuevas formas de vulnerar el sistema.
Estrategias para enfrentar la creciente complejidad
Según Yomtov, los equipos de seguridad deben cambiar su mentalidad ante los parches. La práctica común de «parchar y pasar a otro asunto» se revela como inadecuada, especialmente para vulnerabilidades críticas o explotadas activamente.
Entre los tipos más frecuentes de parches defectuosos se encuentran aquellos dirigidos a problemas como la falsificación de solicitudes del lado servidor (SSRF) y la contaminación de prototipos, donde la estrategia habitual consiste en crear listas de entradas bloqueadas. El problema es que si esa lista no contempla todas las variantes posibles de entrada maliciosa, los atacantes solo necesitan hallar una que no esté bloqueada para infiltrarse.
Este enfoque limitado no solo deja huecos de seguridad, sino que facilita el trabajo de potenciales atacantes, ya que el parche actúa como un mapa que indica qué parte del código ha sido protegida y cuál aún permanece vulnerable. De este modo, un parche puede dar una falsa sensación de seguridad al bloquear un caso concreto, mientras la vulnerabilidad persiste en el código subyacente.
Por este motivo, los profesionales de seguridad deberían analizar no solo el fragmento de código modificado (el llamado «diff») sino también las áreas circundantes para detectar posibles puntos débiles. Yomtov asegura que este tipo de análisis manual y exhaustivo es hoy una de las técnicas más económicas y efectivas para identificar vulnerabilidades.
Además, recomienda que antes de desplegar un parche se realice un «diff-hunt», una revisión exhaustiva para evaluar si el parche realmente corrige la raíz del problema o simplemente bloquea una entrada determinada, y si cubre toda la clase de vulnerabilidades relacionada o potencialmente introduce nuevos fallos.
Esta misma precaución debe aplicarse a los parches que se reciben de terceros: si un proveedor corrige una vulnerabilidad explotada, es seguro asumir que los atacantes examinarán ese parche en busca de formas de eludirlo.
