CVE SonicWall SSRF Zero-day RCE 6 min lectura

SonicWall SMA1000: cadena de SSRF y code injection explotada en tándem contra appliances VPN (CVE-2026-15409 / CVE-2026-15410)

SonicWall publicó SNWLID-2026-0008 con dos fallas activamente explotadas en sus gateways SSL-VPN SMA1000: una SSRF sin autenticación con CVSS 10.0 y una inyección de código post-auth. Parchear no alcanza: si los logs muestran IoCs, hay que re-imagear el appliance.

IP
IPSecureNetwork
July 15, 2026

Contexto del incidente

El 14 de julio de 2026, SonicWall publicó la advisory SNWLID-2026-0008 confirmando que dos vulnerabilidades en sus appliances Secure Mobile Access (SMA) 1000 Series estaban siendo activamente explotadas en la wild. La primera, CVE-2026-15409, es una falla de tipo Server-Side Request Forgery (SSRF, CWE-918) en la interfaz Work Place del appliance, con un puntaje CVSS v3.0 de 10.0 y vector CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Un atacante remoto, sin autenticación, puede provocar que el appliance haga requests HTTP a destinos internos no intencionados — pivotando hacia servicios que de otra forma están segmentados detrás del borde.

La segunda, CVE-2026-15410, es una falla de code injection post-autenticación (CWE-94) en el Appliance Management Console (AMC) con CVSS 7.2. Un atacante autenticado como administrador puede ejecutar comandos arbitrarios del sistema operativo sobre el appliance. Lo crítico del aviso es que las dos vulnerabilidades se están explotando en tándem: el SSRF (CVE-2026-15409) actúa como vector de acceso inicial sin credenciales, y una vez dentro, CVE-2026-15410 permite al atacante consolidar RCE sobre el appliance. CISA agregó ambas al catálogo KEV el mismo 14 de julio de 2026, bajo BOD 26-04, con plazo de remediación federal inmediato.

El caso es grave porque los SMA 1000 no son un appliance de nicho. Son gateways SSL-VPN que SonicWall vende a medianas y grandes empresas, multinacionales, agencias gubernamentales y MSSPs. Un appliance VPN corporativo comprometido es la antesala lógica de un ataque de ransomware: el atacante ya tiene un túnel legítimo hacia la red interna y un punto de pivote persistente hasta que alguien lo detecte. Y el aviso de SonicWall trae un dato incómodo que merece subrayado: parchear no es suficiente. Si los logs muestran alguno de los IoCs que la advisory lista, hay que re-imagear el appliance (o re-desplegarlo, en el caso virtual), cambiar todas las contraseñas de usuarios y administradores, y resetear los tokens TOTP. El atacante pudo haber dejado persistencia — cuentas admin nuevas, claves SSH, cron jobs, binarios modificados — que sobrevive a un simple upgrade de firmware.

El crédito del descubrimiento es para Adam Babis, del PSIRT de SonicWall, quien reportó ambas fallas. Sean Koessel y Steven Adair, de Volexity, aportaron un IoC adicional a la investigación. El patrón de SonicWall como blanco recurrente es conocido: los atacantes vuelven a esta superficie con una regularidad incómoda (CVE-2025-23006, CVE-2025-40602, CVE-2021-20035, entre otros), lo que vuelve crítico mantener una disciplina de monitoreo específica para este vendor.

Un VPN appliance no se compromete dos veces por el mismo agujero — se compromete, se le olvida el parche, y se vuelve a comprometer.

¿Cómo proteger tu infraestructura?

1. Upgrade inmediato a los hotfixes — y revisión de logs antes de hacerlo

Las versiones afectadas son las 12.4.3-03245, 12.4.3-03387, 12.4.3-03434, 12.5.0-02283, 12.5.0-02624 y 12.5.0-02800 (todas platform-hotfix). Los hotfixes publicados son 12.4.3-03453 y 12.5.0-02835, aplicables a los modelos SMA6210, SMA7200 y SMA8200v. Es importante destacar que estas fallas no afectan al SSL-VPN que corre sobre los firewalls SonicWall ni a la línea SMA 100 Series. Antes de aplicar el parche, revisá los logs en busca de los IoCs que listamos en la siguiente sección: si aparecen, parchear no es suficiente y hay que pasar al plan de remediación del punto 2.

2. Si hay IoCs: re-image, reset de credenciales y de TOTP

El aviso de SonicWall es explícito: "It is important that customers understand patching alone is not sufficient". Si los logs muestran alguno de los IoCs de SNWLID-2026-0008, el camino correcto es: (a) re-imagear el appliance físico o re-desplegar el virtual desde una imagen limpia; (b) cambiar todas las contraseñas de usuarios y administradores; (c) resetear todos los tokens TOTP. Esto asume que el atacante pudo haber dejado persistencia que sobrevive al upgrade de firmware. Subestimar este punto es el error más caro que podés cometer con esta advisory.

