Análisis a fondo

Omisión de SAML en el SSLVPN de SonicWall, explotada en entornos reales (CVE-2026-19868)

Una falla del SSLVPN de SonicOS permite a una cuenta con credenciales de otro método omitir SAML y su MFA; explotada, corregida en 7.3.4-7013 y 8.2.3-8015.

Ostorlab Team 7 de noviembre de 2026

Resumen

Una falla del SSLVPN de SonicOS permite a una cuenta con credenciales válidas para otro método omitir la política SAML y su autenticación multifactor (MFA). SonicWall publicó CVE-2026-19868 el 6 de noviembre de 2026.
Los firewalls Gen7 en 7.3.3-7015 o anteriores y los Gen8 en 8.2.2-8015 o anteriores se ven afectados cuando SAML está habilitado para los inicios de sesión del SSLVPN. Las versiones corregidas son 7.3.4-7013 y 8.2.3-8015.
SonicWall la califica CVSS v3.1 7.1 High; el ADP de CISA, 7.5. Investigó un informe de explotación potencial. CISA la añadió al catálogo Known Exploited Vulnerabilities (KEV) el 6 de noviembre de 2026. El plazo es el 20 de noviembre de 2026.
Actualice a 7.3.4-7013 o 8.2.3-8015; SonicWall no enumera ningún workaround. Mientras tanto, revise qué cuentas pueden autenticarse en el SSLVPN por un método distinto de SAML, como explica «¿Cómo lo corrijo?».

¿Estoy afectado?

Debe cumplirse todo lo siguiente para estar expuesto a CVE-2026-19868:

El firewall ejecuta SonicOS Gen7 en 7.3.3-7015 o anterior, o Gen8 en 8.2.2-8015 o anterior.
El servicio SSLVPN está habilitado y es accesible desde la red donde opera el atacante.
SAML está habilitado para los inicios de sesión del SSLVPN. SonicWall afirma que la falla «ONLY impacts the SonicOS SSLVPN interface or service if SAML is enabled for SSLVPN logins».
Al menos una cuenta puede autenticarse mediante un método alternativo. El atacante necesita credenciales válidas para esa cuenta, como indica el aviso.

El aviso cubre dos líneas de plataforma y una larga lista de modelos.

Hardware Gen7: TZ 270, 370, 470, 570 y 670; NSa 2700 a 6700; NSsp 10700 a 15700.
NSv Gen7: NSv 270, 470 y 870.
Hardware Gen8: TZ 80, 280, 380, 480, 580 y 680; NSa 2800 a 5800.
NSv Gen8: NSv XS, S, M y L.

Plataforma	Versiones afectadas	Versión corregida
Hardware y NSv SonicOS Gen7	7.3.3-7015 y anteriores	7.3.4-7013 y posteriores
Hardware y NSv SonicOS Gen8	8.2.2-8015 y anteriores	8.2.3-8015 y posteriores

El aviso también corrige otras seis fallas de SonicOS en las mismas versiones. Esta entrada trata de CVE-2026-19868, la única de las siete que CISA añadió al catálogo KEV.

La falla explotada no es la de mayor puntuación de su propio aviso. Dos fallas de la interfaz de gestión tienen 8.8 y el desbordamiento de heap del SSLVPN tiene 7.5. La inclusión en KEV, no la puntuación, es lo que la hace urgente.

La falla SSLVPN explotada puntúa 7.1, por debajo de dos fallas de la interfaz de gestión con 8.8 y de un desbordamiento SSLVPN con 7.5 en el mismo aviso — Figura 1: puntuaciones CVSS v3.1 de las siete fallas de SonicOS corregidas en SNWLID-2026-0014, con CVE-2026-19868 resaltada. Fuente: aviso de SonicWall SNWLID-2026-0014, verificado el 7 de noviembre de 2026

Compruebe primero el firmware en ejecución. En la línea de comandos de SonicOS, show version imprime la cadena de versión. En la interfaz web, System > Status muestra la misma cadena. La versión debe compararse con la versión corregida de la línea de plataforma, no con la última versión publicada en general.

Después revise la configuración del SSLVPN. En los ajustes de autenticación del SSLVPN, confirme si SAML está habilitado para los inicios de sesión VPN. Si no lo está, esta CVE no se aplica a esa configuración, incluso en una versión afectada. Las otras seis fallas del aviso tienen sus propias condiciones, así que la actualización sigue estando justificada.

Por último, enumere las cuentas y los métodos de autenticación que acepta el SSLVPN. El aviso no indica qué métodos alternativos alcanzan la falla. Trate todo método habilitado distinto de SAML como una vía posible, y toda cuenta que pueda usarlo como una fuente posible de credenciales válidas.

