El 14 de julio, SonicWall cerró un par de zero-days explotados en sus SMA 1000 con la build 12.4.3-03453. El 1 de septiembre publicó otro aviso. Entre las versiones afectadas figura la 12.4.3-03453 y anteriores. La build que te dejaba al día en julio es la última build vulnerable en septiembre, y entre una cosa y la otra pasaron 49 días.
De los de julio ya escribimos: el appliance VPN perimetral es el objetivo perfecto. Volver sobre la misma caja siete semanas después no nos hace ninguna gracia, y precisamente por eso este post no va de correr más con los parches. Va de una cosa que solo se ve cuando pones los dos avisos uno al lado del otro.
Los dos avisos, en la misma tabla
Esto sale de las fichas del NVD y de los avisos del fabricante, no de titulares:
| Julio (SNWLID-2026-0008) | Septiembre (SNWLID-2026-0016) | |
|---|---|---|
| SSRF sin autenticar | CVE-2026-15409 — 10.0 | CVE-2026-83548 — 10.0 |
| Su vector CVSS | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| Componente | Work Place | Work Place |
| Ejecución de comandos | CVE-2026-15410 — 7.2AV:N … PR:H | CVE-2026-83549 — 7.8AV:L … PR:L |
| Dónde vive | AMC | AMC |
| Build corregida | 12.4.3-03453 / 12.5.0-02835 | 12.4.3-03526 / 12.5.0-02952 |
| Entrada en el KEV | 14-jul → plazo 17-jul | 2-sep → plazo 5-sep |
La fila que importa es la sexta. 12.4.3-03453 es a la vez la build que arregló julio y la build más nueva que septiembre declara afectada. No es un matiz de redacción: quien cumplió el plazo de tres días del catálogo KEV en julio —que era lo correcto— aterrizó exactamente en la versión que 49 días después vuelve a estar en ese mismo catálogo.
Y el vector CVSS de los dos SSRF es idéntico carácter a carácter. Misma nota, mismo vector, misma clase de fallo (CWE-918), mismo componente. Dos veces en siete semanas.
El «local» que no te protege
Aquí está la parte que se desprioriza sola. El CVE de ejecución de julio venía con AV:N (red) y PR:H (privilegios altos). El de septiembre viene con AV:L —vector de ataque local— y PR:L. Un responsable de IT que abre la ficha, lee «local» y tiene el AMC restringido a la red de gestión, cierra la pestaña tranquilo. Es la reacción lógica y es la equivocada. Y hay un detalle que conviene poner encima de la mesa antes de seguir: la descripción que la propia SonicWall firma para ese CVE habla de «un atacante remoto autenticado como administrador» —remoto y admin— mientras el vector dice AV:L y PR:L. El de julio, descrito casi con las mismas palabras, se puntuó AV:N y PR:H. El bicho no cambió tanto entre julio y septiembre; lo que cambió es cómo se puntuó. Y eso no te da una salida: o el AV:L es literal y algo tiene que darte ese «local», o no lo es y entonces se llega por red.
Porque «local» es exactamente lo que el otro CVE del par regala. SonicWall describe el 10.0 con una expresión suya que conviene leer despacio: «Pre-authentication SSRF via unintended forward-proxy». Un proxy de reenvío no intencionado. Y la clasificación de esa ficha no se quedó en el CWE-918 de siempre: la propia SonicWall, como CNA, le asignó también el CWE-441 —y CISA lo replica en su entrada del KEV—, cuyo nombre oficial en MITRE es «Unintended Proxy or Intermediary (Confused Deputy)» — el producto recibe una petición y no preserva suficientemente el origen antes de reenviarla fuera de su esfera de control.
El nombre de ese CWE es la explicación de por qué el «local» del otro CVE no te cubre: la petición no nace en internet, nace dentro del propio aparato. El aparato es ese delegado confundido. Tu regla de «al AMC solo se llega desde la red de gestión» sigue siendo cierta y sigue sin servir, porque el que llama ya está dentro de la caja.
Que esto no es especulación nuestra lo respalda julio, que sí se documentó paso a paso. Rapid7, que descubrió aquel par, describió que el SSRF permitía «abrir un túnel basado en websocket hacia servicios que solo escuchan en localhost», llegar así al servicio interno ctrl-service en el puerto 8188, y desde ahí ejecutar comandos como root. Al segundo CVE de julio lo llamaron, en sus palabras, «a local privilege escalation». En julio el «local» ya era alcanzable; en septiembre es lo que dice la propia puntuación.
Lo que no afirmamos
- ✗No sabemos desde cuándo se explota el par de septiembre. SonicWall confirma explotación activa, pero no ha publicado fecha de inicio. Del de julio sí se supo después: Volexity situó el inicio el 22 de junio, 22 días antes del parche.
- ✗El encadenamiento de septiembre no está publicado paso a paso como el de julio. Que los dos se encadenan hasta ejecución sin autenticar lo dicen los analistas; el cómo exacto, todavía no. Nuestra lectura del
AV:Lse apoya en el CWE-441 y en el paralelismo con julio, y la marcamos como lectura, no como hecho del aviso. - ✗Que el KEV marque el par de julio como usado en campañas de ransomware y el de septiembre como «desconocido» no es una nota de gravedad. Es que aún no hay atribución. El de julio también empezó sin ella.
La pregunta cambia de sitio
Un fallo es un fallo. Dos veces la misma forma de fallo en 49 días —una puerta sin autenticar que reenvía peticiones, más una consola de administración que ejecuta— ya no es mala suerte: es la arquitectura del aparato diciéndote algo. Y a partir de ahí, la pregunta útil deja de ser «¿está parcheado?» y pasa a ser «¿hasta dónde llega esa caja cuando la controlan?».
La diferencia práctica entre las dos preguntas es que la primera la contesta el fabricante cada vez que publica un aviso, y la segunda la contestaste tú una vez, hace años, el día que montaste el concentrador — y no la has vuelto a mirar.
En las pymes que nos llegan, ese concentrador suele hacer dos trabajos que no son el mismo. Uno: que la gente que teletrabaja alcance las aplicaciones. Dos: que las delegaciones y algún proveedor alcancen el datacenter. Se juntaron en la misma caja porque nadie quería un segundo aparato, y es una decisión que en su día fue razonable. El problema es que el segundo trabajo no necesita un portal público, y sin embargo hereda toda la exposición del primero.
Separar el transporte entre sedes del acceso remoto de usuarios es la parte de esto que sí es de diseño y no de parcheo. Es lo que hacemos cuando montamos SD-WAN multi-sede: la conectividad entre delegaciones va por su propio camino, con política por sede, y no cuelga de que el portal de teletrabajo aguante el aviso de esta semana. Quien compromete el portal deja de heredar automáticamente las rutas a todas las sedes.
Y ahora la parte honesta, porque si no esto sería un folleto: el SD-WAN no arregla lo de SonicWall. No quita la necesidad de un portal de acceso remoto para usuarios, y el orquestador de un SD-WAN es un plano de gestión con exactamente la misma enfermedad — nosotros mismos lo escribimos en julio sobre el CVE del orquestador de VeloCloud. Cambiar de caja no cura nada. Lo único que cambia es cuántas cosas distintas cuelgan de una sola caja expuesta, que es una magnitud que sí controlas tú.
Si tienes un SMA 1000, por este orden
- 1Mira el número de build exacto, no la rama. Si pone
12.4.3-03453o12.5.0-02835, estás en la versión que julio dejó «al día» y septiembre declara afectada. Destino: 12.4.3-03526 o 12.5.0-02952. Modelos afectados: 6210, 7210 y 8200v. - 2Parchear cierra la puerta; no te dice si entró alguien. Son dos ventanas distintas y las dos hay que mirar: la de julio (desde el 22 de junio) y la de septiembre (fecha de inicio no publicada). El fabricante pide revisar indicadores de compromiso con su soporte, no darlo por bueno.
- 3Si hubo compromiso, el fabricante no dice «limpia». Dice re-imagen del hardware o re-despliegue del virtual, cambiar todas las contraseñas de usuario y de administrador y resetear los tokens TOTP. Ese último punto es el que más se salta la gente, y es el que decide si el atacante sigue pasando tu MFA mañana.
- 4Escribe la lista de lo que ese aparato alcanza. En papel. Si un SSRF lo convierte en proxy de reenvío, el daño máximo es esa lista. Casi nadie la tiene escrita, y es lo único que convierte un CVSS en una cifra tuya.
- 5Separa quién necesita portal de quién necesita ruta. El empleado que teletrabaja necesita portal. La delegación y el proveedor necesitan ruta con política, y eso no tiene por qué pasar por una web publicada en internet. Es trabajo de quitar confianza implícita, no de comprar otra caja.
Un apunte sobre el calendario, que es la parte que nadie cuenta: los dos avisos entraron en el KEV con tres días de plazo. Tres días para inventariar, coordinar una ventana, actualizar un equipo por el que entra todo el teletrabajo y además revisar indicadores. Dos veces en siete semanas. Eso no lo absorbe una persona que además tiene su trabajo; lo absorbe una guardia con procedimiento, que es exactamente para lo que existe el soporte 24×7. Y hoy, 7 de septiembre, el plazo del segundo aviso venció hace dos días.
En corto
No somos resellers de SonicWall ni de nadie, y este post no va de que cambies de marca: la caja siguiente tendrá sus propios avisos. Va de que un aparato que repite la misma forma de fallo en 49 días te está dando un dato de diseño, no una tarea de mantenimiento. El parche lo pone el fabricante cuando puede. El alcance —qué llega ese equipo a tocar el día que no es tuyo— lo pones tú, y es lo único de todo esto que no depende de la próxima build.
Fuentes (verificadas el 7-sep-2026): aviso SNWLID-2026-0016 de SonicWall (1-sep-2026), versiones afectadas y corregidas, «Pre-authentication SSRF via unintended forward-proxy» y pasos de remediación — sonicwall.com; vectores CVSS y CWE de CVE-2026-83548, CVE-2026-83549, CVE-2026-15409 y CVE-2026-15410 — NVD (fichas en estado Analyzed); fechas de alta y plazos del catálogo KEV de CISA (versión 2026.09.04); builds corregidas de julio y mecánica del túnel websocket, ctrl-service y puerto 8188 — Rapid7; fecha de inicio de explotación del par de julio (22-jun-2026, actor UTA0533) — Volexity, vía Cybersecurity Dive; definición de CWE-441 — MITRE.
¿Sabes hasta dónde llega tu concentrador de acceso remoto?
En everyWAN diseñamos y operamos la conectividad entre sedes y el acceso remoto como dos cosas distintas, con política por sede y sin que todo cuelgue de un portal publicado. Si tienes las dos cosas en la misma caja, te ayudamos a separarlas.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN