Em 22 de setembro de 2026, a Arista Networks emitiu um alerta e disponibilizou correções para a CVE-2026-93952, que afeta implementações locais do VeloCloud Orchestrator e estava sendo explorada ativamente. A falha permite acesso remoto não autenticado a funções privilegiadas do host quando a autenticação baseada em certificado está configurada entre o VeloCloud Edge e o orquestrador. O ponto que exige atenção é direto: o ataque não precisa de credenciais de operador ou administrador para avançar. A seguir, a análise separa a condição técnica, o alcance indicado pelas pontuações de risco e as medidas práticas informadas pelo fabricante.
O que a falha permite no VeloCloud Orchestrator
A primeira peça da investigação está na forma como o produto valida os dados recebidos. A vulnerabilidade deriva de uma validação inadequada de entrada, expressão que descreve a incapacidade de verificar corretamente uma informação antes de processá-la. A condição afeta instalações locais do VeloCloud Orchestrator nas quais existe autenticação por certificado entre o VeloCloud Edge e o orquestrador. Se essa configuração estiver presente, então a exploração pode alcançar funcionalidades internas privilegiadas sem que o invasor apresente uma conta de operador ou administrador.
A segunda peça é a combinação entre privilégio e ausência de credenciais. Segundo o comunicado da Arista, invasores remotos conseguem acessar funções internas privilegiadas do VCO, enquanto o alerta sobre a exploração confirma que ataques bem-sucedidos não exigem credenciais administrativas. Isso não significa que qualquer conexão aleatória seja suficiente: a análise publicada pela The Hacker News informa que a exploração requer acesso à interface web e ao certificado público do VeloCloud Edge. Em termos forenses, a conclusão é simples: não há autenticação de operador ou administrador, mas há pré-condições técnicas que precisam ser verificadas na exposição real do serviço.
Por que as pontuações indicam risco elevado
Essa combinação aparece nas avaliações de risco publicadas para a CVE-2026-93952. A National Vulnerability Database atribuiu pontuação base CVSS 4.0 de 9,5, classificada como crítica; o CVSS é uma escala usada para expressar a gravidade e o impacto potencial de uma vulnerabilidade. O vetor registrado inclui acesso pela rede, ausência de privilégios exigidos e impactos altos sobre confidencialidade, integridade e disponibilidade do host e de sistemas relacionados. Se a pergunta é se o problema afeta apenas a leitura de informações, a resposta documentada pela avaliação é negativa: os três pilares de segurança aparecem com impacto alto.
Essa leitura convive com outra pontuação divulgada pela fabricante. A Arista atribuiu à falha um CVSS 3.1 de 10,0, enquanto o registro da NVD utiliza a versão 4.0 e chega a 9,5. Os números não devem ser comparados como se viessem da mesma edição da escala, mas ambos colocam a vulnerabilidade no nível mais alto de atenção. A diferença de pontuação não reduz a urgência, porque a exploração ativa e o acesso a funções privilegiadas são fatos independentes da versão usada para calcular o índice.
A urgência ganhou uma confirmação institucional em 22 de setembro de 2026, quando a CISA incluiu a CVE-2026-93952 em seu catálogo de vulnerabilidades conhecidamente exploradas. Esse catálogo reúne falhas para as quais há registro de exploração e serve de referência para priorização de correções por órgãos federais dos Estados Unidos. A medida não acrescenta uma nova técnica de ataque ao caso, mas elimina qualquer leitura de que o risco seria apenas teórico ou baseado em uma possibilidade futura. Quando uma vulnerabilidade entra nessa relação, a discussão deixa de ser quando atualizar e passa a ser como concluir a atualização dentro do prazo.
Esse prazo foi definido para 25 de setembro de 2026, data até a qual as agências federais americanas deveriam priorizar a mitigação conforme a diretiva federal 26-04. O alerta da CISA registrou a CVE da Arista junto de outras vulnerabilidades adicionadas ao catálogo na mesma atualização. Para administradores fora do governo federal, a data não funciona automaticamente como uma obrigação jurídica, mas oferece uma referência objetiva para medir a urgência operacional. Se uma agência com processos formais de resposta precisa tratar a falha em poucos dias, então ambientes locais expostos devem evitar a estratégia de deixar a correção para a próxima janela indefinida.
Quais versões estão afetadas e quais correções existem
Depois de estabelecer o impacto, a verificação precisa começar pela versão instalada. O advisory da Arista lista como afetadas as linhas 5.2.x até a versão 5.2.3.15 e 6.1.x até a versão 6.1.3.7. A comparação deve considerar o número completo, porque estar na mesma linha de versão não significa estar protegido: o limite informado pelo fabricante é específico. O próximo passo é confrontar essa informação com as versões corrigidas disponibilizadas para o produto.
Na mesma relação, aparecem as linhas 6.4.x até 6.4.2.7 e 7.0.x até 7.0.0.2. A Arista disponibilizou patches, isto é, atualizações de correção, para as versões 5.2.3.16 ou posteriores e 6.4.2.8 ou posteriores. O advisory também informa que as versões hospedadas e dedicadas já foram corrigidas pela empresa. Como as faixas afetadas e as versões corrigidas não cobrem todos os números da mesma forma no material divulgado, o administrador deve conferir a orientação correspondente à sua linha antes de concluir que uma atualização parcial resolveu o problema.
Como verificar uma possível exploração
Com a versão identificada, a investigação deve avançar para os registros de acesso. A Arista orientou a busca por atividade suspeita e divulgou como indicadores de comprometimento os endereços IP 142.93.149.77 e 104.248.126.159, além de cabeçalhos HTTP específicos nos logs. Indicadores de comprometimento são sinais que ajudam a comparar o histórico do ambiente com padrões associados a uma intrusão, portanto a consulta não deve ficar limitada ao momento em que o patch foi aplicado. Se esses endereços ou cabeçalhos aparecerem em acessos compatíveis com a interface do produto, a recomendação divulgada inclui bloquear os IPs e aprofundar a análise.
Por fim, a sequência prática combina três verificações: confirmar se a instalação é local, identificar a versão exata e descobrir se a autenticação baseada em certificado entre o VeloCloud Edge e o orquestrador está habilitada. Em seguida, o administrador deve aplicar a correção compatível, revisar os logs em busca dos indicadores de comprometimento e bloquear os endereços informados quando houver atividade suspeita. Para as agências federais dos Estados Unidos, o marco documentado pela CISA foi 25 de setembro de 2026; para os demais ambientes, a confirmação de exploração ativa torna a atualização uma tarefa imediata, não uma manutenção para uma data indefinida.