SonicWall: valide SAML e MFA depois da correção da SSLVPN
A política de MFA precisa acompanhar os caminhos de autenticação que o firewall realmente oferece. A CVE-2026-19868 pede verificar configuração, firmware e decisões de acesso em conjunto.
Read in EnglishPor Pentesty
Comece pelas condições exatas da falha
O aviso SNWLID-2026-0014, publicado em 6 de novembro de 2026, delimita a exposição: a CVE-2026-19868 afeta a interface ou serviço SSLVPN do SonicOS quando SAML está habilitado para esses logins. O atacante precisa de credenciais válidas para um método alternativo de autenticação. Nessas condições, pode contornar controles SAML e, possivelmente, o MFA imposto por esse caminho.
A SonicWall relata ter investigado uma indicação de possível exploração. Separadamente, a CISA incluiu a CVE no catálogo KEV em 6 de novembro, classificando-a como explorada. Isso justifica prioridade, sem identificar vítimas, autores ou uma campanha de ransomware. Esses dados não demonstram quando começaram os ataques nem que a exploração antecedeu a correção.
Relacione a versão à plataforma observada
A tabela do fabricante inclui os modelos Gen7 TZ, NSa e NSsp e os NSv 270, 470 e 870 nela listados, com SonicOS 7.3.3-7015 e anteriores. A correção indicada é 7.3.4-7013 ou posterior. Nos modelos Gen8 TZ e NSa e NSv XS, S, M e L relacionados no aviso, o intervalo afetado é 8.2.2-8015 e anteriores; a correção é 8.2.3-8015 ou posterior.
Confirme o modelo exato na tabela antes de escolher o pacote. Registre equipamento, geração, versão ativa e origem da evidência. Em ambientes com mais de uma instância atendendo usuários, confira cada membro. Uma captura da instalação em um equipamento não comprova que outro já executa a versão esperada.
Descreva a política antes de testar o acesso
Com os responsáveis pela VPN e pelo provedor de identidade, identifique os caminhos de login oferecidos e a decisão esperada em cada um. Relacione contas de teste, grupos autorizados, exigência de segundo fator e exceções aprovadas. Esse mapa permite avaliar uma credencial válida contra a política definida, em vez de tratar qualquer login bem-sucedido como resultado correto.
Por exemplo, quando a política exige SAML para o grupo remoto, o aceite deve registrar como esse requisito foi confirmado nos caminhos publicados para aquele grupo. Se o provedor registra autenticação, mas a decisão do firewall permanece sem explicação, mantenha a validação aberta. Confira o contexto da sessão com as equipes, sem exigir uma nova tela de MFA quando a política não a prevê.
Um teste autorizado deve observar o fluxo normal permitido e a recusa prevista pela política. Use contas e dados de teste, com limites combinados. Não utilize credenciais encontradas em vazamentos nem tente reproduzir ataques na operação. A finalidade é verificar a decisão de acesso depois da mudança.
Vincule a atualização a uma evidência de funcionamento
Combine a janela de manutenção, os contatos de suporte e o procedimento de recuperação antes de alterar a instalação. Depois da atualização, registre novamente versão ativa e configuração relevante. Execute os fluxos autorizados e associe o resultado ao equipamento, à conta de teste e ao horário, preservando o vínculo entre o estado anterior e o posterior. Registre também o fuso horário usado na coleta.
Quando disponíveis, relacione registros do firewall e do provedor de identidade. A presença ou ausência de uma tela de MFA não deve decidir o aceite sozinha: a equipe precisa verificar o resultado previsto para aquela sessão e política. Guarde apenas a evidência necessária, sem incluir senhas, tokens ou informações pessoais alheias ao teste.
Separe o aceite da investigação de atividade anterior
Aceitar a correção demonstra o estado observado e os fluxos examinados. Investigar acessos anteriores exige outra análise, com registros preservados e responsáveis definidos. Se faltarem dados, documente a lacuna. Uma divergência entre sistemas merece apuração; não confirma automaticamente comprometimento nem permite declarar que nenhuma atividade ocorreu.
Nossa análise de F5 APM e OAuth trata de outra falha e ajuda a organizar o aceite da autorização. Para ambientes redundantes, o caso NetScaler mostra como registrar a correção de cada membro. No SonicWall, encerre a mudança com um responsável, critérios atendidos e pendências visíveis.
Perguntas frequentes
A falha permite entrar sem nenhuma credencial?
Não é essa a condição descrita. O aviso exige credenciais válidas para um método alternativo e SAML habilitado para logins da SSLVPN.
Quais versões corrigidas devo conferir?
Para as plataformas listadas, o fabricante indica 7.3.4-7013 ou posterior na linha Gen7 e 8.2.3-8015 ou posterior na Gen8. Confira o modelo na tabela.
MFA habilitado no provedor elimina a exposição?
Essa configuração isolada não comprova o comportamento dos caminhos alternativos. Relacione a configuração aplicável, a atualização e a política de acesso verificada.
O patch comprova que não houve invasão?
Não. A verificação posterior cobre o estado e os fluxos examinados. Avaliar atividade anterior depende de evidências próprias e investigação.
Fontes e referências
- SonicWall: aviso SNWLID-2026-0014, de 6 de novembro de 2026
- SonicWall CNA: condições da CVE-2026-19868
- CISA: CVE-2026-19868 no catálogo de falhas exploradas
Análise original da Pentesty, publicada em 8 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.