3. Restringir el acceso al AMC hasta que el parche esté aplicado

Como work-around transitorio, restringí el acceso al Appliance Management Console (puerto TCP 8443 por defecto) a redes internas confiables. En appliances dual-homed, esto se configura en la interfaz interna; en single-homed, hace falta una regla de firewall que sólo permita el 8443 desde la subred de administración. Esta mitigación no impacta el tráfico de VPN de los usuarios, sólo el acceso administrativo al appliance. Combinado con TOTP obligatorio en cuentas admin, reduce notablemente la superficie explotable por CVE-2026-15410 hasta que el firmware quede actualizado.

4. Activar MFA en todas las cuentas administrativas del SMA1000

CVE-2026-15410 requiere credenciales de admin para ser explotada, pero la realidad operativa es que muchos appliances SMA1000 tienen cuentas admin con contraseñas reutilizadas, sin MFA, o compartidas entre varios operadores. La guía de administración del SMA1000 incluye una sección de Best Practices for Securing the Appliance — revisala y, como mínimo, forzá TOTP (que el appliance ya soporta nativamente) en todas las cuentas con permisos de administración. Si tu appliance está detrás de un bastión o un IdP corporativo, evaluá integrarlo allí en lugar de mantener credenciales locales.

Indicadores de compromiso (IoC)

El PSIRT de SonicWall publicó IoCs específicos en la sección Indicators of Compromise (IOCs) de SNWLID-2026-0008. Todos son verificables en logs locales del appliance, sin necesidad de feeds externos de telemetría. La ventaja es que la superficie de log de un SMA 1000 es chica y bien conocida; la desventaja es que el atacante opera dentro del propio appliance, así que no aparece en tu SIEM perimetral hasta que algo sale.

  • Log — extraweb_access.log: requests a /__api__/login o /__api__/logout con código HTTP 200. Estos URIs no existen en la configuración legítima del Work Place, así que toda aparición es indicador de compromiso.
  • Log — extraweb_access.log: requests a /wsproxy con parámetros host sospechosos y código HTTP 101 (Switching Protocols, típico de un WebSocket upgrade). Es la firma del SSRF pivotando hacia destinos internos.
  • Log — ctrl-service.log: entradas de hotfix rollback con nombres que contienen secuencias de path traversal (../). Indica que el atacante intentó instalar o revertir un firmware manipulado.
  • Archivo de configuración: rutas para /__api__/login o /__api__/logout en /var/lib/unit/conf.json. Si estas rutas aparecen en el reverse proxy interno (Unit), es porque el atacante las inyectó para mantener un punto de entrada persistente.

Para cazar estos IoCs en un appliance sospechoso, los siguientes comandos se pueden correr por SSH con la cuenta de administración del appliance:

# 1) Buscar URIs sospechosos en el log de access del Work Place
grep -E "(__api__|wsproxy) " /var/log/extraweb/extraweb_access.log \
  | grep -E "HTTP/1\.[01]\" (200|101) "

# 2) Confirmar rutas inyectadas en el reverse proxy Unit
grep -E "(__api__|wsproxy)" /var/lib/unit/conf.json

# 3) Buscar rollbacks de hotfix con path traversal
grep -E "rollback" /var/log/ctrl-service.log | grep -E "\.\./"

Si tenés un sensor Suricata que ve tráfico hacia tu appliance desde Internet, una regla específica para cazar el patrón del SSRF en el Work Place interface puede darte aviso anticipado:

alert http any any -> $SMA1000_SERVERS any \
  (msg:"POSIBLE SonicWall SMA1000 SSRF (CVE-2026-15409) - Work Place interface"; \
   flow:to_server,established; \
   content:"/__api__/"; http_uri; \
   content:"login"; http_uri; \
   sid:2026154091; rev:1;)

Y como verificación complementaria, revisá la tabla de shadowserver para SMA1000: el feed diario de Shadowserver indexa appliances con la interfaz de administración expuesta a Internet. Si tu ASN aparece en el feed con un firmware en el rango 12.4.3-03245 a 12.4.3-03434 o 12.5.0-02283 a 12.5.0-02800, es urgente aplicar el hotfix antes de que el primer intento automatizado te encuentre.

🛡️ ¿Tenés appliances SonicWall SMA 1000 expuestos a Internet?

Una VPN corporativa comprometida es la antesala lógica de un ransomware. En IPSecureNetwork podemos hacer un relevamiento de tus appliances SonicWall, verificar firmware contra SNWLID-2026-0008, revisar logs en busca de los IoCs publicados por el PSIRT, y aplicar las mitigaciones necesarias sin cortar el servicio a tus usuarios. Si ya detectaste actividad sospechosa, te ayudamos con el plan de re-image, reset de credenciales y reseteo de TOTP.

SOLICITAR AUDITORÍA →