Más allá de la automatización: Motivos por los que el aumento de las vulnerabilidades de seguridad basadas en la inteligencia artificial exige una defensa técnica humana

Los futuros historiadores recordarán la primavera de 2026 como el comienzo de la notificación de vulnerabilidades de seguridad basadas en la inteligencia artificial. El 7 de abril, Anthropic anunció una versión preliminar de su modelo de inteligencia artificial Claude Mythos, disponible para empresas seleccionadas como parte de Project Glasswing. La iniciativa afirmó que había descubierto miles de vulnerabilidades de gravedad alta y crítica en todo el ecosistema open source. Tres semanas después, la iniciativa Xint anunció una vulnerabilidad de escalada de privilegios locales en el kernel de Linux que denominó Copy Fail. Unos días después, el mundo se despertó con otra vulnerabilidad denominada Dirty Frag, y luego otra llamada Fragnesia. Habrá más próximamente.

Project Glasswing, Copy Fail y Dirty Frag comparten problemas de divulgación responsable. Project Glasswing compartió poca información práctica, a pesar de la gran expectación. Los investigadores detrás de Copy Fail compartieron los hallazgos con los desarrolladores de kernel.org, pero no con los proveedores de sistemas. Alguien filtró prematuramente los detalles de Dirty Frag, lo que obligó al investigador Hyunwoo Kim a revelar los detalles en un hilo de correo electrónico público antes de que alguien pudiera desarrollar parches.

Esta publicación de blog examina la respuesta de Red Hat a Copy Fail y analiza cómo nuestro servicio de gestión de cuentas técnicas para la seguridad de los productos puede ayudar a las organizaciones a gestionar su estrategia de seguridad en esta nueva era de divulgaciones generadas por inteligencia artificial rápidas e implacables.

Historial y antecedentes de Red Hat Product Security

El equipo de Red Hat Product Security ha sido líder en la comunidad de seguridad de la TI desde 2001 y ha evolucionado constantemente con el panorama de las amenazas 

CVE.org gestiona la notificación de vulnerabilidades de software en toda la industria de TI mediante un concepto denominado Common Vulnerabilities and Exposures (CVE). Una autoridad de numeración de CVE (CNA) es una organización miembro que publica CVE. CVE.org cuenta con más de 500 miembros de CNA en toda la industria de TI. Una CNA-LR es una autoridad de numeración de CVE de último recurso. Las organizaciones miembro confían en ellas para resolver disputas sobre los CVE. Las organizaciones raíz enseñan a otras CNA cómo enviar CVE.

Hoy en día, Red Hat es la única empresa del sector privado en el mundo que desempeña la función de CNA-LR, y una de las dos únicas empresas del sector privado que desempeña la función raíz. Esto significa que Red Hat goza de un merecido respeto, responsabilidad y confianza en toda la industria. A menudo somos los intermediarios que traducen una críptica entrega del kernel en algo práctico mientras el resto del mundo persigue los titulares.

Con el auge de la notificación de vulnerabilidades de seguridad basadas en la inteligencia artificial, el panorama de amenazas no solo evoluciona, sino que se acelera. Recientemente, Mozilla colaboró con Anthropic para descubrir 22 errores que afectan a la seguridad en su motor de JavaScript, seguidos de 271 vulnerabilidades adicionales en una revisión posterior que analizó todo el código base del navegador. En todo el ecosistema de software en general, a mediados de mayo de 2026, las herramientas de detección basadas en la inteligencia artificial, lideradas en gran parte por Mythos, marcaron más de 10000 problemas potenciales, lo que equivale a casi un año de detección tradicional en solo 2 semanas.

Red Hat se encuentra en medio de esta explosión. En 2025, Red Hat Product Security clasificó 7722 vulnerabilidades de seguridad. En los primeros 4 meses de 2026 (del 1 de enero al 30 de abril), la cifra fue de 2826; si ese ritmo continuara, el total anual ascendería a 8596. Del primero de mayo al 15 de mayo, el número de vulnerabilidades clasificadas aumentó a 712, lo que se dispara a más de 17000 para todo el año, es decir, más del doble que en 2025.

Copy Fail: El primero de muchos por venir

