CISA confirma exploração ativa de sete falhas em software e infraestrutura

Sete vulnerabilidades passaram esta semana de risco conhecido para prioridade operacional. A CISA, a agência norte-americana de cibersegurança, adicionou a 2 de setembro sete CVEs ao catálogo Known Exploited Vulnerabilities, ou KEV.

São sete falhas, mas apenas seis produtos: Sangoma Switchvox, Starlette, Kestra OSS, LiteLLM, JFrog Artifactory e SonicWall SMA1000. O equipamento da SonicWall aparece duas vezes, com vulnerabilidades diferentes.

A seleção atravessa várias camadas da infraestrutura moderna, desde o acesso remoto e as comunicações empresariais até ferramentas utilizadas no desenvolvimento e operação de aplicações.

O que a CISA confirmou

Entrar no KEV não significa simplesmente que uma vulnerabilidade tem uma pontuação CVSS elevada ou que existe um exploit tecnicamente possível.

Significa que a CISA dispõe de evidência de exploração conhecida da vulnerabilidade.

Esta distinção é importante. Severidade, possibilidade técnica de exploração e exploração observada no mundo real são conceitos diferentes.

Uma vulnerabilidade pode ter uma classificação elevada sem existir evidência conhecida de exploração. Outra pode ter uma classificação inferior e, ainda assim, justificar prioridade operacional porque já está a ser explorada.

Porque o catálogo KEV importa

O catálogo KEV não reúne todas as vulnerabilidades conhecidas.

É uma lista mantida pela CISA para identificar falhas cuja exploração já foi observada e ajudar as organizações a dar prioridade às correções.

Para as agências federais civis norte-americanas abrangidas pelas diretivas da CISA, a inclusão no catálogo está associada a prazos concretos para mitigação.

Esses prazos não constituem uma obrigação automática para todas as empresas ou organizações fora do governo federal norte-americano.

Ainda assim, o KEV tornou-se uma referência útil para equipas de segurança porque acrescenta um sinal importante ao CVSS: não apenas o que uma vulnerabilidade pode permitir, mas se existem indícios de que está efetivamente a ser explorada.

Sete falhas, várias camadas

As sete vulnerabilidades afetam tipos muito diferentes de tecnologia.

No acesso e perímetro estão duas falhas no SonicWall SMA1000: a CVE-2026-83548, associada a Server-Side Request Forgery, ou SSRF, e a CVE-2026-83549, uma vulnerabilidade de injeção de comandos no sistema operativo.

Nas comunicações empresariais surge o Sangoma Switchvox, afetado pela CVE-2026-9586, uma vulnerabilidade de injeção SQL.

Na cadeia de desenvolvimento aparece o JFrog Artifactory. A CVE-2026-82329 está associada a autenticação inadequada numa ferramenta utilizada para armazenar e gerir artefactos e pacotes de software.

Outra camada é a orquestração.

O Kestra OSS permite construir e executar workflows e tarefas. A CVE-2026-49869 envolve injeção de comandos no sistema operativo.

No LiteLLM, utilizado como gateway entre aplicações e diferentes modelos e serviços de IA, a CVE-2026-59822 está associada a autenticação inadequada.

Por fim, a CVE-2026-48710 afeta a Starlette, uma framework web em Python, através de uma vulnerabilidade de HTTP request/response smuggling.

A ligação à infraestrutura de IA

Nem todas estas vulnerabilidades são específicas de inteligência artificial. A relevância para este contexto resulta da presença de componentes que podem integrar cadeias de software usadas para desenvolver, distribuir ou operar aplicações modernas, incluindo sistemas de IA.

O LiteLLM é o exemplo mais direto desta ligação porque funciona como uma camada intermédia entre aplicações e diferentes modelos ou serviços de inteligência artificial.

Mas a questão é mais ampla.

Um sistema moderno pode depender simultaneamente de frameworks web, gateways, orquestradores, repositórios de software, serviços de autenticação e infraestrutura de rede.

Ferramentas como Kestra, Artifactory ou Starlette podem fazer parte dessa cadeia sem serem, por si próprias, produtos de inteligência artificial.

Por isso, estas sete vulnerabilidades não demonstram que “a IA está sob ataque”. Mostram que a superfície que precisa de ser protegida é muito maior do que o modelo ou a aplicação visível ao utilizador.

Infográfico

O que fazer agora

O primeiro passo é verificar se algum dos seis produtos afetados está presente na infraestrutura da organização e confirmar exatamente a versão e configuração em utilização.

Depois, devem ser consultados os avisos oficiais dos respetivos fornecedores e projetos para identificar a versão corrigida, mitigação recomendada e eventuais condições específicas de exploração.

A entrada de uma vulnerabilidade no KEV aumenta a prioridade dessa verificação precisamente porque existe evidência de exploração conhecida.

Também é importante procurar novas atualizações dos fornecedores. Informações sobre versões afetadas, indicadores de compromisso ou medidas adicionais podem mudar à medida que a investigação avança.