¿Cómo lo corrijo?

Haga una copia de seguridad de la configuración del firewall y anote la versión actual del firmware, para poder revertir la actualización.
Descargue la versión corregida de la línea de plataforma desde MySonicWall: 7.3.4-7013 o posterior para Gen7, y 8.2.3-8015 o posterior para Gen8. SonicWall publica las plataformas y versiones corregidas en la tabla Fixed Software del aviso.
Instale el firmware en cada firewall y confirme la nueva versión tras el reinicio. Para un dispositivo virtual NSv, actualícelo o vuelva a desplegarlo con la misma versión corregida.
Confirme que el SSLVPN sigue usando SAML para las cuentas que deben usarlo, y que no queda habilitado ningún método alternativo no previsto.

La misma actualización corrige seis fallas compañeras en SNWLID-2026-0014.

Dos fallas de la interfaz de gestión con 8.8, CVE-2026-107155 y CVE-2026-107154.
Un desbordamiento de heap antes de la autenticación en el servicio SSL-VPN con 7.5, CVE-2026-82308.
Dos desbordamientos antes de la autenticación en el cliente TACACS+ con 5.9, CVE-2026-77708 y CVE-2026-77709.
Una falla de hash de contraseña débil en los dispositivos virtuales con 5.2, CVE-2026-19703.

Solo CVE-2026-19868 tiene un informe de explotación y una entrada en KEV.

SonicWall no enumera ningún workaround. Los pasos de esta sección reducen la exposición hasta la actualización, pero no corrigen la falla de aplicación de la autenticación.

Elimine o deshabilite las cuentas del SSLVPN que pueden autenticarse por un método distinto de SAML. Esto retira el acceso VPN de esos usuarios, así que mantenga una vía administrativa que no dependa del SSLVPN.
Limite el SSLVPN a direcciones de origen que usted controle, como un rango de salida corporativo o una red de gestión. Esto reduce la población que puede alcanzar la página de inicio de sesión, pero la falla sigue siendo accesible desde cualquier dirección permitida.
Revise los registros de autenticación del SSLVPN en busca de inicios de sesión correctos que hayan usado un método distinto de SAML. Un inicio de sesión para una cuenta que debía usar SAML es una pista, no una prueba de compromiso.

Ninguno de estos pasos sustituye a la versión corregida. La remediación del proveedor es la actualización del firmware.

¿Cuál es la causa raíz?

La puerta de enlace SSLVPN no aplica la política SAML a una cuenta que puede autenticarse mediante otro método. Ese inicio de sesión se completa sin la aserción SAML. También omite la autenticación multifactor que SAML aplica.

SonicOS puede autenticar a los usuarios del SSLVPN mediante más de un método. Un administrador que habilita SAML espera que la puerta de enlace exija el flujo SAML y la autenticación multifactor del proveedor de identidad en cada inicio de sesión VPN. La falla está en esa aplicación.

Cuando una cuenta presenta credenciales válidas para un método alternativo, la puerta de enlace acepta ese método como suficiente. La comprobación SAML no se aplica, así que el inicio de sesión continúa solo con el método alternativo.

SonicWall asigna CWE-308, Use of Single-Factor Authentication, a la falla. Esa debilidad describe el resultado más que una línea de código. Un solo factor basta para la puerta de enlace: la credencial del método alternativo. Eso es suficiente aunque el administrador haya configurado SAML y su autenticación multifactor. El alcance de CVSS cambia, porque la omisión cruza el límite de autenticación que configuró el administrador.

SonicWall no publica código fuente ni un diff del parche para SonicOS. El aviso nombra la condición previa, las versiones afectadas y el impacto. No nombra la ruta del código, el método alternativo ni la secuencia de peticiones.

La rama exacta del código de autenticación no puede reconstruirse con información pública.

Lo que sí es público es el límite de la falla. SAML debe estar habilitado para los inicios de sesión del SSLVPN, y el atacante debe tener credenciales válidas para un método alternativo.

¿Cómo se explota?

El ataque convierte una contraseña válida para un método alternativo en una sesión VPN que nunca satisface la política SAML ni su autenticación multifactor. El aviso describe el mecanismo pero no publica ninguna secuencia de peticiones, así que los pasos de esta lista siguen su redacción y el registro CVE:

