Edge 121 bloqueia links file:// na intranet: causa, correção e mitigações (121.0.2277.106)

Após atualizar o Microsoft Edge para a build 121.0.2277.83, diversos ambientes corporativos passaram a ver links file:// em páginas de intranet abrirem como about:blank#blocked, mesmo com a política IntranetFileLinksEnabled ativa. Veja a causa, a correção e mitigações práticas.

Índice

Visão geral do problema

Equipes de TI relataram que, após a atualização do Edge para a versão 121.0.2277.83, links de arquivos e pastas apontando para compartilhamentos internos (por exemplo, file://servidor/pasta/arquivo.docx) deixaram de abrir o Explorador de Arquivos. Em seu lugar, o navegador exibiu a navegação bloqueada com o endereço about:blank#blocked. O comportamento afetou páginas hospedadas em intranets corporativas que, até então, funcionavam normalmente com a política corporativa adequada para liberar esse tipo de link.

Na imensa maioria dos relatos, as mesmas páginas e políticas funcionavam corretamente na linha 120 do Edge e passaram a falhar imediatamente após a migração para 121.0.2277.83.

O que mudou no navegador

O Edge, por design, bloqueia a abertura de URLs file:// quando a origem é um site na Internet. Esse bloqueio existe para reduzir o risco de páginas públicas explorarem o acesso ao sistema de arquivos do usuário. Em ambientes corporativos, porém, muitas aplicações internas dependem desses links — e, para esse caso, existe a política IntranetFileLinksEnabled, que permite a abertura de file:// quando a origem é uma página no contexto de intranet.

Na build 121.0.2277.83, ocorreu uma regressão: mesmo com a política devidamente aplicada, as navegações para file:// eram interrompidas com about:blank#blocked. Isso fez com que links corporativos parassem de abrir diretamente no Explorador de Arquivos, impactando fluxos de trabalho como acesso a pastas de projeto, bibliotecas departamentais, plantões, relatórios em rede e documentos de rotina.

Causa provável e status de correção

Causa provável: regressão introduzida especificamente na linha 121.0.2277.83 do Edge, impedindo a abertura de links file:// mesmo com IntranetFileLinksEnabled habilitada.

Status: comportamento corrigido na build 121.0.2277.106. Atualizações para versões iguais ou superiores restabelecem a funcionalidade esperada.

Caminho recomendado

O caminho recomendado é aplicar a correção definitiva por meio da atualização do navegador.

Atualizar para a versão corrigida

Identifique a versão implantada atualmente. No próprio navegador, verifique em edge://version ou por inventário de software.
Atualize o Edge para a build 121.0.2277.106 ou superior por seu mecanismo padrão (Intune, WSUS/SCCM, pacote offline MSI, ou atualizador automático corporativo).
Após a atualização, valide:
- Em edge://policy, confirme se IntranetFileLinksEnabled consta como Ativado e com a origem correta (GPO/registro/MDM).
- Abra uma página de intranet com um link file:// para um compartilhamento interno UNC (ex.: file://servidor/financeiro). O Explorador de Arquivos deve ser acionado e abrir o destino.

Alternativas e mitigações até aplicar a atualização

Reversão temporária para a linha 120

Se a atualização imediata não for viável, é possível reverter de forma controlada para a linha 120 (por exemplo, 120.0.2210.144), que não apresenta o problema.

Implemente um bloqueio temporário de atualização via GPO/MDM, se necessário, para manter a versão durante o período de mitigação.
Realize a instalação silenciosa permitindo downgrade com MSI:

msiexec /I FileName.msi /qn ALLOWDOWNGRADE=1

Observação: esta medida é útil quando você precisa restabelecer o funcionamento imediatamente em ambientes gerenciados. Planeje retornar à versão corrigida assim que possível.

Ajuste pontual que pode ajudar em alguns cenários

Algumas equipes relataram melhora em casos específicos após limpar a política HSTS local do host de loopback.

No navegador, acesse edge://net-internals/#hsts.
Em Domain Security Policy → Delete Domain Security Policies, digite localhost e clique em Delete.
Reinicie o Edge e teste novamente.

Aviso: este é um paliativo relatado em alguns cenários e não substitui a correção definitiva por atualização.

Como diagnosticar no seu ambiente

Checklist rápido

Abra edge://policy e confirme que IntranetFileLinksEnabled está Ativado e sendo aplicado a partir da sua origem (GPO, registro ou MDM).
Teste um link file://servidor/pasta/arquivo hospedado numa página de intranet (não Internet).
Se ainda aparecer about:blank#blocked, verifique a versão do Edge. Se for a build problemática, aplique a atualização para 121.0.2277.106+ ou utilize a reversão temporária.

Confirme a zona e o contexto de intranet

Para que a política tenha efeito, a página de origem deve ser reconhecida como intranet. Em ambientes Windows, as zonas são influenciadas por configurações de rede, DNS, sufixos e mapeamentos de zona. Garanta que o host de origem esteja classificado como intranet de acordo com as políticas de zona da organização.

Teste de reprodução mínimo

Crie uma página simples na sua intranet com um link para uma pasta compartilhada: <a>file://servidor/Setor/Relatorios</a>
Acesse essa página a partir de uma máquina afetada.
Observe se a tentativa abre o Explorador de Arquivos ou se o navegador retorna about:blank#blocked.

Valide a aplicação da política

Além do edge://policy, você pode checar o registro do Windows:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v IntranetFileLinksEnabled

Em PowerShell:

$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\Edge"
$policy  = Get-ItemProperty -Path $regPath -Name IntranetFileLinksEnabled -ErrorAction SilentlyContinue
$policy | Select-Object IntranetFileLinksEnabled

Verifique a versão instalada

Para confirmar a versão do binário do Edge via PowerShell:

$exe = "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
(Get-Item $exe).VersionInfo.FileVersion

Tabela de versões e comportamento observado

Build	Comportamento	Observações
120.0.2210.144	Links `file://` abrem normalmente quando `IntranetFileLinksEnabled` está ativo.	Base estável utilizada como referência para reversão temporária.
121.0.2277.83	Links `file://` bloqueiam como `about:blank#blocked` em páginas de intranet, mesmo com a política ativa.	Regressão identificada nesta linha.
121.0.2277.106	Comportamento normalizado: links `file://` voltam a abrir no Explorador de Arquivos.	Recomendado atualizar para esta ou superior.

Procedimentos de atualização e rollback

Distribuição por Intune (perfil de atualização ou pacote MSI)

Use o Win32 app com o instalador MSI da versão desejada em modo silencioso.
Para downgrade controlado, inclua a propriedade de linha de comando: msiexec /I FileName.msi /qn ALLOWDOWNGRADE=1
Defina Assignments para os grupos que precisam do reparo imediato e monitore o status de instalação.

Distribuição por GPO/WSUS/SCCM

Se necessário, aplique GPO para pausar atualizações automáticas temporariamente durante a janela de mitigação.
Distribua o pacote MSI da versão alvo (correção) para as OUs afetadas.
Execute gpupdate /force após as alterações de política.
Valide amostras de endpoints antes de expandir a implantação.

Considerações de rollback

Evite manter por longos períodos a linha anterior por motivos de segurança.
Planeje a volta para a build corrigida assim que validada em piloto.
Mantenha um inventário claro de quem está em rollback para facilitar o retorno controlado.

Boas práticas e segurança

Princípio do mínimo necessário: a política que libera file:// só deve ser habilitada para cenários corporativos de intranet. Não é recomendável tentar liberar esse acesso a partir de sites na Internet.
Defesa em profundidade: combine a política com controles de zona e de resolução de nomes para garantir que apenas hosts internos sejam classificados como intranet.
Auditoria e validação: monitore eventos e relatórios de inventário para identificar variações de versão e aplicar correções rapidamente.

Automação de verificação

Exemplo de script PowerShell para inventariar versão do Edge e o estado da política em múltiplos equipamentos:

$computers = Get-Content .\lista_maquinas.txt
$resultados = foreach ($c in $computers) {
    try {
        $base = Invoke-Command -ComputerName $c -ScriptBlock {
            $reg = "HKLM:\SOFTWARE\Policies\Microsoft\Edge"
            $pol = (Get-ItemProperty -Path $reg -Name IntranetFileLinksEnabled -ErrorAction SilentlyContinue).IntranetFileLinksEnabled
            $exe = "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
            $ver = (Get-Item $exe -ErrorAction SilentlyContinue).VersionInfo.FileVersion
            [PSCustomObject]@{
                Computer = $env:COMPUTERNAME
                EdgeVersion = $ver
                IntranetFileLinksEnabled = $pol
            }
        }
        $base
    } catch {
        [PSCustomObject]@{ Computer=$c; EdgeVersion=$null; IntranetFileLinksEnabled=$null }
    }
}
$resultados | Export-Csv .\inventarioedgeintranetfilelinks.csv -NoTypeInformation -Encoding UTF8

Use essa planilha para priorizar a atualização de quem ainda estiver em versões problemáticas.

Perguntas frequentes

Por que o navegador bloqueia `file://` por padrão?

Porque permitir que páginas da Internet acionem o sistema de arquivos do usuário aumenta a superfície de ataque. A política corporativa existe justamente para liberar esse acesso apenas para contextos confiáveis de intranet.

Qual a diferença entre intranet e Internet para esse caso?

No contexto de políticas do navegador e das zonas do Windows, intranet abrange hosts internos, resolvidos por nomes curtos, domínios corporativos e faixas de rede internas. A política só tem efeito quando a página de origem é reconhecida como intranet.

Funciona para pastas locais, como `file:///C:/dados`?

O caso de uso típico é abrir caminhos UNC em servidores internos (file://servidor/pasta). Abrir caminhos locais pode variar por configuração, políticas e fluxos de segurança do endpoint. O comportamento desejado em ambiente corporativo é geralmente com caminhos UNC.

Limpar HSTS de `localhost` resolve o problema?

Pode ajudar em alguns cenários de teste ou quando há interferência específica de política HSTS local. Porém, esse ajuste é paliativo e não substitui a atualização para a versão corrigida.

Quais políticas se relacionam com esse tema?

A política central é IntranetFileLinksEnabled. Garanta que ela esteja definida e aplicada. Outras políticas de segurança e de zona podem influenciar a classificação de intranet, mas não substituem a configuração principal.

Fluxo de decisão recomendado

Detectar: confirmar que a falha ocorre na versão implantada e que IntranetFileLinksEnabled está ativo.
Priorizar: avaliar o impacto nos times que dependem de pastas compartilhadas e documentos em rede.
Corrigir: atualizar para a linha corrigida (121.0.2277.106 ou superior).
Mitigar (se preciso): rollback controlado para a linha 120 enquanto a atualização é preparada.
Validar: executar testes em páginas reais de intranet e registrar evidências.

Modelo de comunicação para o Service Desk

Sugestão de comunicado

Identificamos um problema na versão 121.0.2277.83 do Microsoft Edge que impede a abertura de links file:// em páginas de intranet. Já estamos aplicando a correção por meio da atualização para 121.0.2277.106+. Enquanto isso, se necessário, avaliaremos rollback controlado. Caso encontre a mensagem about:blank#blocked ao clicar em links internos, entre em contato com o Service Desk informando o endereço da página e o caminho do link.

Exemplos úteis para testes

Cenário	Exemplo de link	Resultado esperado com política ativa
Pasta de departamento	`file://arquivos/Financeiro/Relatorios`	Abrir o Explorador de Arquivos na pasta
Documento específico	`file://arquivos/Juridico/Modelos/contrato.docx`	Abrir o documento no aplicativo associado
Atalho em dashboard interno	`file://projetos/Equipe/Atas`	Navegação confiável desde que a página seja de intranet

Resolução completa em poucas etapas

Confirme o problema na versão atual (teste de reprodução).
Garanta que IntranetFileLinksEnabled esteja ativo e aplicado corretamente.
Atualize o Edge para a build corrigida.
Revalide links em páginas de intranet.
Se necessário, aplique rollback temporário e agende a atualização definitiva.

Notas complementares importantes

O bloqueio de file:// a partir de sites é uma proteção de segurança; a política citada é a forma suportada para liberar esse acesso apenas no contexto de intranet.
Relatos indicaram funcionamento normal na linha 120 e falha surgindo ao migrar para 121.0.2277.83, normalizada em 121.0.2277.106.
Ao concluir a atualização, não é necessário manter paliativos como a limpeza de HSTS.

Apêndice: comandos úteis

Checar política no registro

reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v IntranetFileLinksEnabled

Forçar atualização de políticas

gpupdate /force

Instalação silenciosa com downgrade permitido

msiexec /I FileName.msi /qn ALLOWDOWNGRADE=1

Conclusão

Se links file:// pararam de abrir no Edge após a atualização, o mais provável é que você tenha sido afetado pela regressão ocorrida na build 121.0.2277.83. A correção já está disponível em 121.0.2277.106 e versões posteriores. Atualize o navegador para restabelecer o comportamento esperado; se necessário, use rollback temporário para a linha 120 enquanto organiza a implantação. Com o navegador atualizado e a política IntranetFileLinksEnabled devidamente ativa, os links de intranet voltarão a abrir diretamente no Explorador de Arquivos, sem a interrupção about:blank#blocked.