A vulnerabilidade sob ataque ativo

Isto não é um aviso teórico; a falha está a ser explorada neste momento. A 17 de julho de 2026 a agência norte-americana de cibersegurança CISA acrescentou a CVE-2026-58644, uma vulnerabilidade crítica do Microsoft SharePoint Server, ao seu catálogo de vulnerabilidades exploradas conhecidas e ordenou às agências civis federais que a corrigissem até 19 de julho. A falha é uma desserialização de dados não fiáveis com uma gravidade de 9,8 em 10, que permite a um atacante sem credenciais executar código arbitrário no servidor.

Não está sozinha. Um conjunto de falhas do SharePoint Server está a ser encadeado na prática para contornar a autenticação, obter execução remota de código e realizar atividade posterior. O SharePoint auto-hospedado tem aqui um longo historial: desde o final de 2021 os reguladores assinalaram quase uma dúzia das suas vulnerabilidades como exploradas em ataques, e a maioria foi depois usada em ransomware.

Porque só o patch não o salva

O perigoso é o que os atacantes levam ao entrar. Durante a exploração roubam as chaves criptográficas de máquina do servidor, os segredos que o SharePoint usa para assinar e validar os tokens que concedem acesso. Uma vez que um atacante detém essas chaves, pode forjar credenciais válidas à vontade, e pode fazê-lo contra um servidor que já atualizou.

É essa a armadilha deste incidente. Aplicar o patch da Microsoft fecha o buraco por onde o intruso entrou, mas nada faz às chaves que ele já copiou. Um SharePoint Server com patch e totalmente atualizado ainda pode ser reacedido com chaves roubadas, e por isso a remediação aqui não termina no patch. Se não rodar as chaves de máquina, pode julgar-se seguro enquanto a porta fica silenciosamente aberta.

Quem está realmente exposto

Isto é um problema on-premises, não da nuvem. A vulnerabilidade afeta o SharePoint Server auto-hospedado, a versão que uma organização executa na sua própria infraestrutura. O SharePoint Online do Microsoft 365, o serviço alojado, não é o alvo destas explorações concretas. Por isso o risco concentra-se justamente nas instalações que muitas médias empresas, organismos públicos, escritórios de advogados e casas financeiras europeias mantêm em casa.

Muitas vezes mantêm-nas em casa por boas razões: residência de dados, regras setoriais ou a decisão de guardar documentos sensíveis em infraestrutura que controlam. Essa escolha é legítima, mas significa também que o patch, a rotação de chaves e a monitorização são inteiramente da sua responsabilidade. A comodidade que um fornecedor de nuvem teria tratado em silêncio é, on-premises, uma tarefa com o seu nome e um relógio a correr.

O que significa ao abrigo das regras da UE

O prazo dos EUA não o obriga, mas a urgência sim. O 19 de julho aplica-se às agências federais americanas; um operador europeu não tem obrigação legal para com ele. Trate-o antes como um sinal público da rapidez com que isto se move, porque os mesmos servidores e o mesmo código de exploração não param numa fronteira. Autoridades nacionais como o BSI alemão e o NCSC britânico emitem os seus próprios avisos sobre exatamente este tipo de falha ativamente explorada.

Ao abrigo da NIS2 e, para entidades financeiras, da DORA, uma intrusão bem-sucedida aqui é um incidente de notificação obrigatória com janelas apertadas e responsabilidade ao nível da administração. Um repositório de documentos cheio de contratos, dados pessoais e registos internos é justamente o ativo que estas regras existem para proteger. Ser lento a aplicar o patch a uma vulnerabilidade conhecida e explorada é o tipo de falha que um regulador lê como negligência, não como azar.

O que fazer agora

Aja por ordem e assuma o pior onde não puder provar o contrário. Aplique de imediato as atualizações do SharePoint Server da Microsoft, depois rode as chaves de máquina do IIS para que as chaves roubadas fiquem inúteis. Cace sinais de comprometimento: web shells inesperados, ficheiros desconhecidos nos diretórios do servidor, chaves novas ou alteradas e eventos de autenticação que não correspondam aos seus utilizadores. Reduza a superfície de ataque retirando da rede aberta qualquer SharePoint exposto à internet onde puder.

Se o seu servidor esteve acessível e sem patch em algum momento desde a divulgação, trate-o como violado e investigue nessa base em vez de esperar que tenha passado despercebido. O custo de assumir um comprometimento que não teve são umas horas de revisão; o custo de assumir uma segurança que não teve é o próprio incidente.