O equipamento cuja função é detonar malware

Uma sandbox existe para ser atacada. Compra-se o FortiSandbox para que os ficheiros suspeitos sejam abertos num sítio que não é a sua rede, observados enquanto se portam mal e depois julgados. Por desenho, fica exatamente no ponto onde chega aquilo em que não se confia. É isso que faz de uma injeção de comandos sem autenticação na sua interface web um problema de categoria diferente da mesma falha num servidor comum.

A CVE-2026-25089 é precisamente isso. Afeta a interface web do FortiSandbox, do FortiSandbox Cloud e do FortiSandbox PaaS e permite que um atacante não autenticado execute comandos não autorizados através de pedidos HTTP especificamente construídos. Tem uma pontuação CVSS de 9.1. A Fortinet divulgou-a e corrigiu-a a 9 de junho de 2026.

Em meados de junho começou a exploração, em meados de julho o catálogo deu por ela

A exploração de três falhas do FortiSandbox foi observada no terreno ao longo do fim de semana de sensivelmente 14 a 16 de junho, e o acompanhamento independente registou exploração da CVE-2026-39808 logo a 12 de junho. A imprensa especializada noticiou-o na altura: a Help Net Security a 16 de junho, a Qualys no dia seguinte, a par da cobertura do The Hacker News e da SecurityWeek. Duas das três, a CVE-2026-39808 e a CVE-2026-39813, já tinham sido divulgadas pela Fortinet em abril. A terceira, a CVE-2026-25089, tinha sido corrigida a 9 de junho, dias antes de os ataques começarem.

A 16 de julho de 2026, a CISA publicou a versão 2026.07.16 do catálogo e acrescentou três entradas. Duas delas são as falhas do FortiSandbox, a CVE-2026-25089 e a CVE-2026-39808. A terceira é uma falha de desserialização do Microsoft SharePoint, a CVE-2026-58644.

Conte os dias. Exploração confirmada, noticiada publicamente e real, em meados de junho. Entrada no catálogo federal a 16 de julho. Cerca de trinta dias separam as duas coisas, num equipamento alcançável a partir da internet com uma falha de execução remota de código sem autenticação, e durante esses trinta dias a informação não era secreta. Estava nos avisos do fabricante e na imprensa especializada.

A terceira continua a faltar

Naquela vaga de junho foram reportadas três CVE do FortiSandbox como exploradas. Duas foram catalogadas a 16 de julho. A CVE-2026-39813, uma falha de travessia de caminhos na API JRPC do FortiSandbox que pode ser usada para contornar a autenticação, não está no catálogo.

É esta a parte que deveria mudar a forma como o catálogo é usado, e não apenas a rapidez. Uma entrada no KEV é um sinal positivo forte: o que lá está, está a ser explorado e há que agir. A ausência de uma entrada é um sinal muito mais fraco do que a maioria dos programas de correção assume. A CVE-2026-39813 foi reportada como explorada ao lado das duas que ficaram listadas, na mesma vaga, na mesma família de produto, e não chegou ao catálogo. Uma organização que corrige o que a CISA lista e adia o que a CISA não lista acaba de adiar uma falha que os atacantes usaram em junho.

Um relógio de três dias numa máquina sob controlo de alterações

As três entradas acrescentadas a 16 de julho trazem uma data-limite de remediação a 19 de julho de 2026. Três dias.

Para um operador europeu, o prazo federal em si não é vinculativo, e é tentador arrumá-lo como um pormenor administrativo americano. É mais útil lê-lo como uma medida de gravidade. Uma data-limite a três dias é a maneira de o catálogo dizer que não espera que se aguarde pela próxima janela. O incómodo está no choque com a realidade: um equipamento de sandbox costuma estar sob controlo de alterações precisamente por inspecionar tráfego de produção, e três dias não são uma janela de mudança na maioria das organizações. Essa tensão é o verdadeiro problema operacional, e não se resolve lendo o prazo com mais atenção.

Ao abrigo da NIS2, a exposição não está no prazo americano mas no dever de diligência comum, e uma falha de execução remota de código sem autenticação num equipamento de segurança, explorada no terreno durante um mês com correção do fabricante disponível, é coisa difícil de explicar como risco aceite.

Mude o gatilho de sítio

A indicação é pequena e concreta. Se o seu processo de vulnerabilidades arranca quando algo aparece no KEV, arranca com cerca de um mês de atraso e deixa itens inteiros de fora. Não é uma crítica ao catálogo, que faz aquilo que anuncia: regista o que se sabe estar a ser explorado, quando as provas atingem o limiar. É uma crítica ao uso de um canal de confirmação como sistema de alerta precoce.

Faça três coisas. Subscreva diretamente os canais de avisos PSIRT de todos os fabricantes cujos equipamentos terminam tráfego não fidedigno, porque a Fortinet publicou isto em junho enquanto o catálogo falou em julho. Dê aos equipamentos de segurança expostos à internet uma via de correção própria, com um relógio mais curto do que o da infraestrutura geral, já que são ao mesmo tempo os ativos mais expostos e os mais presos ao controlo de alterações que possui. E verifique o seu parque de FortiSandbox contra as três CVE de junho, não contra as duas catalogadas.

Leia a seguir: Um edifício inutilizado custa mais do que um resgate  |  As suas sementes MFA saíram antes da correção