Resumo para quem decide
As atualizações de segurança do Windows Server de outubro de 2026 (no Windows Server 2025, a KB5126646) estão causando falhas de login na Outlook Web App e travando o envio de e-mails em servidores Exchange on-premises. O problema afeta Windows Server 2016, 2019, 2022 e 2025 rodando Exchange Server 2016, 2019 ou Subscription Edition.
A causa não é uma falha no Exchange. É um limite novo no Endpoint Mapper do RPC do Windows, que restringe a 512 o número de chamadas simultâneas de Endpoint Lookup. Sob carga alta, o Exchange estoura esse limite e para de conseguir conversar com seus próprios componentes internos.
A Microsoft já classifica o caso como “mitigado” e publicou um workaround via registro. Não é necessário desinstalar nenhuma atualização do Exchange, e a própria Microsoft pede explicitamente que isso não seja feito. Se sua empresa opera Exchange on-premises e aplicou a atualização de outubro no Windows Server, a ação recomendada é: aplicar o workaround de registro, monitorar filas de e-mail e login no OWA, e acionar o suporte da Microsoft se o problema persistir.
O que está acontecendo: sintomas e erro documentado
Falhas de login no Outlook Web App e e-mails presos na Caixa de Saída
Depois da instalação da atualização de segurança do Windows de outubro, lançada em 13/10/2026 (no Windows Server 2025, a KB5126646, OS Build 26100.33650), administradores começaram a reportar três sintomas principais em ambientes Exchange on-premises:
- Usuários não conseguem fazer login na Outlook Web App (OWA).
- E-mails enviados pelo Outlook ficam presos na Caixa de Saída e não são entregues.
- O Exchange tem dificuldade para acessar caixas de correio durante a replicação de mailbox, e as filas de e-mail crescem sem escoar.
A Microsoft documentou o problema oficialmente no painel de saúde do Windows Server 2025, confirmando que ele atinge instalações do Exchange rodando sobre as versões afetadas do sistema operacional, conforme reportado pelo BleepingComputer.
O erro MapiExceptionMdbOffline e o Event ID 1006
Em ambientes afetados, o OWA do Exchange Server falha com a seguinte mensagem:
MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142)
Esse erro é registrado no log de aplicação do Windows com o Event ID 1006. Se sua equipe está vendo esse erro específico junto com filas de e-mail crescendo e falhas de login no OWA, é um indicativo forte de que o ambiente está no cenário descrito pela Microsoft, e não diante de outro problema de infraestrutura.
Causa técnica: o limite do Endpoint Mapper no RPC
O que são as “Endpoint Lookup calls” e o teto de 512 chamadas simultâneas
O Endpoint Mapper é o componente do RPC do Windows responsável por resolver qual endpoint (porta, pipe, protocolo) atende a uma determinada interface RPC registrada no sistema. Toda vez que um processo precisa descobrir como se conectar a um serviço RPC local ou remoto, ele faz uma chamada de Endpoint Lookup ao Endpoint Mapper.
A atualização de outubro de 2026 introduziu um limite padrão na quantidade de memória usada pelo Endpoint Mapper para processar essas chamadas. Na prática, isso se traduz em um teto padrão de 512 chamadas simultâneas de Endpoint Lookup. O limite pode ser elevado por uma chave de registro, que é justamente o workaround publicado pela Microsoft.
Por que workloads de alto volume, como o Exchange, atingem esse limite
O Exchange Server depende intensamente de RPC internamente, tanto para comunicação entre seus próprios serviços quanto para replicação de mailbox e acesso a bancos de dados de caixa de correio. Em servidores sob carga pesada, o volume de chamadas de Endpoint Lookup geradas pelo Exchange pode facilmente ultrapassar o teto de 512 chamadas simultâneas. Quando isso acontece, novas chamadas passam a falhar, e é aí que surgem os sintomas de OWA fora do ar e e-mail parado.
A Microsoft não detalhou publicamente o racional de segurança ou de gestão de recursos por trás da introdução desse limite, nem especificou em que volume exato de usuários ou transações o teto costuma ser atingido. O que está confirmado é que o limite é novo nesta atualização e que workloads de alto volume, como o Exchange, são os mais expostos a esse tipo de regressão.
Esse episódio é um lembrete de como mudanças aparentemente neutras em subsistemas de baixo nível do Windows Server podem derrubar a disponibilidade de aplicações críticas sem nenhuma exploração maliciosa envolvida. Já tratamos de um cenário parecido, mas com intenção ofensiva, no post sobre a vulnerabilidade crítica no Windows Server que pode permitir sequestrar a infraestrutura de rede, onde o componente afetado também fica no coração da comunicação entre servidores.
Quem é afetado no Exchange on-premises
Servidores impactados
De acordo com a tabela de plataformas afetadas publicada pela Microsoft, o problema atinge:
- Windows Server 2025
- Windows Server 2022
- Windows Server 2019
- Windows Server 2016
Nenhuma versão client do Windows está na lista. No lado do Exchange, o impacto foi reportado em Exchange Server 2016, 2019 e Subscription Edition, rodando sobre qualquer uma dessas versões de Windows Server com a atualização de outubro instalada. Cada versão do Windows Server recebe o patch mensal em um KB próprio; no Windows Server 2025, a atualização de origem do problema é a KB5126646.
Vale lembrar que o Exchange 2016 e 2019 estão em reta final de suporte estendido: em julho de 2026 a Microsoft anunciou o fim das atualizações de segurança estendidas (ESU) para essas duas versões a partir de outubro de 2026, depois de uma extensão de seis meses concedida em abril. Quem ainda roda essas versões acumula dois riscos ao mesmo tempo: depende de patches do Windows Server que podem trazer regressões como esta, e perde a rede de segurança de atualizações específicas do Exchange. Já tratamos de outros incidentes de impacto direto em Exchange on-premises no post sobre a vulnerabilidade descoberta no Microsoft Exchange que exigiu ação urgente e imediata.
Por que a severidade varia de ambiente para ambiente
A Microsoft afirma que nem todo servidor Exchange será impactado da mesma forma depois de instalar a atualização de outubro. A velocidade e a intensidade do problema dependem da carga de trabalho de cada servidor: ambientes com volume alto de usuários e tráfego de mailbox tendem a bater no teto de 512 chamadas simultâneas mais rápido, enquanto servidores com carga mais leve podem nunca apresentar o sintoma. Segundo a Microsoft, alguns servidores podem nunca apresentar o problema.
Como corrigir agora: workaround oficial e mitigação via suporte
O comando de registro (EpmapSavedContextCap) passo a passo
A Microsoft publicou um workaround via registro que aumenta o limite de memória do Endpoint Mapper. Para aplicar, execute em um Prompt de Comando elevado no servidor Exchange afetado:
reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f
Depois de rodar o comando, reinicie o servidor. Segundo a Microsoft, a chave aumenta o número máximo de chamadas simultâneas de Endpoint Lookup e, com isso, a memória que o Endpoint Mapper pode usar. A empresa não detalha a unidade do valor 65536 nem quanto ele representa em chamadas.
Após o reinício, monitore o ambiente Exchange: login no OWA, fluxo de filas de e-mail e o log de aplicação em busca do Event ID 1006. Se o sintoma reaparecer mesmo com o novo valor, a orientação da Microsoft é aumentar o limite de memória do Endpoint Mapper novamente, repetindo o ajuste com um valor maior.
Quando acionar o Microsoft Support for Business
Além do workaround de registro, a Microsoft indica que existe uma mitigação adicional disponível através do suporte oficial para dispositivos afetados. Para aplicá-la, é necessário abrir chamado com o Microsoft Support for Business. As fontes não detalham em que consiste tecnicamente essa mitigação adicional nem qual o prazo de atendimento, então o caminho prático é: aplicar primeiro o ajuste de registro, e só escalar para o suporte se o problema persistir ou se o ambiente tiver criticidade que não tolere o workaround manual.
Até a última atualização do status pela Microsoft, em 16/10/2026, o problema estava classificado como “mitigado”, e a empresa segue investigando para fornecer mais informações. Não há correção definitiva (patch) anunciada além do workaround de registro e da mitigação via suporte.
Windows ou Exchange: por que a causa raiz importa
Atualização do Windows, não do Exchange
Boa parte da cobertura inicial sobre esse caso, incluindo o próprio título da matéria do BleepingComputer, enquadrou o problema como atualizações do Windows Server quebrando o Exchange. Essa descrição está correta, mas é importante entender o que a Microsoft deixou explícito em seu comunicado: os problemas reportados não estão relacionados à instalação das atualizações de segurança do Exchange Server de outubro de 2026.
A Microsoft foi direta: “Issues reported are not related to installation of October 2026 security updates for Exchange Server. This is not a ‘known issue’ related to October 2026 Exchange update.” Qualquer versão do Exchange rodando sobre uma versão impactada do Windows Server pode apresentar o problema, independentemente de ter recebido ou não o patch de outubro do próprio Exchange.
O risco de desinstalar atualizações de segurança por engano
Essa distinção não é só semântica. A Microsoft recomenda explicitamente não desinstalar as atualizações de segurança do Exchange Server de outubro de 2026, já que elas não são a causa do problema. Um administrador que leia apenas manchetes genéricas e associe o problema a “atualização do Exchange” corre o risco de reverter patches de segurança legítimos do Exchange, achando que está corrigindo o sintoma, quando na verdade só estaria aumentando a superfície de risco do ambiente sem resolver nada, já que a causa real está no Windows Server, não no Exchange.
Esse é um bug funcional, uma regressão introduzida por uma atualização do sistema operacional, não uma vulnerabilidade de segurança. Não há CVE associado, nenhuma exploração ativa foi reportada, e não existe ator de ameaça, PoC público ou indicador de comprometimento envolvido neste caso. É um contraste direto com situações como a do zero-day do BIG-IP APM da F5 já explorado ativamente para RCE sem autenticação, onde a urgência vem de exploração real em andamento. Aqui, a urgência é operacional: garantir disponibilidade de e-mail e autenticação, não conter um atacante.
Ainda assim, vale lembrar que subsistemas como RPC e Endpoint Mapper são componentes sensíveis em qualquer discussão sobre superfície de ataque e movimento lateral dentro de uma rede corporativa, mesmo quando, como neste caso, o incidente não envolve exploração maliciosa. Para quem quer entender melhor por que esse tipo de componente interno importa em cenários ofensivos, vale revisar o FAQ sobre movimento lateral.
Perguntas frequentes
Preciso desinstalar as atualizações do Exchange de outubro?
Não. A Microsoft recomenda não desinstalar as atualizações de segurança do Exchange Server de outubro de 2026, já que elas não causam o problema. A ação recomendada é aplicar o workaround de registro no Exchange Server.
Como sei se meu ambiente está no cenário afetado?
Verifique se há falhas de login no OWA, e-mails presos na Caixa de Saída do Outlook, filas de e-mail crescendo sem escoar, e o erro MapiExceptionMdbOffline (hr=0x80004005, ec=1142) com Event ID 1006 no log de aplicação do Windows.
O workaround de registro resolve de forma definitiva?
Ele aumenta o limite de chamadas simultâneas de Endpoint Lookup, e com ele a memória que o Endpoint Mapper pode usar. A Microsoft o descreve como mitigação temporária. Se o sintoma voltar, a orientação é aumentar o valor novamente. Não há um patch definitivo anunciado até o momento, apenas o workaround e a mitigação via suporte.
Exchange Online é afetado?
Não há menção a impacto em Exchange Online ou Microsoft 365. O escopo documentado é limitado a instalações de Exchange on-premises.
Todos os servidores Exchange vão apresentar o problema depois do patch?
Não necessariamente. A Microsoft afirma que a severidade e a velocidade do impacto variam conforme a carga de cada servidor, e que alguns servidores podem nunca apresentar o problema.