El atacante encuentra un SSLVPN SonicOS expuesto a Internet con SAML habilitado para los inicios de sesión VPN.
El atacante tiene credenciales válidas para una cuenta que puede autenticarse mediante un método alternativo. El aviso no indica qué métodos se aceptan en una configuración vulnerable.
El atacante se autentica en el SSLVPN mediante ese método alternativo en lugar del flujo SAML.
La puerta de enlace acepta el inicio de sesión sin exigir la aserción SAML. La autenticación multifactor aplicada por SAML no se ejecuta, porque la sesión nunca llega al paso SAML.
El atacante recibe una sesión VPN con los permisos de la cuenta y puede alcanzar los recursos internos que esa cuenta tiene autorizados.
La sesión se usa como cualquier otra sesión VPN, con el mismo registro y los mismos controles de acceso que se aplican a esa cuenta.

Es una omisión de la autenticación multifactor para una contraseña robada, reutilizada u obtenida de otro modo. No es una entrada no autenticada en el firewall. El atacante sigue necesitando una credencial válida para una cuenta que pueda usar un método alternativo. Esa distinción importa al evaluar la exposición: la población en riesgo es toda cuenta que pueda omitir la política SAML, no todo usuario de Internet.

CISA añadió la CVE a KEV el 6 de noviembre de 2026, lo que registra explotación activa. SonicWall dice que investigó un informe que indicaba explotación potencial. Ninguna de las dos fuentes nombra una víctima, una fecha, un actor ni una dirección de origen. No hay prueba de concepto ni secuencia de peticiones pública, así que estos pasos no pueden reproducirse solo con información pública.

¿Cómo se desarrolla el ataque?

Una contraseña válida para un método alternativo llega al SSLVPN. La puerta de enlace omite entonces la política SAML y su autenticación multifactor, y el atacante obtiene una sesión VPN con el acceso de esa cuenta.

