El 29 de octubre de 2026, el fabricante y el investigador publicaron el mismo día dos explicaciones distintas del mismo cifrado. Al día siguiente apareció una tercera que no encaja con ninguna. Nadie miente, y la parte interesante no es quién tiene razón: es lo que las tres juntas dicen sobre la pantalla que miras para saber si estás al día.
El caso, en tres líneas. Desde principios de octubre, una familia de ransomware llamada C3RB3R —una variante de Cerber— cifra NAS de Synology y renombra los ficheros con la extensión .L0CK3D. El 29 de octubre, el equipo antiransomware de la firma china 360 publicó que la entrada eran dos fallos corregidos el 18 de septiembre. Ese mismo día, Synology publicó una nota en su web diciendo que los atacantes explotan «una vulnerabilidad parcheada en diciembre de 2024» y enlazando a un aviso de hace dos años. Los dos textos existen, están firmados y no se citan el uno al otro.
Las tres versiones, una al lado de otra
Las dos primeras caben a la vez
La contradicción se deshace en los números de compilación. En SA-24:20, la versión que corrige el fallo de 2024 para la rama DSM 7.2.2 es 7.2.2-72806-1 o superior. En SA-26:13, la que corrige los fallos de septiembre para esa misma rama es 7.2.2-72806-9 o superior. Contando la propia -1, son ocho compilaciones en las que un aparato está al día del fallo de 2024 y expuesto al de 2026 —dando por hecho que la numeración no salta, que es un supuesto nuestro—.
La respuesta es aburrida: hay dos parques de aparatos distintos. Uno lleva dos años sin tocarse y lo abre el fallo de 2024; otro se actualizó alguna vez, se quedó parado antes de septiembre y lo abre el de 2026. Synology ve sus casos, 360 ve los suyos, y los dos pueden tener razón sobre lo que han mirado. Esta lectura es nuestra y no nos la ha confirmado nadie, pero es aritmética de versiones, no especulación.
La tercera no necesita un día cero
La víctima que documenta el equipo de respuesta corría DSM 7.4.1-90080 Update 1, una compilación publicada el 12 de octubre y posterior a la que corrige los fallos de septiembre (7.4-90075). La lectura cómoda es «entonces hay un día cero». Pero el propio informe no lo afirma: avisa de que no ha podido establecer si hubo explotación de día cero ni si el aparato ya estaba comprometido antes de actualizarse. Esa segunda puerta es la más mundana y la más probable: la campaña empezó a principios de octubre, y el parche llegó a mitad.
Y hay una tercera puerta que no necesita inventar nada, porque está publicada y fechada. El 22 de octubre de 2026, diez días después de esa compilación, Synology publicó el aviso SA-26:14: dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, las dos en CVSS 9,8, ejecución remota de código. Y no están en DSM.
Dos inventarios de parches y una sola pantalla
Los productos afectados por SA-26:14 son Synology Calendar, Mail Station y los entornos de ejecución de PHP 7.3 a 8.4. Es decir: paquetes. Se corrigen actualizando paquetes, cada uno con su propio número de versión, en otra pantalla. El build de DSM puede estar impecable y esas dos nueve-coma-ocho seguir ahí. El aviso añade dos detalles que conviene no saltarse: Hyper Backup no está afectado, y PHP 7.3 no recibe corrección porque está fuera de soporte. Si un paquete tuyo arrastra ese PHP, no hay botón que pulsar.
Esta es la parte que nos parece más útil de todo el caso, y no depende de saber por dónde entraron. En un NAS conviven dos inventarios de parches —el del sistema y el de los paquetes— que se actualizan por separado, y la pantalla que mira todo el mundo para decir «estamos al día» solo enseña uno. En el peor mes posible, las dos vulnerabilidades de 9,8 más recientes estaban en el inventario que no sale. No afirmamos que la campaña entrara por ahí: nadie lo ha dicho. Afirmamos que si tu comprobación es un número de versión de DSM, no te habrías enterado.
El fallo de 2024 no estaba en ninguna lista de prioridades
Si la versión de Synology es la correcta para tu aparato, hay un detalle que conviene mirar de frente. CVE-2024-10441 salió de un concurso: el aviso se titula literalmente «DSM (PWN2OWN 2024)» y en los agradecimientos aparece el equipo de investigación de DEVCORE, aunque el aviso no dice qué equipo encontró cada CVE. Nunca ha entrado en el catálogo de vulnerabilidades explotadas conocidas de CISA. Durante casi dos años, cualquiera que priorizara por ese catálogo —que son muchos, y es una práctica razonable— tenía este fallo por debajo del corte.
Un matiz de fechas, por honestidad. La nota de Synology dice «diciembre de 2024», pero la página del aviso SA-24:20 está fechada el 5 de noviembre de 2024 y marcada como actualizada el 28 de marzo de 2025. Los avisos de Synology se amplían con el tiempo —se añaden productos y versiones corregidas—, así que la fecha de la nota puede referirse a una ampliación posterior. No lo resolvemos porque no tenemos el historial de cambios del aviso. De la fecha de publicación al 29 de octubre de 2026 hay 723 días; contando desde diciembre, 693. El orden de magnitud no cambia.
Esto no va de un NAS. Va de dónde vive tu copia
En la mayoría de empresas pequeñas que nos hemos encontrado, el mismo aparato hace dos trabajos que nadie decidió juntar: es el servidor de ficheros del día a día y es el destino de las copias. Normalmente porque creció así. Alguien compró un NAS para compartir carpetas, luego alguien apuntó ahí el trabajo de copia porque había sitio, y nadie volvió a mirarlo.
Mira ahora qué permiten las vulnerabilidades de la columna del medio: escritura arbitraria de ficheros, sin autenticación, sobre ese aparato. Cuando el incidente y la pérdida de la recuperación ocurren en el mismo trozo de hierro, no tienes un incidente con copia de seguridad: tienes un incidente. Es el mismo error de diseño que contamos cuando hablamos de el servidor de copias metido en el dominio que tiene que rescatar: la cosa que te salva no puede depender de la cosa que se rompe.
Y antes de que alguien conteste «ya, pero mis instantáneas son inmutables»: la inmutabilidad se cae por la puerta del permiso mucho más a menudo que por la del cifrado, y ya dedicamos un artículo entero a ello —tu copia inmutable tiene un permiso que la borra—. Si la cuenta que puede desactivar la retención vive en el mismo aparato que acaba de caer, la retención es una preferencia.
Siete comprobaciones que valen en los tres relatos
Ninguna depende de acertar la vía de entrada. Son de una tarde.
- ·Apunta la versión entera, con sufijo. En DSM, Panel de control → Actualizar y restaurar. No vale «7.2.2»: lo que decide es el número final,
-72806-9frente a-72806-1. Es exactamente la diferencia entre las dos primeras filas de la tabla. - ·Y luego abre el Centro de paquetes. Esa es la segunda lista. Si tienes Calendar, Mail Station o cualquier paquete que arrastre un PHP, ahí viven las dos vulnerabilidades de 9,8 del 22 de octubre. Desinstala lo que no uses: un paquete que nadie abre desde 2023 es superficie gratis.
- ·Mira el router, no el NAS. Busca reenvíos de puertos hacia él y servicios de acceso remoto activos. La pregunta no es si está «protegido», es si una petición desde internet llega a su interfaz de administración.
- ·Qué cuenta usa el trabajo de copia. Si el servidor de copias entra en el NAS con una cuenta administradora, el que entre en el NAS alcanza las copias. Cuenta dedicada, permiso solo sobre su carpeta, y sin acceso a la consola.
- ·¿Existe una copia fuera de ese aparato? Si la respuesta es «las instantáneas del propio NAS», no hay copia: hay versiones. Otro destino, otras credenciales, otro sitio físico o lógico.
- ·Quién puede apagar la retención. Haz la lista de cuentas capaces de borrar o acortar una copia marcada como inmutable. Si incluye al administrador del aparato comprometido, vuelve al punto anterior.
- ·Restaura algo de verdad, con cronómetro. No un fichero: un conjunto que alguien use mañana. El número que salga es tu tiempo de recuperación real, y suele ser la primera vez que alguien lo mide.
Cuándo esto no te aplica
Si tu NAS es un destino secundario, no llega a él nada desde internet, el trabajo de copia entra con una cuenta dedicada y hay una copia más en otro sitio que ese aparato no puede tocar, esta semana no tienes un problema: tienes un simulacro gratis. Comprueba los siete puntos en una hora y sigue con tu trabajo. Decirlo nos parece más útil que convertir cada noticia en una urgencia.
Y al revés: si el aparato es tu único almacenamiento y lo publicaste en internet para que alguien pudiera trabajar desde casa, tanto da el fabricante. Este mes le ha tocado a una marca; la arquitectura de «un cacharro con interfaz web que guarda todo y se actualiza por dos sitios distintos» es la misma en todas.
Dónde nos deja esto a nosotros
No hemos respondido a ninguno de estos incidentes y no tenemos telemetría propia sobre la campaña: lo que tenemos son tres páginas de aviso leídas enteras y un calendario. Pero la conclusión la aplicamos todos los días cuando montamos un plan de disaster recovery: el diseño se valida contra el caso en el que no sabes cómo entraron. Si tu plan solo funciona cuando el informe forense llega a tiempo, tiene una dependencia que no controlas.
La parte aburrida —que el aparato esté inventariado, que alguien sepa que tiene dos listas de actualizaciones y no una, y que haya una ventana con un responsable que la firme— es mantenimiento informático. Si al leer los siete puntos te has quedado atascado en el quinto, que es donde se atasca casi todo el mundo, escríbenos y lo miramos juntos.
Nota de fuentes. Hemos leído directamente tres páginas de Synology y de ahí salen todos los datos duros. SA-26:13, publicado el 18-09-2026: ocho CVE, con CVE-2026-13684 y CVE-2026-13639 en CVSS 9,8 (vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) y versiones corregidas 7.4-90075, 7.3.2-86009-4, 7.2.2-72806-9 y 7.2.1-69057-12. SA-24:20, titulado «DSM (PWN2OWN 2024)», publicado el 05-11-2024 y actualizado el 28-03-2025: tres CVE, con CVE-2024-10441 en CVSS 9,8, y versiones corregidas 7.2.2-72806-1, 7.2.1-69057-6, 7.2-64570-4, 7.1.1-42962-7 y 6.2.4-25556-8. SA-26:14, publicado el 22-10-2026: CVE-2026-109618 y CVE-2026-109619, las dos en CVSS 9,8, afectando a Synology Calendar, Mail Station y PHP 7.3 a 8.4, con Hyper Backup no afectado y PHP 7.3 sin corrección por fin de soporte. La nota de prensa de Synology del 29-10-2026 la hemos leído en su propia web: habla de «una vulnerabilidad parcheada en diciembre de 2024», enlaza SA-24:20 y no cita ningún CVE ni menciona los avisos de 2026. El solape de compilaciones entre avisos, la lectura de que hay dos parques distintos y la tesis de los dos inventarios de parches son nuestras y están marcadas como tales. De segunda mano, a través de la cobertura periodística del 29, 30 y 31 de octubre de 2026 y sin verificación propia: la atribución de 360 a CVE-2026-13639 y CVE-2026-13684, el informe de Solar con la víctima en DSM 7.4.1-90080 Update 1 y sus salvedades —que circuló en redes y no hemos podido leer en origen—, la fecha de publicación de esa compilación (12-10-2026) y la autoría de DEVCORE en Pwn2Own. Que CVE-2024-10441 no figura en el catálogo de vulnerabilidades explotadas conocidas de CISA es lo que recogen las fichas públicas del CVE a fecha de hoy. No somos clientes ni distribuidores de ninguno de los fabricantes citados y no hemos participado en la respuesta a ninguno de estos casos.
Microsoft 365
ES 
CAT 
EN