«Copy Fail» es el tipo de vulnerabilidad de Linux que llama la atención por una buena razón: los informes públicos indican que puede proporcionar a un usuario local sin privilegios una vía práctica para obtener privilegios de root en varias distribuciones importantes, cuenta con una prueba de concepto pública y tiene implicaciones entre contenedores, ya que aprovecha indebidamente el comportamiento de la caché de páginas compartida.
Para los equipos de seguridad y operaciones, el problema no es únicamente el fallo del núcleo en sí mismo. Se trata de la rapidez con la que puede identificar los sistemas expuestos, priorizar aquellos que presentan un mayor riesgo, aplicarles los parches correspondientes y verificar que el cambio se haya aplicado efectivamente. Sin embargo, el 77 % de las organizaciones necesitan más de una semana para implementar parches en toda la empresa.
¿Qué es «Copy Fail»?
«Copy Fail» es una vulnerabilidad de Linux que permite la escalada de privilegios a nivel local en el subsistema de cifrado del núcleo. A grandes rasgos, esta vulnerabilidad permite a un usuario local sin privilegios realizar una escritura pequeña y controlada en los datos de un archivo respaldado por la caché de páginas. En las cadenas de explotación públicas, esa corrupción transitoria puede dirigirse al contenido almacenado en caché de un binario con permisos setuid, de modo que, en una ejecución posterior, se ejecute código controlado por el atacante con privilegios de root.
Hay varios factores que hacen que esta vulnerabilidad destaque:
- Se trata de un problema de escalada de privilegios a nivel local con una vía de explotación viable
- Se ha descrito como un sistema fiable y compatible con las principales distribuciones de Linux
- No se basa en una condición de carrera, como ocurría en muchos de los antiguos métodos de escalada de privilegios en Linux
- Esto tiene repercusiones entre contenedores, ya que la caché de páginas se comparte a nivel de host
El resultado es un riesgo evidente: si un atacante consigue ejecutar código como usuario con privilegios reducidos en un sistema Linux vulnerable, podría llegar a obtener acceso administrativo completo.
Comprender qué distingue a esta vulnerabilidad aporta un contexto útil, pero la pregunta más apremiante para la mayoría de los equipos es por qué está generando una urgencia operativa precisamente en este momento.
Por qué los equipos de seguridad se lo están tomando en serio
Aunque el número de CVE del núcleo de Linux aumentó considerablemente en 2024, gran parte de ese incremento se debió a los cambios en las prácticas de asignación de CVE tras convertirse el proyecto del núcleo en una autoridad de numeración CVE, y no a un aumento directamente comparable, de un año a otro, del riesgo empresarial.
No todas las vulnerabilidades CVE de Linux de alta gravedad generan el mismo nivel de urgencia operativa. «Copy Fail» lo hace, por varias razones.
Es fácil describirlo desde el punto de vista del atacante
Las informaciones publicadas se han centrado en una prueba de concepto compacta en Python capaz de atacar un binario con permiso setuid, como /usr/bin/su, y que, en sistemas vulnerables, podría permitir que un punto de acceso con privilegios reducidos se elevara a privilegios de root. Cuando una vulnerabilidad es a la vez comprensible y reproducible, los defensores deben dar por hecho que los atacantes del mundo real se interesarán por ella. Los operadores de ransomware utilizaron una LPE similar del núcleo en 2025.
Afecta a los entornos habituales de Linux empresarial
Se ha informado de que esta vulnerabilidad afecta a las distribuciones de Linux lanzadas a partir de la versión 2017, incluidas plataformas empresariales ampliamente implantadas, tales como:
- Amazon Linux
- Red Hat Enterprise Linux
- SUSE
- Ubuntu
- Debian y otros núcleos de fabricantes cuyas versiones de los paquetes distribuidos incluyen la ruta de código vulnerable y aún no incorporan la corrección del fabricante
La amplitud de las distribuciones afectadas es uno de los motivos por los que se trata de un problema que afecta a toda la flota, y no de un problema aislado de una plataforma concreta.
Los contenedores no eliminan el riesgo
Este es uno de los aspectos más importantes para los equipos de la plataforma, y no solo por las suposiciones de aislamiento. El error de copia no es «solo» un problema del servidor. Dado que la caché de páginas se comparte entre los distintos procesos de un sistema, una vulnerabilidad como esta puede poner en entredicho las suposiciones sobre el aislamiento en entornos con núcleo compartido.
Sin embargo, la realidad operativa más inmediata es que la aplicación de parches requiere un reinicio, y ese requisito de reinicio se aplica a todo el entorno Linux. Para la mayoría de las organizaciones, esto supone interrupciones planificadas a gran escala, y no una actualización silenciosa en segundo plano.
Dicho requisito de reinicio se aplica a:
- Nodos de trabajo de Kubernetes
- Ejecutores de CI/CD compartidos
- Servidores de contenedores multitenant
- Entornos aislados para la ejecución de código
- Otros entornos informáticos compartidos basados en Linux
En resumen, cualquier entorno en el que se ejecuten múltiples cargas de trabajo en un servidor compartido debe considerarse potencialmente vulnerable si los usuarios sin privilegios pueden ejecutar código arbitrario.
RHEL y las distribuciones compatibles disponen de una medida de mitigación que permite reducir la vulnerabilidad sin necesidad de reiniciar el sistema de forma inmediata; sin embargo, en la mayoría de los entornos, es inevitable establecer un plazo para la aplicación de parches.
Una vez definido el perfil de amenaza, resulta útil comprender los mecanismos que subyacen a la vulnerabilidad antes de pasar a su corrección.
Cómo funciona «Copy Fail» a grandes rasgos
Sin entrar en detalles sobre el código de explotación, el problema señalado se debe a una vulnerabilidad en la gestión de algif_aead del núcleo de Linux, dentro del subsistema de cifrado. En una investigación pública se ha descrito una ruta que implica a AF_ALG, operaciones AEAD y la función splice(), y que da lugar a que los datos respaldados por la caché de páginas acaben en un lugar en el que el núcleo puede realizar una escritura que no debería.
En la práctica, el proceso del ataque descrito públicamente es el siguiente:
- Abrir un socket: Abrir un socket AF_ALG y vincularlo a la transformación AEAD o de cifrado autenticado afectada que requiere el exploit
- Cree la carga útil: Cree la entrada necesaria para activar la ruta de código vulnerable
- Alterar el objetivo: Provocar una escritura en la copia almacenada en caché de un binario de destino, como /usr/bin/su
- Ejecute el archivo binario: . Ejecute el archivo binario mientras su contenido almacenado en caché está dañado, de modo que el código controlado por el atacante se ejecute con los privilegios elevados del archivo binario.
Los detalles técnicos aportan un contexto útil, pero la conclusión operativa tiene mayor relevancia: se trata de una vulnerabilidad a nivel del núcleo con una vía clara de escalada de privilegios a nivel local.
Conocer el funcionamiento de esta vulnerabilidad ayuda a comprender por qué «Copy Fail» se clasifica en una categoría de riesgo distinta a la de muchos fallos más antiguos de Linux relacionados con la escalada de privilegios.
¿En qué se diferencia «Copy Fail» de los antiguos fallos de seguridad de Linux relacionados con la escalada de privilegios?
Los equipos de seguridad comparan, como es lógico, los nuevos problemas de escalada de privilegios en Linux con fallos anteriores que han tenido gran repercusión. «Copy Fail» forma parte de ese debate, pero presenta su propio perfil de riesgo.
| Factor | Error al copiar | LPEs de Linux más antiguas con un alto nivel de competencia |
|---|---|---|
| Fiabilidad de los exploits | Se considera de gran fiabilidad | A menudo depende del momento |
| Necesidad de desplazamientos del núcleo | No es un elemento fundamental de la vía de explotación descrita | A menudo es necesario en algunas cadenas de explotación |
| Portabilidad entre distribuciones | Se ha informado de ello en las principales distribuciones | A menudo, más específico de cada versión |
| Impacto de los contenedores | Es importante en entornos con núcleo compartido | Varía |
| Dificultad de detección | Difícil | A menudo resultan difíciles, pero hay algunos caminos que son más ruidosos |
Esa combinación es la razón por la que los responsables de la seguridad deben resistirse a la tentación de considerar esto como «un simple fallo local más».
La escalada de privilegios locales sigue siendo una de las etapas más importantes en las cadenas de ataque modernas, especialmente tras el robo de credenciales, el phishing, unos controles de acceso iniciales deficientes o el compromiso de una aplicación.
El perfil de riesgo determina el orden de prioridades. La siguiente pregunta es qué sistemas deberían pasar a ocupar los primeros puestos de la lista de correcciones.
¿Quiénes son los más vulnerables?
Cada terminal Linux vulnerable requiere una respuesta, pero algunos entornos deberían tener prioridad.
Sistemas de máxima prioridad
- Sistemas Linux conectados a Internet en los que los atacantes podrían haber conseguido ya un punto de acceso a nivel de usuario
- Nodos de Kubernetes compartidos y hosts de contenedores
- CI/CD e infraestructura de compilación en la que se ejecutan dependencias de terceros o código aportado por la comunidad durante la compilación
- Servidores de Bastion y servidores de salto
- Estaciones de trabajo para desarrolladores con acceso privilegiado a entornos de producción
- Servidores Linux multiusuario en entornos empresariales
Por qué los entornos con núcleo compartido merecen un análisis más minucioso
El aspecto que trasciende los límites de los contenedores es lo que eleva esta cuestión de una simple tarea de aplicación de parches a un debate sobre los riesgos de la plataforma.
Si su límite de confianza se centra principalmente en «el contenedor», Copy Fail le recuerda que los supuestos sobre el núcleo compartido siguen siendo frágiles, especialmente en entornos en los que se ejecuta código generado por IA o no fiable dentro de contenedores, o en los que los sistemas conectados a Internet aceptan y procesan entradas de usuarios externos procedentes de fuentes desconocidas.
Para muchas organizaciones, la verdadera cuestión no es si la vulnerabilidad es grave. La cuestión es si saben exactamente qué cargas de trabajo se ejecutan actualmente en núcleos vulnerables.
Versiones afectadas y estado de la corrección
Los avisos disponibles públicamente indican que el problema se remonta a un cambio en el núcleo introducido en la versión 2017. Se han publicado correcciones estables para el núcleo, y las distribuciones las están incorporando a sus propios canales de actualización.
Una forma concisa de determinar si sus sistemas se ven afectados es la siguiente:
| Categoría | Estado |
|---|---|
| Sistemas que ejecutan núcleos en los que está presente la lógica vulnerable | Posiblemente expuestos |
| Sistemas actualizados con paquetes del núcleo corregidos por el proveedor | Solucionado (reinicio confirmado) |
| Sistemas que se basan únicamente en la supervisión, sin la aplicación de parches | Sigue existiendo el riesgo (la supervisión no soluciona la vulnerabilidad subyacente) |
| Servidores de contenedores con núcleo compartido sin correcciones del núcleo | Gran preocupación |
Dado que los proveedores de Linux para empresas incorporan correcciones retroactivamente, la única forma justificada de validar la vulnerabilidad consiste en seguir las recomendaciones de su distribución, además de disponer de una visibilidad directa de los paquetes del núcleo implementados y del estado de reinicio.
Una vez identificada la exposición, el siguiente paso consiste en elaborar un plan de respuesta claro y estructurado.
Qué hacer ahora mismo
Para la mayoría de los equipos, el plan de respuesta debe ser sencillo y rápido.
1. Identificar los sistemas Linux vulnerables
Comience por realizar un inventario detallado de:
- Distribución y versión
- Versión del núcleo actualmente en ejecución
- Paquetes del núcleo instalados
- Estado del reinicio tras la actualización del núcleo
- Función del sistema, especialmente como host de contenedores o ejecutor de CI/CD
2. Priorice en función del riesgo, no solo por el número
Aplique parches a todos los elementos vulnerables, pero comience por estos:
- Infraestructura compartida
- Servidores de alto valor
- Sistemas con numerosos usuarios interactivos
- Sistemas que ejecutan habitualmente código no fiable o semiconfiable
En este contexto, resulta especialmente útil un enfoque de gestión de vulnerabilidades basado en el riesgo, tal y como se describe en , ya que el mero número de activos es menos importante que saber qué sistemas Linux suponen un mayor riesgo operativo y de seguridad.
3. Aplique el parche del proveedor
Esta es la acción clave. Las actualizaciones del núcleo son la verdadera solución en este caso. Los equipos que necesitan actuar con rapidez y a gran escala suelen recurrir a flujos de trabajo de gestión de puntos finales de para la implementación de parches , en lugar de abordar la corrección del núcleo como una tarea manual puntual.
4. Reinicie el sistema cuando sea necesario
En el caso de las actualizaciones convencionales de paquetes del núcleo, un paquete preparado por fases que no se haya activado mediante un reinicio con el nuevo núcleo no se considera una corrección completa. Si en su entorno se utiliza la aplicación de parches en tiempo real al núcleo, compruebe, en su lugar, el estado de «livepatch».
5. Compruebe que la corrección ya está activa
No se limite a decir «se ha implementado el parche». Compruebe que:
- El paquete actualizado ya está instalado
- El servidor se reiniciaba cuando era necesario
- El núcleo que se está ejecutando es el que ha sido corregido
Es aquí donde el estado actual del terminal cobra especial importancia, ya que el inventario de paquetes por sí solo no demuestra que el núcleo en ejecución haya cambiado.
6. Considere la posibilidad de aplicar medidas de mitigación temporales únicamente si se retrasa la aplicación del parche
En caso de que la aplicación del parche deba posponerse, algunas directrices públicas han recomendado desactivar la ruta del módulo afectado como medida temporal. En RHEL y en las distribuciones compatibles, la aplicación de esta medida correctiva requiere un reinicio, al igual que su eliminación para restablecer las funciones criptográficas afectadas.
Esa realidad operativa debe tenerse en cuenta a la hora de tomar decisiones sobre el riesgo, sobre todo cuando las interrupciones imprevistas del servicio acarrean sus propias consecuencias. Esto no sustituye a la aplicación de parches.
Comprobar que se han aplicado los parches y que los sistemas se han reiniciado es tan importante como la propia aplicación de los parches. Esto nos lleva directamente a las realidades en materia de detección y supervisión que los equipos deben comprender.
Realidades en materia de detección y seguimiento
Es en este punto donde los defensores deben ser sinceros. Si un atacante es capaz de aprovechar esta vulnerabilidad, significa que sus controles de detección y prevención ya han fallado en alguna fase anterior.
La detección previa a la explotación es limitada, ya que el comportamiento vulnerable se produce dentro de los mecanismos legítimos del núcleo. Lo que la detección puede ofrecer de forma realista en este caso es:
- Búsqueda de comportamientos posteriores a la explotación
- Vigilar los patrones sospechosos de ejecución de setuid
- Investigación de cambios inesperados en los privilegios
- Supervisión de la actividad posterior del atacante tras obtener acceso de root
Eso es útil, pero no equivale a la prevención. Las vulnerabilidades como «Copy Fail» nos recuerdan que el volumen y el ritmo de las CVE del núcleo no están disminuyendo, y que un modelo de aplicación de parches reactivo tendrá cada vez más dificultades para mantenerse al día.
La estrategia más sostenible consiste en aplicar parches de forma continua, de modo que la reducción del tiempo necesario para aplicar los parches se considere una prioridad operativa permanente, en lugar de una respuesta a vulnerabilidades de seguridad (CVE) concretas.
La visión de Tanium sobre el riesgo de «Copy Fail»
No es una respuesta muy alentadora, pero sí es la más realista: detectar la vulnerabilidad en el momento en que se activa a nivel del núcleo no es factible, pero detectar los indicios de un ataque en curso —scripts o archivos binarios desconocidos que llegan al sistema— sí es posible con herramientas como Tanium y soluciones EDR especializadas. La aplicación de parches sigue siendo la respuesta principal, pero no es la única medida disponible. Siempre que sea viable desde el punto de vista operativo, los equipos pueden seguir supervisando o restringiendo la interfaz del núcleo afectada y estar atentos a cualquier comportamiento sospechoso posterior.
Esa forma de plantear las cosas es importante. «Copy Fail» resulta preocupante por su sencillez y por sus características de escalada de privilegios locales, pero los responsables de la seguridad deben distinguir la realidad operativa del ruido.
La filosofía de actuación en este caso es sencilla y se desarrolla por etapas:
- Identificar los sistemas Linux vulnerables
- Priorice aquellos sistemas en los que la escalada de privilegios de usuario local a root tenga mayores consecuencias
- Aplique los parches al núcleo
- Compruebe que el parche esté activo
- Utilice la detección posterior al ataque únicamente como medida de control complementaria, no como plan principal
Para los clientes de Tanium, esto suele corresponder a lo que la plataforma de Tanium ya ayuda a los equipos a hacer en su gestión diaria de las vulnerabilidades: obtener una visión actualizada de los terminales Linux, identificar qué sistemas están expuestos y realizar un seguimiento del progreso de las medidas correctivas.
Lo fundamental no es que «Copy Fail» introduzca un flujo de trabajo totalmente nuevo. Esto refuerza la idea de que la gestión continua de la exposición y una validación rigurosa de los parches son esenciales.
En resumen
El CVE-2026-31431 es un grave problema de escalada de privilegios en el núcleo de Linux, pero la respuesta adecuada no es complicada. No se trata de un tema en el que tenga sentido prometer más de lo que se puede cumplir en materia de prevención basándose únicamente en el análisis de datos. La postura más acertada es aplicar el parche lo antes posible. No necesita un marco de trabajo novedoso. Necesita visibilidad, establecimiento de prioridades, aplicación de parches y validación.
Para los equipos de seguridad y operaciones, esto supone un buen recordatorio de que la gestión de vulnerabilidades rara vez es solo una cuestión técnica.
Lo más complicado es mantener el equilibrio adecuado entre confidencialidad, integridad y disponibilidad, al tiempo que se aplican las correcciones con la rapidez suficiente para reducir el riesgo sin interrumpir las operaciones empresariales ni las funciones críticas que dependen de dichos sistemas.
En las organizaciones de mayor tamaño, la corrección de incidencias y la búsqueda de amenazas suelen estar a cargo de equipos distintos y pueden llevarse a cabo simultáneamente. Ambas vías pueden y deben avanzar en paralelo, sin esperar a la otra.
Cómo es una respuesta empresarial sólida
Los equipos que gestionan eficazmente los errores de copia suelen llevar a cabo cuatro acciones con rapidez:
| Etapa de respuesta | Cómo se reconoce lo que es bueno |
|---|---|
| Evaluación de la exposición | Obtenga una lista clara de los sistemas Linux vulnerables en cuestión de horas, no de días |
| Establecimiento de prioridades | En función de la exposición, la tolerancia al riesgo y las limitaciones operativas de su organización |
| Remediación | Los parches del núcleo se implementan rápidamente con supervisión operativa |
| Validación | Se ha confirmado el estado del núcleo en ejecución; no se ha dado por supuesto |
Es en este punto donde muchas organizaciones encuentran dificultades. Es posible que sepan que existe un CVE, pero no pueden responder de inmediato:
- ¿Qué sistemas están expuestos?
- ¿Qué servicios empresariales se ejecutan en dichos sistemas?
- ¿Qué servidores se han actualizado pero no se han reiniciado?
- ¿Qué servidores de contenedores no tienen instalados los parches y siguen suponiendo un riesgo para las cargas de trabajo en ejecución?
Se trata de cuestiones operativas, no de cuestiones de investigación. Y son ellos quienes determinan si una vulnerabilidad CVE se convierte en un incidente.
Errores habituales que debe evitar
Considerar la escalada de privilegios local como una prioridad menor
Dado que para aprovechar esta vulnerabilidad es necesario disponer ya de acceso local, es posible que se le asigne una prioridad menor frente a otras necesidades inmediatas de aplicación de parches. Se trata de una decisión legítima en materia de riesgos, pero el impacto en el negocio de contar con una vía fiable para acceder a los privilegios de root sigue exigiendo un calendario definido para la corrección de la situación.
Suponiendo que los contenedores proporcionen suficiente separación
En entornos con núcleo compartido, esa suposición puede resultar errónea rápidamente. Las organizaciones que hacen un uso significativo de contenedores deberían plantearse la visibilidad y la protección de los entornos contenedorizados , en lugar de dar por sentado que la capa de orquestación por sí sola reduce el riesgo a nivel del núcleo.
Considerar la implementación del paquete como finalización de la corrección
Los parches del núcleo suelen requerir una comprobación tras el reinicio. Sin ello, es posible que solo consiga un progreso parcial.
A la espera de una lógica de detección perfecta
En el caso de «Copy Fail», esperar a que se active la lógica de detección previa a la explotación antes de actuar es una estrategia fallida. Aplique primero el parche. Si se sospecha que se está produciendo una explotación, dé prioridad a los flujos de trabajo de respuesta tras la violación de seguridad una vez que las medidas de contención y corrección ya se hayan puesto en marcha.
Preguntas frecuentes sobre errores de copia
«Copy Fail» plantea cuestiones prácticas que van más allá del aviso de la CVE. A continuación se recogen las preguntas más habituales que se plantean los equipos de seguridad y operaciones de las empresas mientras llevan a cabo la evaluación de vulnerabilidades y la planificación de las medidas correctoras.
¿Se puede explotar de forma remota la vulnerabilidad «Copy Fail»?
No. Se trata de una vulnerabilidad de escalada de privilegios local, lo que significa que un atacante debe disponer ya de acceso al sistema. Ese requisito de acceso es la razón por la que algunas organizaciones pueden restarle prioridad; sin embargo, una vía fiable para obtener privilegios de root en un sistema al que ya se ha accedido sigue teniendo consecuencias reales para la empresa y debe incluirse en su plan de corrección.
¿Afecta el error «Copy Fail» a los contenedores y a Kubernetes?
Es posible. Dado que los contenedores comparten el núcleo del host, un host vulnerable puede exponer las cargas de trabajo en contenedores al riesgo de ejecución privilegiada (LPE) en el núcleo local. La viabilidad práctica de la explotación depende del acceso del contenedor a la interfaz del núcleo afectada, de la política de seguridad en tiempo de ejecución y de si las páginas del archivo de destino están compartidas y son accesibles desde esa carga de trabajo.
¿Cuál es la mejor medida de mitigación si no puedo aplicar el parche de inmediato?
Existen medidas de mitigación provisionales, que han sido documentadas tanto por los proveedores afectados como por el equipo de investigación que descubrió la vulnerabilidad. Sin embargo, la solución definitiva consiste en aplicar un parche al núcleo. Las medidas provisionales deben considerarse una reducción del riesgo a corto plazo, no una solución definitiva.
¿Cómo puedo comprobar que la corrección ha funcionado?
Confirme que el paquete del núcleo corregido por el proveedor esté instalado, compruebe si ha sido necesario reiniciar el sistema y verifique que el núcleo en ejecución sea la versión corregida. La validación debe centrarse en el estado real del núcleo, y no solo en el estado de la implementación.
¿Por qué está recibiendo tanta atención esta vulnerabilidad?
Porque reúne una serie de características que no gustan a los defensores de la seguridad: una escalada de privilegios fiable de usuario local a root, una amplia relevancia en el entorno Linux, un debate público sobre la prueba de concepto y repercusiones entre contenedores. El enfoque de detección potenciado por la inteligencia artificial también ha aumentado la visibilidad, aunque la respuesta operativa sigue siendo, afortunadamente, muy sencilla: aplicar parches.
La solución para el error «Copy Fail» es sencilla: aplique un parche al núcleo. Si su equipo sigue trabajando en la gestión de vulnerabilidades, Tanium puede ayudarle a identificar qué sistemas Linux lo necesitan, priorizarlos según el riesgo y confirmar que el parche se ha aplicado en todo su entorno.
Concierte hoy mismo una demostración gratuita en.
