El equipo de AlmaLinux ha publicado parches de emergencia para la vulnerabilidad crítica Copy Fail (CVE-2026-31431), dirigidos a todas las versiones activas de la distribución (8, 9 y 10, así como para Kitten 10), aunque con una particularidad esencial: estas correcciones residen en el repositorio de pruebas (testing), un destino que ninguna persona responsable recomendaría habilitar en equipos de producción.

⚠️ La vulnerabilidad que exige una respuesta extraordinaria

Copy Fail es un fallo de escalada de privilegios local descubierto por el equipo de Xint Code y divulgado públicamente el 29 de abril de 2026. Se trata de un error lógico en el subsistema criptográfico del núcleo de Linux, específicamente en la authencesn encadenada a través de AF_ALG y la llamada al sistema splice().

El código de explotación funcional ocupa solo 732 bytes y, según los propios investigadores, funciona sin modificación alguna en todas las distribuciones principales construidas desde 2017. El fallo permaneció latente durante casi una década, desde que se introdujo con la confirmación de cambios 72548b093ee3 en 2017 hasta que el parche upstream (confirmación a664bf3d603d) se confirmó en el núcleo principal el 1 de abril de 2026.

Para quienes administren sistemas en entornos compartidos, granjas de construcción de contenedores o ejecutores de integración continua donde usuarios sin nivel de confianza razonable puedan obtener un intérprete de mandatos, esta vulnerabilidad representa un nivel de riesgo inasumible.

📦 La iniciativa de AlmaLinux

Ante la ausencia de parches por parte de Red Hat, el comité directivo técnico ALESCo aprobó una decisión extraordinaria: construir y distribuir paquetes del núcleo con el parche upstream antes de que estén disponibles en CentOS Stream o RHEL.

Las versiones de los núcleos de Linux corregidos son:

Nota sobre Kitten 10: Al tratarse de una versión de desarrollo, Kitten 10 recibe el parche directamente en su repositorio principal, sin necesidad de habilitar el repositorio de pruebas.

🔧 Procedimiento de actualización (únicamente durante el periodo de pruebas)

Para quienes dispongan de entornos de prueba y deseen colaborar con la verificación de los paquetes, el procedimiento es el siguiente:

dnf install -y almalinux-release-testing
dnf update kernel* --enablerepo=almalinux-testing
reboot

Tras el reinicio, es posible verificar la versión del núcleo activo con:

uname -r

El equipo de AlmaLinux recomienda explícitamente evitar mantener habilitado el repositorio de pruebas después de actualizar, a menos que se haya hecho en un entorno genuinamente de pruebas.

🤔 El dilema de los repositorios de pruebas en producción

Aquí reside la cuestión principal. Los repositorios de pruebas están concebidos para detección temprana de errores, pero resultan inadecuados para la estabilidad de entornos productivos, a menos que se disfrute revirtiendo paquetes rotos a las tres de la madrugada, como bien se ha señalado en la comunidad.

La propia documentación de AlmaLinux advierte que el repositorio de pruebas se recomienda exclusivamente para equipos destinados a pruebas y jamás en producción. Instalar paquetes desde pruebas en servidores que alojan cargas de trabajo críticas implica:

• Riesgo de inestabilidad del núcleo sin detectar durante las pruebas automatizadas.
• Posibilidad de introducir nuevas vulnerabilidades en lugar de corregir la existente.
• Ausencia de la garantía de firmas GPG que respaldan los repositorios estables.
• Dificultades para recibir actualizaciones futuras si el repositorio permanece habilitado.

Dista de ser una cuestión de confianza en el equipo de AlmaLinux —su rápida reacción es ejemplar y merece todo el reconocimiento—, sino una cuestión de principios de administración de sistemas. Los repositorios de pruebas, por definición, carecen del nivel de validación y madurez que se exige a cualquier componente que se ejecute en producción.

🏢 La postura de Red Hat

Es importante contextualizar la decisión de AlmaLinux. A fecha de hoy, Red Hat se mantiene sin publicar actualizaciones oficiales del núcleo que corrijan CVE-2026-31431. La página oficial del CVE de Red Hat está operativa, pero carece de paquetes disponibles. Esta situación ha obligado a los derivados de RHEL a tomar decisiones difíciles: esperar a su fuente primaria o actuar de forma independiente.

La postura de AlmaLinux es comprensible: la gravedad del fallo, unida a la extrema sencillez de su explotación, hacía que esperar resultara inasumible para muchos casos de uso.

📌 Reflexión final

Los administradores se enfrentan ahora a un dilema de difícil resolución:

• Opción A: Aplicar el parche desde el repositorio de pruebas, asumiendo los riesgos asociados a la estabilidad, a cambio de cerrar una vulnerabilidad crítica documentada y con código de explotación público.
• Opción B: Mantener los sistemas sin aplicar paquetes con parches correctivos, expuestos a 'Copy Fail', a la espera de que los paquetes lleguen a los repositorios estables de AlmaLinux (algo que el equipo se ha comprometido a hacer en cuanto la comunidad valide los paquetes).

Dista de ser una respuesta única. Cada administración debe evaluar su propio contexto, el nivel de exposición a usuarios sin nivel de confianza razonable y su tolerancia al riesgo tanto de seguridad como de estabilidad operativa.

Lo que sí parece claro es que los equipos de seguridad y los administradores de sistemas merecían una ventana de tiempo más amplia entre la divulgación de la vulnerabilidad y la publicación del código de explotación. El anuncio público completo, con todos los detalles técnicos y el código funcional, antes de que las correcciones llegaran a las distribuciones, ha forzado a tomar decisiones apresuradas en condiciones subóptimas. La divulgación coordinada de vulnerabilidades existe precisamente para evitar estas situaciones.

Los paquetes de AlmaLinux son una solución técnica sólida; el problema radica en la vía de distribución elegida para una respuesta que debía ser urgente. Ojalá las circunstancias hubieran permitido un proceso más ordenado.

📚 Bibliografía

• Blog oficial de AlmaLinux: Copy Fail (CVE-2026-31431) Patches Released
• Foro de AlmaLinux: Llamado a pruebas para núcleos parcheados
• CVE-2026-31431 en NVD (Base de Datos Nacional de Vulnerabilidades)
• Sitio web oficial de Copy Fail
• Parche upstream en el núcleo de Linux (confirmación a664bf3d603d)
• Copy Fail en Access Red Hat (CVE-2026-31431)
• Linux Compatible: AlmaLinux Copy Fail Patch Released for Testing