Vulnerabilidad crítica en SonicWall SSL-VPN permite saltar autenticación multifactor

Introducción

En mayo de 2026, SonicWall publicó un aviso de seguridad que debería estar en la lista de prioridades de cualquier equipo de seguridad o DevOps que gestione VPNs corporativas. La vulnerabilidad CVE-2024-12802 afecta a los appliances SonicWall Gen6 SSL-VPN y permite a atacantes bypassear la autenticación multifactor (MFA) mediante un formato específico de nombre de usuario (UPN). Esto convierte a los dispositivos en una puerta trasera crítica, especialmente en entornos donde el acceso remoto es esencial.

El vector de ataque no requiere privilegios elevados ni acceso previo a la red interna. Un atacante externo podría explotar este fallo simplemente con credenciales válidas de un usuario legítimo, pero en un formato alterado que el sistema procesa incorrectamente. La explotación exitosa otorga acceso completo a la VPN sin necesidad de superar el segundo factor de autenticación, como tokens TOTP o soluciones como Duo Security.

Qué ocurrió

El 15 de mayo de 2026, SonicWall emitió un boletín de seguridad (SA-2026-05-15) donde detalló que CVE-2024-12802 —clasificada con un CVSS v3.1 de 8.8 (Alto)— permite a usuarios maliciosos autenticarse en el portal SSL-VPN utilizando un formato específico de UPN (User Principal Name). El problema reside en cómo el sistema procesa el nombre de usuario durante la fase de autenticación, sin validar correctamente el segundo factor cuando se usa este formato.

El exploit funciona de la siguiente manera:

1. El atacante obtiene credenciales válidas de un usuario (por ejemplo, mediante phishing o credenciales filtradas).
2. En lugar de usar el formato estándar [email protected], envía el nombre de usuario en el formato usuario%40dominio.com (el %40 es la codificación URL de @).
3. El sistema interpreta incorrectamente este formato como parte de la autenticación y salta el paso de MFA, permitiendo el acceso.

SonicWall confirmó que el fallo afecta a todas las versiones de firmware de los appliances Gen6 SSL-VPN anteriores a la 10.2.4.8-34o, incluyendo los modelos SMA 1000v, SMA 100v, y SMA 200v. La explotación no requiere acceso a la red interna, lo que amplía el riesgo a entornos con VPNs expuestas a Internet.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de Seguridad

Este fallo representa un riesgo crítico porque:

• El bypass de MFA anula una de las capas de seguridad más importantes en entornos remotos.
• No hay necesidad de escalada de privilegios: un atacante con credenciales válidas puede acceder directamente a la VPN.
• Afecta a múltiples modelos: Según datos de SonicWall, hay más de 50.000 appliances Gen6 SSL-VPN en producción a nivel global, muchos de ellos en sectores regulados como salud y finanzas.

El CVSS 8.8 refleja la criticidad, pero el impacto real es aún mayor si consideramos que:

• Los atacantes pueden moverse lateralmente una vez dentro de la VPN, accediendo a recursos internos.
• La explotación no deja huellas evidentes en logs estándar, lo que dificulta la detección.

Para equipos de DevOps e Infraestructura

Los equipos que gestionan VPNs corporativas deben considerar:

• Exposición directa a Internet: Muchos appliances SSL-VPN están configurados con puertos abiertos (443/TCP) para permitir acceso remoto.
• Falta de segmentación: La VPN a menudo es el único punto de entrada a la red interna, lo que convierte a este fallo en un punto único de fallo (SPOF).
• Compliance: En sectores como PCI-DSS o HIPAA, la MFA es obligatoria. La explotación de este fallo podría invalidar certificaciones de seguridad.

Para equipos de Cloud

Si tu infraestructura VPN está en la nube (por ejemplo, usando SonicWall SMA en AWS o Azure), el riesgo sigue siendo alto:

• El fallo es independiente del entorno: Funciona tanto en appliances físicos como virtuales (SMA 1000v).
• Las instancias en la nube pueden estar más expuestas: Si el appliance no está en una VPC/VNet segmentada, el riesgo de movimiento lateral aumenta.

Detalles técnicos

Componentes afectados

El exploit aprovecha un parsing incorrecto del UPN en la fase de autenticación. El flujo normal sería:

