Si tu empresa utiliza un firewall SonicWall, o si subcontratas la TI a un proveedor de servicios gestionados (MSP) que inicia sesión de forma remota para mantener tus sistemas actualizados y respaldados, tienes dos motivos distintos para hacer una llamada esta semana. Ambos tienen que ver con vulnerabilidades que los atacantes están explotando ahora mismo, no con riesgos teóricos descritos en un boletín del proveedor que nadie lee. Ninguno requiere que te conviertas en experto en seguridad. Requiere que hagas preguntas específicas y esperes respuestas específicas —fechas, números de versión, confirmaciones—, no palabras tranquilizadoras.

Esto es lo que está ocurriendo en cada caso, junto con una lista de comprobación que puedes copiar, pegar y enviar a quien gestione tu red.

Problema 1: Tu firewall SonicWall (CVE-2026-15409 y CVE-2026-15410)

SonicWall informó y corrigió dos vulnerabilidades el 14 de julio de 2026, pero, según el propio cronograma de la empresa, los atacantes ya las habían estado explotando durante aproximadamente tres semanas antes de la divulgación pública. Eso significa que «ya está corregido» y «ya es seguro» no son automáticamente lo mismo para un dispositivo que estuvo expuesto a internet durante ese periodo.

El actor de amenazas mencionado con mayor frecuencia en relación con esta cadena de vulnerabilidades es INC, una operación de ransomware como servicio que los investigadores de Rapid7 describen como uno de los grupos de este tipo más activos del mundo en este momento (aunque no todos los ataques que utilizan estas vulnerabilidades se han vinculado de forma definitiva específicamente con INC; es casi seguro que también hay otros atacantes oportunistas implicados). Por separado, la firma de seguridad Huntress informó de una oleada rápida en la que se comprometieron 30 clientes de SonicWall en menos de dos días. Este no es un riesgo de evolución lenta.

También hay antecedentes relevantes: SonicWall informó anteriormente de un incidente en el que un grupo patrocinado por un Estado robó archivos de configuración del firewall de todos los clientes de SonicWall que utilizaban su función de copias de seguridad en la nube. Un archivo de configuración robado puede contener credenciales de cuentas locales y ajustes de VPN. Si la configuración de tu firewall se respaldó alguna vez en el servicio en la nube de SonicWall antes de que se contuviera ese incidente, corregir las vulnerabilidades actuales no deshace lo que ya se hubiera expuesto; es posible que aún sea necesario rotar las credenciales de esa configuración.

Lista de comprobación para enviar a tu proveedor de TI o MSP:

  • «¿Qué modelo de SonicWall y qué versión de firmware estamos ejecutando actualmente, y esa versión corrige CVE-2026-15409 y CVE-2026-15410?» (Pídeles que lo confirmen consultando el aviso oficial de SonicWall; no aceptes «tenemos la versión más reciente» sin un número de versión).
  • «¿En qué fecha aplicamos el parche?» Si fue después del 14 de julio de 2026, pídeles que revisen los registros correspondientes a las semanas anteriores en busca de indicios de acceso no autorizado: inicios de sesión inesperados de administradores, cuentas locales nuevas o sesiones de SSLVPN desde direcciones IP desconocidas.
  • «¿Estuvo nuestro portal de SSLVPN o de acceso remoto expuesto a internet durante ese periodo?» Si la respuesta es afirmativa, pide un restablecimiento obligatorio de contraseña para todas las cuentas que se autentican a través de él, no solo la aplicación de un parche.
  • «¿Se respaldó alguna vez la configuración de nuestro firewall en el servicio en la nube de SonicWall y, en caso afirmativo, se han rotado desde entonces las credenciales incluidas en ese archivo de configuración?»
  • «¿Tienen habilitada la autenticación multifactor en todas las cuentas de acceso remoto a través del firewall?» Si no, pídeles que la activen esta semana.

Problema 2: La herramienta de gestión remota de tu MSP (CVE-2026-18577 en N-able N-central)

Este caso es diferente porque no se trata de tu equipo, sino de una herramienta que tu proveedor de TI podría utilizar para gestionar decenas o cientos de empresas clientes, posiblemente incluida la tuya, desde una consola central. N-able N-central es una de esas plataformas, y CISA (la Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos) añadió una vulnerabilidad en ella —CVE-2026-18577, con una gravedad de 8.2 sobre 10— a su catálogo de Vulnerabilidades Explotadas Conocidas después de confirmar su explotación activa desde el 31 de julio de 2026. Según los informes, la vulnerabilidad permite que un atacante obtenga acceso administrativo completo a la propia consola de N-central.

Eso importa por lo que un atacante puede hacer desde allí. Huntress informó de que los ataques exitosos pasaron de la consola comprometida a los endpoints gestionados a través de ella; es decir, una vulneración de la herramienta del MSP puede convertirse en una vulneración de tus sistemas sin que el atacante te haya apuntado directamente. Huntress también descubrió que los atacantes creaban túneles de Cloudflare en sistemas comprometidos, una técnica que les proporciona una vía de regreso persistente y cifrada que puede parecer tráfico web normal para un firewall.

No necesitas saber si tu proveedor específico utiliza N-central. Tienes que preguntar, y hacerlo de forma más amplia que limitándote a ese nombre de producto.

Lista de comprobación para enviar a tu proveedor de TI o MSP:

  • «¿Utilizan N-able N-central o cualquier otro producto de N-able para gestionar nuestros sistemas?» Si la respuesta es afirmativa: «¿Está actualizado contra CVE-2026-18577 y a fecha de cuándo?»
  • «¿Han auditado la actividad de las cuentas de administrador y los registros de acceso de su consola de gestión desde el 31 de julio de 2026 en busca de algo que no puedan explicar?»
  • «¿Han comprobado específicamente nuestros sistemas en busca de conexiones salientes inesperadas, en particular procesos de túneles de Cloudflare (que a veces aparecen como “cloudflared”) o dominios de túnel que ustedes no hayan configurado?»
  • «¿Se han enviado a nuestros sistemas nuevas cuentas de administrador local, tareas programadas o políticas de gestión remota que no puedan atribuir a su propio equipo?»
  • «Si no utilizan N-central, ¿qué herramienta de gestión remota utilizan en su lugar y se ha añadido recientemente alguna vulnerabilidad de esa herramienta al catálogo de Vulnerabilidades Explotadas Conocidas de CISA?»

Qué hacer con las respuestas

Un buen proveedor de TI responderá con fechas y detalles, a menudo en el plazo de un día, porque ya debería conocer esta información o poder extraerla rápidamente de los registros. Una respuesta vaga —«lo tenemos bajo control», «nuestros sistemas son seguros», sin ofrecer fechas— también es información útil: te indica que esta conversación debe repetirse, por escrito y con una fecha límite establecida.

Si gestionas tu propio SonicWall sin un MSP, la lista de comprobación anterior también se aplica directamente a ti: inicia sesión tú mismo en la consola de gestión, comprueba la versión del firmware y consulta la página de avisos de SonicWall para encontrar la versión que corrige ambas CVE.

Ninguno de estos fallos exige que elimines a un proveedor ni que despidas a un prestador de servicios. Exigen confirmar que la brecha específica se ha cerrado y que nada la atravesó mientras estuvo abierta. Haz las preguntas, obtén las fechas y pon un recordatorio en tu calendario para volver a preguntar la próxima vez que un proveedor revele algo «explotado activamente». Volverá a ocurrir.