Si su empresa guarda archivos de trabajo y copias de seguridad en un NAS Synology, debe comprobar la versión completa de DSM y la independencia de sus respaldos. El aviso publicado por INCIBE-CERT el 21 de septiembre de 2026 recoge ocho vulnerabilidades, incluidas dos críticas. La decisión no termina al instalar una actualización: también importa saber quién puede alcanzar el equipo y qué ocurriría si dejara de estar disponible.
Esta revisión es pertinente para empresas de Colombia, México y otros mercados latinoamericanos que utilicen las ramas afectadas, con independencia de dónde se publicó la alerta. No hay en las fuentes consultadas una identificación de víctimas locales. La exposición depende del producto, la versión y su configuración, no del país donde opera la organización.
Qué confirmó el aviso de septiembre
INCIBE identifica el aviso como INCIBE-2026-650 y remite a Synology-SA-26:13. El comunicado del fabricante está fechado el 18 de septiembre; la publicación de INCIBE del día 21 es la referencia reciente de esta noticia. No se presenta el descubrimiento como si hubiera ocurrido el día de publicación de este artículo.
Los fallos críticos CVE-2026-13684 y CVE-2026-13639 pueden permitir a un atacante remoto no autenticado leer o escribir archivos arbitrarios y provocar denegación de servicio. El primero afecta al tratamiento de salida en SCGI; el segundo, a la entropía utilizada en la lógica de inicio de sesión. Synology les asigna una puntuación CVSS de 9,8.
La existencia de un fallo crítico no demuestra que un equipo haya sido atacado. INCIBE no registra explotación en su tabla para los identificadores mostrados al consultar el aviso. Esa ausencia de confirmación pública tampoco es prueba de que cada instalación permanezca intacta: la investigación de un equipo concreto requiere registros y contexto propios.
Versiones corregidas: compruebe el número completo
La tabla siguiente reproduce los niveles de corrección indicados en el aviso. Compare la compilación y el número de actualización, no solo la familia de DSM. Antes de ejecutar el cambio, confirme en el portal oficial las instrucciones y compatibilidad de su modelo.
| Rama | Actualizar a |
|---|---|
| DSM 7.4 | 7.4-90075 o posterior |
| DSM 7.3 | 7.3.2-86009-4 o posterior |
| DSM 7.2.2 | 7.2.2-72806-9 o posterior |
| DSM 7.2.1 | 7.2.1-69057-12 o posterior |
El fabricante no ofrece una mitigación alternativa en el aviso. Reducir accesos o aislar temporalmente el equipo puede disminuir exposición, pero no corrige el defecto del software. Si una dependencia impide actualizar, documente la causa, limite el acceso y acuerde una ventana de resolución con el responsable del negocio.
Cómo saber si el NAS importa para un proceso crítico
Empiece por un inventario pequeño y útil: nombre del equipo, modelo, versión, ubicación lógica, responsable, servicios habilitados y datos que contiene. Identifique si soporta archivos compartidos, repositorios de respaldo, grabaciones u otros procesos. No dé por supuesto que todos los paquetes instalados tienen el mismo alcance de exposición que DSM.
Después pregunte qué usuarios y sistemas necesitan conectarse. Un almacenamiento puede parecer secundario hasta que se descubre que conserva los documentos necesarios para facturar o la única copia reciente de una aplicación. La criticidad debe derivarse de esas dependencias, no del precio del dispositivo ni de su tamaño físico.
Un proveedor externo puede administrar el NAS sin ser dueño de la decisión de riesgo. La empresa debe conservar visibilidad de quién aprueba actualizaciones, dónde se guardan las credenciales y qué evidencia entrega el proveedor después de intervenir. Si nadie puede responder esas preguntas, el primer hallazgo es de gobierno, incluso antes de revisar vulnerabilidades.
Revise las rutas de acceso, no solo la pantalla de administración
Compruebe la publicación de servicios hacia Internet, las reglas de red y los mecanismos de acceso remoto usados por empleados y terceros. Incluya rutas a través de otras redes, túneles o servicios de conexión. Un equipo sin dirección pública directa puede seguir siendo accesible desde una cuenta o dispositivo que un atacante consiga comprometer.
Limite la administración a los orígenes necesarios y separe las cuentas administrativas de las utilizadas para tareas corrientes. Revise permisos sobre carpetas, enlaces compartidos y cuentas de servicio. No todos esos controles solucionan los CVE del aviso; su utilidad es reducir caminos de entrada y el alcance de acciones autorizadas en el entorno.
La revisión debe ejecutarse con autorización y métodos adecuados para la operación. No es necesario lanzar una prueba agresiva contra el almacenamiento productivo para confirmar una versión vulnerable. La evidencia documental, la configuración y comprobaciones no destructivas pueden resolver la primera decisión con menos riesgo.
Un NAS con archivos no es automáticamente una copia independiente
La pregunta central es si un mismo acceso puede comprometer el original y la recuperación. Guardar archivos en dos carpetas del mismo equipo no crea necesariamente independencia. Tampoco basta con disponer de otro dispositivo si comparte credenciales administrativas o permite borrar las copias mediante la misma identidad que administra el entorno principal.
Revise separación de permisos, retención y posibilidad de restaurar sin depender del sistema afectado. Cuando existan funciones de inmutabilidad, confirme su alcance y configuración; no asuma que una etiqueta comercial impide cualquier borrado. Una instantánea puede ser útil, pero debe evaluarse junto a la arquitectura y las amenazas que se pretende resistir.
Pruebe una restauración en un destino autorizado y aislado, usando una muestra representativa y verificando que el contenido sirve para el negocio. Recuperar un archivo legible es diferente de recuperar una aplicación con sus dependencias. Documente el tiempo, los pasos manuales y los permisos requeridos, sin prometer que una prueba pequeña representa todos los sistemas.
Actualización con evidencia antes y después
Prepare el cambio con el administrador y el dueño del proceso. Compruebe estado del almacenamiento, disponibilidad de respaldo, espacio y compatibilidad. Defina a quién avisar, qué servicios pueden interrumpirse y cómo se decidirá que el cambio terminó correctamente. Descargue paquetes únicamente desde los canales oficiales y siga la documentación del fabricante.
Registre versión inicial, versión final, hora y responsable. Después compruebe acceso a los recursos necesarios, ejecución de tareas de copia y funcionamiento de los servicios realmente utilizados. No declare remediación solo porque la consola mostró un reinicio satisfactorio. La validación debe unir estado técnico y continuidad de la operación.
Si aparece un comportamiento anómalo, evite sucesivas intervenciones improvisadas. Preserve registros disponibles, establezca una cronología y determine si el problema corresponde a compatibilidad, configuración o posible compromiso. Son situaciones diferentes que requieren decisiones distintas; asumir que cualquier fallo posterior al parche es un ataque puede desviar la respuesta.
Cuándo pasar de parcheo a investigación
Una actualización corrige una condición vulnerable; no explica por sí sola qué ocurrió antes. Si hay usuarios desconocidos, cambios no autorizados, permisos alterados, archivos inesperados o conexiones sin justificación, escale la revisión. Estas señales son orientativas y deben contrastarse: una tarea legítima del proveedor también puede producir cambios que el equipo interno no reconocía.
Conserve registros y configuraciones antes de borrar elementos sospechosos. Coordine el aislamiento para no destruir evidencia o cortar una recuperación en curso. El Análisis Forense Digital de Insylux puede ayudar a reconstruir hechos dentro de un alcance acordado. No atribuya actividad a un actor ni afirme exfiltración sin evidencia suficiente.
Si además existen archivos cifrados o extorsión, active un proceso específico de contención y recuperación. El servicio de Ransomware RRR: recuperación y resiliencia aborda ese escenario. Este aviso no demuestra una campaña de ransomware contra Synology ni permite garantizar recuperación de información.
Qué exigir al proveedor que administra el almacenamiento
Solicite una respuesta por equipo: versión, exposición, datos soportados, acción y evidencia de cierre. Un mensaje que diga «equipos actualizados» sin identificar activos no permite comprobar cobertura. También deben registrarse equipos fuera de soporte, dependencias que impiden cambios y excepciones aceptadas con fecha de revisión.
| Decisión | Comprobación mínima | Responsable sugerido |
|---|---|---|
| Aplicar corrección | Compilación final y servicios operativos. | Administrador del almacenamiento. |
| Reducir exposición | Rutas autorizadas y accesos retirados. | Responsable de redes y seguridad. |
| Asegurar recuperación | Restauración probada y permisos separados. | Responsable de respaldos y negocio. |
| Investigar anomalías | Cronología, registros y alcance delimitado. | Equipo de respuesta a incidentes. |
Para organizaciones que coordinan oficinas o proveedores entre Colombia y México, acuerde además horario de intervención y canal de escalamiento. Esa coordinación es una necesidad operativa, no evidencia de mayor explotación regional. La misma disciplina resulta útil para una única sede con almacenamiento compartido y soporte remoto.
Preguntas frecuentes antes de actualizar
¿Basta con cambiar la contraseña del administrador?
No. Los dos fallos críticos descritos no requieren autenticación según los avisos. Mejorar contraseñas y permisos sigue siendo útil, pero no reemplaza la instalación de la versión corregida ni la revisión de las rutas de acceso.
¿Debo apagar todos los NAS inmediatamente?
No existe una respuesta universal. Determine exposición y criticidad, coordine restricciones y aplique el parche con urgencia proporcionada. Si hay evidencia de compromiso, el aislamiento debe formar parte de una respuesta que preserve información y considere continuidad.
¿Un escaneo confirma que los respaldos funcionan?
No. El análisis de vulnerabilidades y la prueba de restauración responden preguntas diferentes. Se necesitan tanto evidencias de corrección como una recuperación comprobada para sostener que el plan cubre ambos objetivos.
Obtenga una decisión verificable por activo
Fuentes y límites
- INCIBE-CERT: aviso INCIBE-2026-650, publicado el 21 de septiembre de 2026.
- Synology-SA-26:13 DSM, publicado el 18 de septiembre de 2026: identificadores, condiciones técnicas y versiones corregidas.
- NIST: recursos de seguridad para pequeñas empresas, contexto para protección de datos y respuesta.
El inventario, las tablas de trabajo y las recomendaciones operativas son elaboración de Equipo Insylux. Las versiones deben contrastarse nuevamente antes de ejecutar cambios; no se afirma afectación de empresas latinoamericanas concretas.