Cualquier día, CVE.org publica cientos de registros de vulnerabilidades. El 22 de abril, una CNA, kernel.org, publicó 100 vulnerabilidades, numeradas de la CVE-2026-31431 a la CVE-2026-31530. 

CVE-2026-31431 ofrece esta descripción.

“En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: algif_aead - Revert to operating out-of-place. Esto revierte principalmente el commit 72548b093ee3, excepto por la copia de los datos asociados. No existe ningún beneficio al operar in-place en algif_aead, ya que el origen y el destino provienen de asignaciones diferentes. Elimina toda la complejidad añadida para la operación in-place y simplemente copia los AD directamente”.

Esto no era nada emocionante hasta que, una semana después, el 29 de abril, un servicio llamado Xint.io de una empresa llamada Theori publicó un ataque de prueba de concepto y lo llamó Copy Fail. Detrás de esa descripción técnica se ocultaba un medio para que cualquier usuario local sin privilegios, ya sea en bare metal, en una máquina virtual (VM) o dentro de un contenedor, obtuviera acceso root a un sistema.

Afortunadamente, este ataque requiere acceso a la máquina. Un atacante debe iniciar sesión primero. Por desgracia, Red Hat y otras distribuciones de Linux se enteraron del ataque el mismo día que el público.

Los artículos de prensa y los hilos en línea estallaron. La carrera había comenzado.

Red Hat Product Security actualizó de inmediato su calificación de vulnerabilidad de este CVE a Importante y actualizó su boletín de seguridad con una estrategia de mitigación y un cronograma de corrección. Red Hat entregó el primero de muchos avisos de seguridad 5 días después, el 4 de mayo. Varios más le siguieron rápidamente.

Pero la historia no termina ahí.

Implementación para los clientes

Para el mediodía, hora de verano del centro de EE. UU. del 12 de mayo, Copy Fail generó 1132 casos de soporte de clientes que ejecutan Red Hat Enterprise Linux (RHEL), Red Hat OpenShift y Red Hat OpenStack. Más tarde, en mayo, esa cifra había aumentado a más de 1300 casos. Muchos de estos casos de soporte incluyeron preguntas detalladas o problemas complejos que no caben en un documento de preguntas frecuentes convencional. Por ejemplo:

• Algunas organizaciones dependen de aplicaciones con soporte limitado o nulo que suelen fallar con las actualizaciones y parches del sistema operativo. En esta nueva era de parches y actualizaciones constantes, estas aplicaciones presentan un riesgo aún mayor.
• Siempre surgen preguntas sobre cómo usar las puntuaciones del Common Vulnerability Scoring System (CVSS) para evaluar el riesgo. La mejor respuesta es: depende. Las puntuaciones CVSS asignan niveles de gravedad de forma aislada. La evaluación del riesgo depende de las características específicas del cliente y exige el juicio humano.
• ¿Cómo se puede hacer frente a una avalancha interminable de problemas marcados por la inteligencia artificial? La respuesta de "parchear todo" es un modelo fallido. En lugar de sufrir interrupciones constantes para aplicar parches, diseña tu entorno de TI para mitigar las vulnerabilidades con una defensa profunda, utiliza el juicio humano tradicional para evaluar qué vulnerabilidades representan realmente una amenaza para tu entorno específico y aplica los parches correspondientes.
• Al menos un cliente necesitaba saber cómo aplicar parches en OpenStack 17.1, que depende de RHEL 9.2. La respuesta fue utilizar el flujo de versiones de SAP de RHEL 9.2.
• Otro cliente necesitaba saber qué sucedería si utilizaba kernels más nuevos con parches en sistemas RHEL 8 más antiguos. 
• Algunas organizaciones ejecutaban versiones antiguas de OpenShift y necesitaban una estrategia de parches.
• Muchos necesitaban ayuda para coordinar la implementación de parches con los equipos de aplicaciones que buscan un tiempo de inactividad cero.
• A otras organizaciones les preocupaba el rendimiento.
• Varias necesitaban ayuda con los análisis de riesgos para diversas iniciativas de cumplimiento.
• Y en muchos casos, los clientes solicitaron declaraciones de garantía oficiales de Red Hat para los directivos.

Estos son solo algunos ejemplos. Las amenazas de seguridad siempre son estresantes, y consideramos valioso que alguien trabaje directamente con los clientes para ayudar a separar las especulaciones de la realidad, especialmente cuando surgen titulares sobre el error de Linux más alarmante en una década. 