flowchart LR A["El atacante tiene una contraseña válida
para un método alternativo"] --> B["SSLVPN SonicOS expuesto a Internet
con SAML habilitado"] B --> C["Inicio de sesión completado por el
método alternativo"] C --> D["Política SAML y autenticación
multifactor SAML no aplicadas"] D --> E["Sesión VPN como la cuenta"] E --> F["Recursos internos que
la cuenta puede alcanzar"]

¿Qué puede hacer un atacante?

El atacante obtiene una sesión VPN como la cuenta cuyas credenciales de método alternativo se usaron, con los permisos de esa cuenta. El impacto directo es el acceso a las redes y servicios internos que la cuenta tiene autorizados.

SonicWall califica CVE-2026-19868 como CVSS v3.1 7.1 High, CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N. El bloque ADP de CISA lleva 7.5, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N. Los dos vectores difieren en los privilegios requeridos: el proveedor supone una cuenta válida y el bloque ADP de CISA no. Ambos registran impacto alto en confidencialidad, bajo en integridad y nulo en disponibilidad. Eso corresponde a un punto de apoyo VPN orientado a lectura, no a una falla de ejecución de código.

Todas las condiciones de «¿Estoy afectado?» se aplican por completo:

El firewall es una versión Gen7 o Gen8 afectada.
El SSLVPN es accesible desde la red del atacante.
SAML está habilitado para los inicios de sesión del SSLVPN.
El atacante tiene credenciales válidas para una cuenta que puede autenticarse mediante un método alternativo.

El aviso no describe ninguna forma de superar la autorización VPN de la cuenta mediante esta falla. Una cuenta con pocos privilegios da un túnel con pocos privilegios; una cuenta privilegiada o con amplia autorización da mucho más. El aviso no describe creación de cuentas, ejecución de código ni escalada de privilegios en el firewall, y el registro CVE tampoco.

Considere esos impactos fuera del alcance de esta CVE, no como demostrados.

La exposición es mayor donde el SSLVPN es el límite de autenticación multifactor para una plantilla. Cualquier contraseña que la autenticación multifactor de SAML habría bloqueado basta entonces para abrir una sesión VPN. Ese es el escenario que la inclusión en KEV hace urgente, y por eso la versión corregida, y no una regla de detección, es el control principal.

¿Por qué funciona la corrección?

Las versiones corregidas cierran la brecha de aplicación. Un inicio de sesión mediante un método alternativo ya no puede satisfacer el SSLVPN cuando SAML está configurado para los inicios de sesión VPN. SonicWall no publica el cambio de código ni un diff del parche. La exhaustividad de la corrección depende de la declaración del proveedor de que 7.3.4-7013 y 8.2.3-8015 lo contienen.

El aviso enumera las mismas versiones corregidas para todo el lote de siete CVE, y no enumera ningún workaround. Eso hace de la actualización la única remediación admitida por el proveedor. Los pasos operativos de «¿Cómo lo corrijo?» reducen quién puede alcanzar la vía alternativa, pero dejan la falla de aplicación en su sitio.

Si opera un dispositivo virtual, confirme que la imagen NSv se reconstruye o se actualiza a la versión corregida. Una copia de seguridad de la configuración restaurada sobre una imagen antigua reintroduce la falla.

¿Cómo compruebo si estuve comprometido?

SonicWall no ha publicado indicadores de compromiso, un número de víctimas ni una firma de petición. Las comprobaciones de esta sección buscan el efecto de la falla, no una carga útil conocida.

Empiece por los registros de autenticación del SSLVPN en el firewall o en el colector syslog. Busque inicios de sesión correctos de cuentas que deberían usar SAML. Compare el método de autenticación registrado para cada inicio de sesión con el método que la cuenta debería usar. Un inicio de sesión correcto para una cuenta exclusiva de SAML que registra cualquier otro método es el patrón que produciría esta falla.

Después revise qué hizo la sesión. Compare las direcciones de origen y las horas de esos inicios de sesión con el patrón habitual de la cuenta. Busque hosts o servicios internos que la cuenta no suele alcanzar, y sesiones que empezaron fuera del horario o del país del titular de la cuenta.

Revise el inventario de cuentas en busca de cambios del mismo periodo. Las cuentas locales nuevas, los métodos de autenticación alternativos habilitados recientemente y las nuevas autorizaciones del SSLVPN merecen investigación.

La entrada en KEV enlaza los requisitos de análisis forense de CISA bajo la Directiva Operativa Vinculante 26-04. Esa guía es la referencia para las pruebas que hay que conservar, aunque usted no sea una agencia federal.

Un intento fallido no deja un rastro especial. Un inicio de sesión correcto puede parecer normal en un registro que no guarda el método de autenticación. Si no puede descartar un inicio de sesión, trate la cuenta como comprometida. Restablezca sus credenciales y revise a qué podía acceder. Reconstruya el firewall desde una configuración confiable si el propio dispositivo es sospechoso.

Cronología

2026-11-06: SonicWall publica SNWLID-2026-0014 y CVE-2026-19868. El aviso dice que el PSIRT de SonicWall investigó un informe que indicaba explotación potencial.
2026-11-06: CISA añade CVE-2026-19868 al catálogo Known Exploited Vulnerabilities, con una fecha límite federal del 20 de noviembre de 2026.
2026-11-20: fecha límite federal de remediación para CVE-2026-19868.

Preguntas frecuentes

¿Afecta a los dispositivos SonicWall SMA1000?

No. CVE-2026-19868 es una falla de SonicOS en las líneas de firewalls Gen7 y Gen8 y en los NSv. El SMA1000 es una línea de acceso remoto distinta, y sus problemas de 2026 tienen sus propios avisos y correcciones. Un parque SonicWall puede contener ambos, así que revise cada producto con su propio aviso, no con esta tabla de versiones.

¿Puede un atacante explotarla sin ninguna credencial?

No. El aviso exige credenciales válidas para un método de autenticación alternativo. La falla elimina el paso SAML y multifactor para esa cuenta; no elimina el paso de la contraseña. Un usuario de Internet sin cuenta en el firewall ni en sus fuentes de identidad no puede usar esta vía.

¿Es explotable cuando SAML no está habilitado?

No. SonicWall limita la falla a los servicios SSLVPN donde SAML está habilitado para los inicios de sesión VPN. Eso no hace inofensivas las otras seis fallas del aviso, y una versión afectada debe actualizarse igualmente.

¿Hay un workaround si no puedo actualizar hoy?

SonicWall no enumera ninguno. Retirar las cuentas con método alternativo del SSLVPN y restringir el servicio a direcciones de origen de confianza reduce la exposición, pero no corrige la brecha de aplicación. El firmware corregido es la remediación.

¿CVE-2026-19868 está en el catálogo KEV de CISA?

Sí. CISA la añadió el 6 de noviembre de 2026 con una fecha límite federal del 20 de noviembre de 2026. Esa inclusión registra explotación activa, y es la razón por la que esta entrada empieza por la actualización y no por la detección.

¿Qué pasa con las otras seis CVE del mismo aviso?

Están corregidas en las mismas versiones.

Dos fallas de la interfaz de gestión tienen 8.8.
El desbordamiento de heap del SSL-VPN tiene 7.5.
Los dos desbordamientos de TACACS+ tienen 5.9 cada uno.
La falla de hash de contraseña débil tiene 5.2.