Si tu empresa utiliza un firewall SonicWall, o si externalizas la TI con un proveedor de servicios administrados (MSP) que inicia sesión de forma remota para mantener tus sistemas actualizados y respaldados, tienes dos razones distintas para hacer una llamada esta semana. Ambas están relacionadas con vulnerabilidades que los atacantes están explotando ahora mismo, no con riesgos teóricos mencionados en un boletín del proveedor que nadie lee. Ninguna 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 con cada una, junto con una lista de verificación que puedes copiar, pegar y enviar a quien administre tu red.

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

SonicWall divulgó y corrigió dos vulnerabilidades el 14 de julio de 2026, pero según la propia cronología 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 equipo 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 fallas se han vinculado de manera definitiva específicamente con INC; es casi seguro que también participan otros atacantes oportunistas). Por separado, la firma de seguridad Huntress informó sobre una oleada rápida en la que 30 clientes de SonicWall fueron comprometidos en menos de dos días. Este no es un riesgo de evolución lenta.

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

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

  • «¿Qué modelo y versión de firmware de SonicWall estamos utilizando actualmente, y esa versión corrige CVE-2026-15409 y CVE-2026-15410?» (Pídeles que lo confirmen comparándolo con el aviso oficial de SonicWall; no aceptes «tenemos la última versión» sin un número de versión.)
  • «¿En qué fecha aplicamos la corrección?» Si fue después del 14 de julio de 2026, pídeles que revisen los registros de 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.
  • «¿Nuestra SSLVPN o nuestro portal de acceso remoto estuvieron expuestos a internet durante ese periodo?» Si la respuesta es sí, solicita un restablecimiento obligatorio de contraseña para todas las cuentas que se autentiquen mediante él, no solo una corrección.
  • «¿La configuración de nuestro firewall se respaldó alguna vez en el servicio en la nube de SonicWall y, de ser así, ya se cambiaron las credenciales incluidas en ese archivo?»
  • «¿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 administración remota de tu MSP (CVE-2026-18577 en N-able N-central)

Este caso es diferente porque no se trata de tu equipo: es una herramienta que tu proveedor de TI podría utilizar para administrar 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 Seguridad de Infraestructura y Ciberseguridad de Estados Unidos) agregó 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 falla permite que un atacante obtenga acceso administrativo total a la propia consola de N-central.

Eso importa por lo que un atacante puede hacer desde allí. Huntress informó que los ataques exitosos pasaron de la consola comprometida a los endpoints administrados mediante ella; es decir, una intrusión en la herramienta del MSP puede convertirse en una intrusión en tus sistemas sin que el atacante te dirija el ataque 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. Necesitas preguntar, y hacerlo de manera más amplia que limitándote al nombre de ese producto.

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

  • «¿Utilizan N-able N-central o algún otro producto de N-able para administrar nuestros sistemas?» Si la respuesta es sí: «¿Está corregido contra CVE-2026-18577 y a partir de qué fecha?»
  • «¿Han auditado la actividad de las cuentas administrativas y los registros de acceso de su consola de administración desde el 31 de julio de 2026 en busca de algo que no puedan explicar?»
  • «¿Han revisado específicamente nuestros sistemas en busca de conexiones salientes inesperadas, particularmente 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 cuentas nuevas de administrador local, tareas programadas o políticas de administración remota que no puedan atribuir a su propio equipo?»
  • «Si no utilizan N-central, ¿qué herramienta de administración remota utilizan en su lugar y alguna vulnerabilidad de esa herramienta se ha agregado recientemente al catálogo de Vulnerabilidades Explotadas Conocidas de CISA?»

Qué hacer con las respuestas

Un buen proveedor de TI responderá estas preguntas con fechas y detalles, a menudo en un día, porque ya debería conocer esta información o poder obtenerla rápidamente de los registros. Una respuesta vaga —«estamos ocupándonos», «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 un plazo definido.

Si administras tu propio SonicWall sin un MSP, la lista de verificación anterior también se aplica directamente a ti: inicia sesión en la consola de administración, verifica la versión del firmware y consulta la página de avisos de SonicWall para encontrar la versión que corrige ambas CVE.

Ninguna de estas fallas requiere que elimines a un proveedor o despidas a un prestador de servicios. Requieren confirmar que la brecha específica se haya cerrado y que nada haya pasado por ella 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 que está siendo «explotado activamente». Volverá a suceder.