La infraestructura de Canonical —la empresa que desarrolla Ubuntu— lleva más de 24 horas fuera de servicio tras un ataque de denegación de servicio distribuido (DDoS) reclamado por el grupo hacktivista «The Islamic Cyber Resistance in Iraq – 313 Team». El momento no podría ser peor: el ataque comenzó horas después de que se publicara el exploit de Copy Fail (CVE-2026-31431), una vulnerabilidad crítica del kernel de Linux que permite a cualquier usuario local escalar privilegios hasta root en prácticamente todas las distribuciones lanzadas desde 2017.
Lo informa Ars Technica en detalle, y la historia tiene una dimensión que va más allá del DDoS en sí: la coincidencia —deliberada o no— entre el ataque y la divulgación pública de una vulnerabilidad grave ha dejado a millones de administradores de sistemas sin acceso a los avisos de seguridad oficiales en el peor momento posible.
¿Qué servicios de Ubuntu están caídos?
Según la página de estado de Canonical —que ella misma está afectada y apenas carga— más de una docena de dominios y servicios están caídos o degradados desde el jueves 30 de abril. La lista incluye los más críticos para el ecosistema Ubuntu:
- ubuntu.com y canonical.com (errores 503 persistentes)
- security.ubuntu.com — el repositorio de actualizaciones de seguridad
- archive.ubuntu.com — el repositorio principal de paquetes
- Ubuntu Security API para CVEs y avisos de seguridad
- Snapcraft, portal.canonical.com, developer.ubuntu.com, blog.ubuntu.com
- Plataformas cloud cómo jaas.ai y maas.io
El impacto directo es claro: no se pueden instalar actualizaciones desde los servidores oficiales, no se puede descargar Ubuntu, y las herramientas de gestión automática de parches que dependen de la Security API de Canonical tampoco pueden obtener datos de vulnerabilidades en tiempo real. TechCrunch verificó que los intentos de actualización en un dispositivo con Ubuntu fallaban sistemáticamente mientras el ataque estaba en curso.
La buena noticia parcial es que los espejos (mirrors) de los repositorios de Ubuntu siguen funcionando con normalidad, por lo que actualizar desde un mirror alternativo sí es posible. En Software y Actualizaciones se puede seleccionar el mirror en el desplegable «Descargar desde».
El grupo que lo reivindica y cómo funciona el ataque
El grupo 313 Team anunció el ataque a través de su canal de Telegram el jueves por la tarde, indicando inicialmente que duraría cuatro horas. Más de 24 horas después, la infraestructura de Canonical seguía sin funcionar con normalidad, algo que The Register calificó cómo llamativo dado que existen servicios de protección DDoS bien consolidados —algunos gratuitos— que deberían poder mitigar este tipo de ataques.
El método utilizado es un servicio DDoS de pago conocido cómo Beam, un «stresser» o «booter»: plataformas que venden capacidad de ataque a cualquiera que pague, sin necesidad de infraestructura propia ni conocimientos técnicos avanzados. Según TechCrunch, el servicio en cuestión afirma poder generar ataques de más de 3,5 Tbps —aproximadamente la mitad del ataque DDoS que Cloudflare denominó «el mayor jamás registrado» el año pasado.
El 313 Team no es nuevo en este tipo de operaciones. En las semanas previas ya había reclamado ataques DDoS contra eBay Japón, eBay Estados Unidos y BlueSky. No hay una razón declarada para atacar a Canonical específicamente; la hipótesis más plausible es la visibilidad de Ubuntu cómo la distribución Linux más popular del mundo.
Sobre los ataques dirigidos contra infraestructura Linux este tipo de ofensivas no son nuevas, aunque sí es inusual que afecten a la infraestructura del fabricante directamente durante tantas horas.
Copy Fail: la vulnerabilidad que nadie puede parchear mientras Ubuntu está caído
Aquí está el nudo real de la historia. El 29 de abril de 2026, los investigadores de Theori y Xint.io publicaron los detalles completos de CVE-2026-31431, apodado «Copy Fail». La descripción es alarmante: un script Python de 732 bytes puede modificar un binario setuid en la caché de página del kernel y obtener acceso root sin necesidad de permisos especiales. El CVSS asignado es 7,8 sobre 10 (severidad ALTA).
La vulnerabilidad reside en el módulo criptográfico algif_aead del kernel de Linux, concretamente en una optimización introducida en agosto de 2017 mediante el commit 72548b093ee3. Ese cambio reorientó las operaciones AEAD para trabajar «in-place», lo que abrió la posibilidad de escribir datos controlados en la caché de memoria que respalda los binarios del sistema. El resultado práctico: un atacante con una cuenta local —no necesariamente acceso físico al servidor, basta con SSH o un job de CI— puede escalar a root en segundos.
Afecta a todas las distribuciones Linux con kernel entre 2017 y principios de 2026: Ubuntu (hasta 25.10), Debian, RHEL, SUSE, Amazon Linux, Fedora, Arch y muchas más. La única versión de Ubuntu no afectada es Ubuntu 26.04 Resolute, que ya incorpora el kernel corregido. CERT-EU ha publicado una alerta urgente recomendando aplicar la mitigación provisional de inmediato, especialmente en nodos Kubernetes y runners de CI/CD.
Esta vulnerabilidad en el kernel de Linux recuerda en su patrón a PwnKit (CVE-2021-4034), que también permaneció oculta durante años antes de que apareciera un exploit público horas después de su divulgación.
La mitigación temporal publicada por Canonical pasa por desactivar el módulo afectado (algif_aead) a través del paquete kmod. No es una solución definitiva —el parche del kernel está en desarrollo—, pero sí bloquea el vector de ataque inmediato. El problema: la página oficial donde Canonical publicó esa guía de mitigación lleva más de un día sin cargar.
El problema de comunicación que nadie está abordando
Hay algo que llama especialmente la atención en esta historia: Canonical ha guardado prácticamente silencio desde que empezó el ataque. La única comunicación oficial ha sido un mensaje en X que repite la misma frase: «La infraestructura web de Canonical está bajo un ataque sostenido y transfronterizo y estamos trabajando para resolverlo.»
Sin actualizaciones de estado, sin ETAs, sin detalles técnicos. Más de 24 horas después del inicio del incidente, la página de status.canonical.com seguía inaccesible o mostrando el mismo mensaje genérico.
Eso plantea una pregunta legítima que The Register también formuló: ¿por qué una empresa de este tamaño no tiene protección DDoS activa? Cloudflare, Akamai, Fastly o incluso la opción gratuita de Cloudflare para proyectos open source habrían podido mitigar un ataque de estas características en minutos. La ausencia de esa capa de protección resulta difícil de justificar, especialmente cuando Canonical gestiona el soporte de seguridad a largo plazo de Canonical para millones de servidores en producción.
Mi valoración
Tras seguir este incidente de cerca durante las últimas horas, lo que más me preocupa no es el DDoS en sí —que es un ataque técnicamente burdo, aunque eficaz— sino la combinación de factores que lo convierte en algo más serio de lo que parece.
La coincidencia temporal con Copy Fail puede ser pura mala suerte. Pero el efecto práctico es el mismo que si hubiera sido deliberado: administradores de sistemas con una vulnerabilidad activa de escalada a root sin acceso a las instrucciones oficiales de mitigación, sin poder instalar parches desde los servidores de Canonical, y sin comunicación clara de la empresa sobre cuándo se normaliza la situación.
Lo que más me convence del análisis técnico de Copy Fail es su fiabilidad. No es un exploit basado en condiciones de carrera ni en fugas de memoria que funcionan en un kernel de cada diez: funciona de forma determinista en prácticamente todas las versiones afectadas. Eso lo pone en una categoría diferente a la mayoría de las LPE (Local Privilege Escalation) que vemos habitualmente.
Lo más estructuralmente significativo, sin embargo, es que Canonical lleva más de 24 horas sin servicio por un DDoS que debería haberse podido mitigar en minutos. Eso no habla bien de la resiliencia de infraestructura de una empresa que vende exactamente eso: infraestructura fiable para producción. Mi predicción es que veremos cambios importantes en la arquitectura de protección de ubuntu.com en las próximas semanas, probablemente forzados desde las conversaciones internas que este incidente habrá generado.
Preguntas frecuentes
¿Puedo actualizar Ubuntu aunque los servidores de Canonical estén caídos?
Sí. Los mirrors o espejos de los repositorios oficiales siguen funcionando con normalidad. Para cambiar el mirror desde el que se descargan las actualizaciones, abre la aplicación Software y Actualizaciones, ve a la pestaña Software de Ubuntu y despliega el menú «Descargar desde». Selecciona un servidor geográficamente cercano o usa el selector automático. Los repositorios de seguridad también están disponibles desde mirrors alternativos.
¿Cómo sé si mi sistema es vulnerable a Copy Fail (CVE-2026-31431)?
Todos los sistemas con kernel Linux compilado entre agosto de 2017 y principios de 2026 son potencialmente vulnerables, incluyendo Ubuntu 24.04 LTS, 22.04 LTS, RHEL, Debian, Fedora y Amazon Linux. Ubuntu 26.04 Resolute no está afectado. La mitigación inmediata recomendada por Canonical consiste en desactivar el módulo algif_aead. CERT-EU ha publicado una alerta detallada con los pasos concretos, aunque la web oficial de Ubuntu puede no estar accesible temporalmente.
¿Es peligroso Copy Fail para usuarios domésticos de Linux?
El riesgo para un usuario doméstico con un ordenador personal es bajo: la vulnerabilidad requiere acceso local al sistema, lo que en casa habitualmente significa que el atacante ya tiene acceso físico. El riesgo real es alto en entornos compartidos: servidores con múltiples cuentas SSH, clústeres Kubernetes, runners de CI/CD (GitHub Actions, GitLab, Jenkins) y cualquier infraestructura que ejecute código de terceros o usuarios no de confianza.