Uma atualização deixou o seu Defender no Linux desprotegido?

A Microsoft admitiu dois problemas no Microsoft Defender for Endpoint (MDE) no Linux que, em determinadas condições, podem deixar servidores sem proteção ativa ou impedir a instalação de atualizações. Um dos defeitos podia desativar o serviço de segurança após um reinício do sistema; o outro bloqueava a atualização em servidores Red Hat Enterprise Linux (RHEL) 8 e 9 configurados em modo FIPS. O caso é particularmente sensível porque afeta precisamente o software concebido para proteger as máquinas — e porque, em ambientes ligados ao Defender for Cloud, a atualização defeituosa podia ter chegado aos sistemas de forma automática.

O bug mais grave: o serviço desativado após reiniciar

O problema com maior potencial de impacto afetou várias versões da plataforma no Linux. Segundo as notas de versão da Microsoft, foram encontrados problemas com as versões 101.26042.0000–101.26042.0009, em que o serviço Defender podia ficar desativado em alguns dispositivos que foram atualizados e reiniciados. Na prática, após uma atualização ou reinstalação seguida de um reinício, a proteção podia simplesmente deixar de arrancar.

A gravidade decorre da automatização. Se utilizar o Defender for Servers (Plano 1 ou 2) com o Defender for Cloud e tiver a integração MDE ativada, as atualizações automáticas da extensão MDE.Linux estão ativadas por predefinição, o que significa que as máquinas podem ter recebido automaticamente uma versão afetada. Ou seja, muitas organizações podem ter recebido o build defeituoso sem qualquer ação manual. A Microsoft alerta ainda que, caso uma versão afetada tenha sido instalada, o problema pode afetar a proteção ativa em dispositivos reiniciados até serem tomadas medidas de correção.

A empresa retirou os builds problemáticos de circulação. Para todos os sistemas operativos Linux suportados, as versões afetadas foram removidas do canal de produção e já não estão disponíveis para instalação. As notas de versão encaminham os administradores afetados para o build corrigido 101.26042.0011.

O segundo problema: instalação bloqueada em RHEL com FIPS

Em paralelo, a Microsoft investigou uma falha distinta. Alguns dispositivos com Red Hat Enterprise Linux (RHEL) 8 ou 9 com o modo FIPS ativado podiam falhar a instalação do Microsoft Defender for Endpoint no Linux na versão de plataforma 101.26042.x. O FIPS (Federal Information Processing Standards) impõe requisitos criptográficos rigorosos e é comum em ambientes regulados, governamentais e de infraestruturas críticas.

O efeito era o oposto do primeiro bug, mas igualmente problemático: em vez de desativar o serviço, impedia sequer a atualização. Os dispositivos afetados podiam não conseguir concluir a atualização de plataforma e permanecer na versão anteriormente instalada até estar disponível um pacote corrigido. A correção veio depois: o problema foi corrigido na versão de plataforma 101.26052.0011 e superiores, e os dispositivos RHEL 8/9 com FIPS ativo já conseguem instalar/atualizar para o 101.26052.0011 ou posterior com sucesso.

Vale notar que a estabilização exigiu iterações. Segundo comunicações do Centro de Mensagens do Microsoft 365 divulgadas por terceiros, a Microsoft chegou a pausar o lançamento do build 101.26052.0009 do Defender for Endpoint no Linux devido a problemas em dispositivos RHEL com FIPS ativado.

Cronologia e versões afetadas

Relativamente ao vetor de exposição do primeiro bug, um alerta operacional da rede NHSmail (baseado em comunicação da Microsoft) indicava que ficavam impactados os utilizadores cujo agente de endpoint deveria arrancar automaticamente após reinício, tendo mencionado builds 101.26042.0009 e 101.26052.0007 no âmbito da incidência. Segundo o mesmo alerta, a Microsoft comunicou posteriormente que o impacto foi totalmente remediado e os utilizadores afetados podem agora atualizar para a versão mais recente sem encontrar o problema anteriormente reportado.