La necesidad de contar con un partner comercial que ayude a cerrar la brecha entre la innovación upstream y las protecciones de seguridad de nivel empresarial nunca ha sido más evidente.

Red Hat Technical Account Management Service for Product Security

Para ayudar a gestionar situaciones de seguridad como esta, Red Hat ahora ofrece Red Hat Technical Account Management Service for Product SecurityPágina disponible en Inglés (Español no está disponible). Los Technical Account Managers (TAM) actúan como enlaces de comunicación entre los clientes y los grupos de productos e ingeniería de Red Hat y la comunidad open source. Mientras que la mayoría de los TAM se centran en un producto o una tecnología en particular, los TAM de seguridad de Red Hat se centran de manera integral en los entornos de seguridad de toda la cartera de productos de Red Hat. Estos TAM ayudan a:

• Compartir información ad hoc sobre diversas tácticas de ataque
• Ayudar a los clientes a utilizar las herramientas de seguridad y cumplimiento de Red Hat
• Sugerir configuraciones e implementaciones reforzadas según corresponda
• Explicar cómo Red Hat ayuda a reducir el riesgo y mitigar las vulnerabilidades
• Proporcionar análisis de vulnerabilidades más precisos para los productos de Red Hat
• Asistir en la clasificación de los informes de análisis de vulnerabilidades
• Facilitar la comunicación con los clientes, los equipos de Red Hat, los partners, otros proveedores y la comunidad open source cuando sea posible
• Influir en la gestión de productos de Red Hat, los equipos de seguridad de los productos, los partners, otros proveedores y la comunidad open source al representar los puntos de vista de los clientes
• Fomentar el conocimiento sobre la cadena de valor del software y los ataques a la cadena de suministro
• Asesoramiento sobre posibles mitigaciones ante incidentes de seguridad graves
• Ayuda en la elaboración de evaluaciones de incidentes de seguridad post mortem

La comunicación constante siempre es fundamental, especialmente durante una crisis, y más aún cuando la inteligencia artificial aumenta la velocidad y la gravedad de los informes de vulnerabilidades de seguridad. Los TAM de seguridad de Red Hat se encuentran en una posición privilegiada para ayudar a los clientes a distinguir el ruido de la realidad y abordar otras inquietudes. 

Tranquilidad

En esta nueva era de informes de vulnerabilidades impulsados por la inteligencia artificial, la mayor amenaza no es solo el volumen de errores, sino la dependencia excesiva de la automatización. La inteligencia artificial puede encontrar vulnerabilidades, pero no puede proporcionar una estrategia de seguridad basada en el riesgo ni ofrecer la integridad necesaria para respaldar a tu organización durante una crisis. El criterio humano sigue siendo lo único en lo que realmente puedes confiar. Las fallas en los procesos de divulgación responsable representan otra amenaza. Cada vez que alguien divulga una nueva vulnerabilidad antes de que los desarrolladores lancen una mitigación o un parche, permite que los atacantes tomen por sorpresa a los clientes.

Nadie puede prometer una inmunidad total contra los ataques, pero los TAM de seguridad de Red Hat pueden ayudar mediante la coordinación estrecha con Red Hat Product Security y la comunidad. Esto permite proporcionar la orientación estratégica y la defensa técnica que la inteligencia artificial no puede ofrecer. 

La capacidad de discernir la diferencia entre la exageración y la realidad, u obtener una alerta anticipada de un ataque inminente con unas pocas horas de antelación, puede marcar la diferencia entre aplicar una mitigación justo a tiempo y un desastre. No esperes a la próxima divulgación importante para proteger tu infraestructura. Obtén más información sobre la manera en la que un TAM de seguridad de Red Hat ofrece la planificación proactiva y la defensa técnica que tu organización necesitaPágina disponible en Inglés (Español no está disponible).

Comunícate con tu equipo de cuentas de Red Hat para obtener más información o ponte en contacto con Red Hat.
 

Para encontrar estas cifras, accede a la base de datos de CVE de Red Hat legible por humanos, selecciona un intervalo de fechas adecuado y observa el recuento que aparece en la parte inferior de la página.