Durante la madrugada del 29 de abril de 2026, mientras los administradores de sistemas y los equipos de seguridad dormían, los investigadores de Theori/Xint decidieron encender una cerilla en un depósito de gasolina digital. Publicaron la existencia de CVE-2026-31431 (Copy Fail), pero además el código de explotación funcional completo, de tan solo 732 bytes, un guion de instrucciones que permite a cualquier usuario local sin privilegios convertirse en root en prácticamente cualquier distribución Linux lanzada desde 2017.

Nueve años. El fallo se introdujo en 2017 (confirmación de cambios 72548b093ee3) y permaneció oculto durante casi una década. El parche se comprometió en el núcleo principal el 1 de abril de 2026. A partir de ahí, la cronología se vuelve turbia. El CVE se asignó el 22 de abril. Poco después, alguien tomó una decisión que carece por completo de ética profesional en el ámbito de la seguridad informática.

⏰ El cronómetro juega en contra de los administradores

El 29 de abril todo estalló con la divulgación pública. El más mínimo sentido común dicta la concesión de un plazo de embargo prudencial –90 días es lo habitual, a veces más– para que todas las partes implicadas preparen y publiquen actualizaciones reales para sus usuarios. Pero los investigadores de Theori seguramente priorizaron consideraciones comerciales (a fin de cuentas deseaban promocionar su escáner «Xint Code») o la inmediatez de la notoriedad, y emprendieron la divulgación sin dar tregua a nadie.

¿El resultado? Una ventana de vulnerabilidad innecesaria para millones de sistemas en todo el mundo. Como ha señalado Will Dormann (@wdormann), miembro de renombre en la comunidad de seguridad: «No puedo entender cómo ocurre ésto. En todos mis años en seguridad o estás a bordo de la divulgación coordinada de vulnerabilidades o lanzas un 0-day. Esto encaja de manera extraña en medio. O bien estos chicos de Xint Code tienen una agenda oculta o son realmente malos en la divulgación coordinada».

Pocas objeciones caben a ese análisis.

🌍 El mapa mundial de los parches: un desierto

Mientras usted lee esto, la situación resulta desoladora. Carece de correcciones oficiales para la gran mayoría de las distribuciones principales. El CERT de la Unión Europea (CERT‑EU) lo confirma sin ambages: «A fecha de hoy (30 de abril de 2026), ninguna distribución ha enviado un paquete de núcleo corregido. El parche principal se confirmó el 1 de abril de 2026, pero las actualizaciones de los proveedores siguen pendientes en todas las grandes distribuciones».

Ubuntu, Amazon Linux 2023, SUSE Linux Enterprise: ninguno dispone de una solución oficial. Y lo que resulta más preocupante, Red Hat Enterprise Linux (y por tanto AlmaLinux, Rocky Linux y otros derivados) se encuentran en un estado incierto. La página oficial del CVE de Red Hat está operativa, pero carece de rastro de actualizaciones disponibles. La última actualización del núcleo de AlmaLinux data del 21 de abril de 2026… y corregía otros CVEs (CVE‑2025‑68741 y CVE‑2026‑23191), pero aún sin incluir corrección para Copy Fail. Los servidores de AlmaLinux de esta organización –y de la suya propia, si gestiona alguno– siguen tan expuestos hoy como lo estaban hace una semana.

Dicho de otra manera: existe una vulnerabilidad que permite la escalada de privilegios locales completa con un código de explotación ya disponible y ninguna defensa real para la mayoría de los sistemas que ejecutan cargas de trabajo en producción. La recomendación oficial de CERT‑EU: inhabilitar el módulo algif_aead como medida temporal. Una medida que, por cierto, resulta inútil en las distribuciones RHEL (y por tanto AlmaLinux, Rocky…), porque el código vulnerable está integrado directamente en el núcleo y carece de la posibilidad de desactivarse (vmlinux). Para estos casos, la única mitigación posible consiste en filtrar AF_ALG mediante seccomp y systemd (con RestrictAddressFamilies=~AF_ALG, por ejemplo). O sea, una auténtica y compleja solución emergente, lejos de una solución elegante.

🤔 ¿Qué tipo de divulgación es ésta?

Lo que más indigna dista de ser el descubrimiento de una vulnerabilidad –porque esa labor se agradece–. Lo que resulta intolerable es publicar el código de explotación y una página web reluciente (copy.fail) antes de que las distribuciones tengan tiempo siquiera de preparar una actualización.

Los investigadores podrían haber optado por:

1. Registrar el fallo ante el equipo de seguridad del núcleo de Linux, lo que ya han hecho –y bien–.
2. Conceder un plazo de al menos 30, 60 o 90 días para que todas las distribuciones empaqueten y prueben sus parches.
3. Publicar de forma progresiva la información: primero el aviso, más tarde el código (o mejor aún, evitar publicar el código y limitarse a la descripción técnica).
4. Establecer una fecha de divulgación consensuada que diera tiempo a los administradores del mundo real para implementar las mitigaciones.

En lugar de esto, Theori optó por la vía rápida. Tal vez para promocionar su escáner Xint, tal vez por pura desconfianza en que el equipo de seguridad del núcleo reaccionara a tiempo. Sea como fuere, han puesto en riesgo real a miles de organizaciones que ahora se debaten entre mantener expuestos sus servidores o aplicar remedios de emergencia que ni siquiera son efectivos en todos los entornos. @pbeyssac expresaba hace escasas fechas una opinión similar en redes sociales: «Muchos han criticado la falta de coordinación y el riesgo innecesario para los usuarios finales».

🔮 Reflexión final: ¿quién es el responsable?

En la cadena de la seguridad, existen muchos eslabones: el descubridor, los mantenedores del núcleo, los equipos de las distribuciones, los administradores de sistemas y, finalmente, los usuarios.

Aquellos investigadores que, como Theori, tienen la oportunidad de hacerlo bien y eligen el camino del espectáculo y la notoriedad, cargan con una buena parte de la responsabilidad cuando las explotaciones comienzan a circular en la naturaleza y los sistemas caen.

La divulgación coordinada de vulnerabilidades carece de ser un estorbo burocrático: es un mecanismo de protección. Quienes lo obvian demuestran, cuando menos, una alarmante falta de ética profesional o una peligrosa desconexión con la realidad de los sistemas que dicen ayudar a proteger.

📌 En resumen:

• La vulnerabilidad es extremadamente grave: permite a cualquier usuario local convertirse en root con un guion de instrucciones de 732 bytes.
• El código de explotación ya está disponible.
• La mayoría de las distribuciones aún carecen de parche oficial.
• AlmaLinux (y por tanto RHEL y derivados) carecen de solución disponible y la mitigación por módulo resulta inútil.
• Los investigadores han priorizado el lucimiento personal sobre la seguridad de los usuarios.
• Le corresponde a usted, administrador, revisar sus sistemas, aplicar la limitación de acceso a AF_ALG y preparar copias de seguridad… hasta que llegue la actualización que nunca debió demorarse.

📚 Bibliografía y referencias

• Copy Fail (CVE-2026-31431): sitio web oficial con detalles públicos
• Artículo técnico de Theori/Xint en Xint.io
• Security Advisory CERT‑EU 2026‑005
• Will Dormann (@wdormann) en infosec.exchange
• Mend.io: análisis técnico de la vulnerabilidad
• Estado de actualizaciones de AlmaLinux (21 de abril de 2026)
• Opinión de @pbeyssac en X (antes Twitter)