1. Usuario envía credenciales: [email protected] + token MFA.
2. Sistema valida usuario + token.
3. Si válido, otorga acceso.

Pero con el exploit:

1. Usuario envía: usuario%40dominio.com + (sin token MFA).
2. El sistema procesa %40 como parte del nombre de usuario y omite la validación del token MFA.
3. Acceso concedido.

Prueba de concepto (PoC)

SonicWall no publicó un PoC público, pero el exploit puede replicarse con:

curl -k -X POST "https://<VPN_IP>/auth.php" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "username=usuario%40dominio.com&password=Clave123!&realm=ldap"

Si el appliance está vulnerable, la respuesta incluirá una cookie de sesión válida sin requerir MFA.

Contexto de explotación

• CVE-2024-12802 fue reportada a SonicWall en marzo de 2026 por investigadores de Secureworks.
• El fallo está relacionado con un buffer overflow en el parser de UPN (CWE-125), pero no requiere ejecución de código arbitrario.
• No hay evidencia pública de explotación masiva hasta mayo de 2026, pero el patrón es consistente con ataques a VPNs (ej: CVE-2023-46747 en Fortinet).

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar el firmware inmediatamente

SonicWall publicó el parche en la versión 10.2.4.8-34o. Los pasos son:

# Para appliances físicos (ej: SMA 1000v)
ssh admin@<appliance_IP>
update firmware url https://update.sonicwall.com/10.2.4.8-34o.bin

# Para instancias en la nube (AWS/Azure)
- Descargar la imagen desde SonicWall Update Center.
- Subirla como nueva AMI (AWS) o VHD (Azure).
- Reiniciar la instancia.

show system firmware version

Si muestra < 10.2.4.8-34o, aplicar el parche.

2. Auditar configuraciones de MFA

• Deshabilitar el formato alternativo de UPN si está habilitado (algunas configuraciones permiten usuario%40dominio.com).
• Revisar logs de autenticación en busca de intentos con %40 en el nombre de usuario. Ejemplo de búsqueda en Splunk:

index=security sourcetype="sonicwall:vpn" username="*%40*"

3. Segmentar la VPN

• No exponer el puerto 443/TCP directamente a Internet. Usar:

– AWS API Gateway + Lambda para autenticación previa.

• Restringir el acceso VPN solo a subredes corporativas (ej: VPN solo desde oficinas o VPN a VPN).

4. Monitoreo y detección

Implementar reglas en SIEM para detectar:

# Ejemplo para Sigma (SigmaHQ)
title: SonicWall SSL-VPN Bypass MFA Attempt
logsource:
  category: vpn
  product: sonicwall
detection:
  selection:
    username|contains: '%40'
    event_id: 'auth_failed'
  condition: selection

• Alertar en tiempo real si se detectan múltiples intentos de autenticación fallidos con este patrón.

5. Plan de respuesta a incidentes

Si sospechas que tu appliance ya fue explotado:

1. Aislar el dispositivo: Desconectarlo de la red interna.
2. Revisar logs: Buscar accesos con IPs desconocidas o horarios anómalos.
3. Forzar cambio de credenciales: Todos los usuarios que hayan accedido desde la fecha del exploit.
4. Revisar sistemas internos: Buscar movimientos laterales (ej: conexiones a servidores LDAP, bases de datos).

Conclusión

CVE-2024-12802 es un recordatorio de que los fallos en autenticación pueden ser más críticos que los de ejecución de código. En este caso, un simple error de parsing de un carácter (@) permite saltarse la MFA, la capa de seguridad más importante en entornos remotos. La explotación no requiere habilidades avanzadas, solo conocimiento del formato de UPN y credenciales válidas.

Para los equipos de DevOps y Seguridad, la prioridad es actualizar el firmware hoy mismo y revisar las configuraciones de MFA. Para los equipos de Infraestructura, segmentar la VPN y monitorear logs en busca de intentos de explotación. La ventana de ataque es pequeña si actúas rápido, pero el impacto de un bypass de MFA en producción puede ser devastador.

Si tu organización depende de SonicWall Gen6 SSL-VPN, este no es un fallo más: es una emergencia de seguridad. La actualización no puede esperar.