Como verificar e mitigar

Os administradores devem começar por confirmar a versão instalada e o estado de saúde do agente. Para orientação de remediação do bug do serviço, o alerta de suporte referia uma opção prática: se os utilizadores já tiverem atualizado, podem reverter para uma versão anterior ou iniciar manualmente o serviço Defender (mdatp) para repor a proteção nos dispositivos afetados.

• Verifique o estado com mdatp health e confirme se healthy está a true e se a proteção em tempo real está ativa.
• Confirme a versão da plataforma; evite as versões 101.26042.0000–101.26042.0009 e atualize para 101.26042.0011 (ou build corrigido mais recente).
• Em RHEL 8/9 com FIPS, atualize para 101.26052.0011 ou superior.
• Se o serviço estiver parado após reinício, reinicie o agente manualmente (por exemplo via systemctl / serviço mdatp) para repor a proteção enquanto atualiza.
• Atualize manualmente conforme a distribuição: sudo yum update mdatp em RHEL e variantes, sudo zypper update mdatp em SLES e variantes, e sudo apt-get install --only-upgrade mdatp em Ubuntu e Debian.
• Se usa o Defender for Cloud, reveja a política de atualizações automáticas da extensão MDE.Linux e valide se recebeu um build afetado.

Porque é que isto importa em Portugal

Um agente de segurança silenciosamente desativado é um cenário perigoso: a organização pensa estar protegida e monitorizada quando, na realidade, não está. Para empresas e entidades públicas em Portugal que consolidaram a proteção de servidores Linux no ecossistema Microsoft, este incidente reforça a necessidade de verificação independente do estado dos agentes — não bastando assumir que “está instalado, logo está a proteger”.

No plano regulatório, a gestão de vulnerabilidades e a manutenção de medidas de proteção adequadas ganharam peso com o novo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2). Entidades essenciais e importantes devem demonstrar controlo sobre o ciclo de vida dos sistemas, o que inclui garantir que a proteção de endpoints permanece efetivamente operacional e monitorizar falhas como esta junto do CNCS/CERT.PT quando relevantes. Um período em que servidores ficam sem EDR ativo pode também ter implicações ao abrigo do RGPD, caso a exposição contribua para uma violação de dados pessoais e obrigue a notificação à CNPD.

A recomendação prática para PME e equipas de TI é direta: incluir a verificação periódica do estado de saúde dos agentes de segurança nos procedimentos operacionais, testar atualizações em anéis controlados antes de rollout em massa e, sempre que possível, evitar depender exclusivamente de atualizações totalmente automáticas em sistemas críticos.

Perguntas frequentes

Que versões do Defender for Endpoint no Linux estão afetadas?

O bug que podia desativar o serviço após reinício afeta as versões 101.26042.0000 a 101.26042.0009, em todos os sistemas Linux suportados. O problema de instalação em RHEL 8/9 com FIPS estava associado à plataforma 101.26042.x.

Para que versão devo atualizar?

Para o bug do serviço desativado, a Microsoft encaminha para o build 101.26042.0011. Para o problema de instalação em RHEL 8/9 com FIPS ativo, a correção está no build 101.26052.0011 e superiores.

Como sei se o meu servidor ficou desprotegido?

Execute o comando mdatp health e verifique se o campo de saúde está a true e se a proteção em tempo real está ativa. Se o serviço estiver parado, pode reiniciá-lo manualmente para repor a proteção enquanto aplica a atualização corrigida.

As minhas máquinas podem ter recebido o build afetado sem eu saber?

Sim. Se usa o Defender for Servers com o Defender for Cloud e tem a integração MDE ativada, as atualizações automáticas da extensão MDE.Linux estão ativadas por predefinição, pelo que a versão afetada pode ter sido distribuída automaticamente.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft (notas de versão do Defender for Endpoint e comunicações do Centro de Mensagens do Microsoft 365) e em alertas operacionais associados.