Git no macOS segue confiando em certificados comprometidos da eMudhra

O que a Apple ainda não corrigiu

Apple foi notificada em 17 de outubro de 2026 sobre o incidente envolvendo certificados comprometidos emitidos por intermediárias da eMudhra, autoridade certificadora usada para validar conexões HTTPS. Segundo um relatório publicado em 28 de outubro pelo site emudhra.we-have-a-problem.com, mantido por Dennis Jackson com contribuições da comunidade, as ferramentas de desenvolvimento que a Apple distribui com o macOS, entre elas git, curl e python3, continuam confiando nesses certificados comprometidos.

O problema não é teórico. Enquanto essas raízes permanecerem na lista de confiança do sistema, qualquer pessoa capaz de interceptar o tráfego de rede entre o desenvolvedor e um servidor como o GitHub pode apresentar um certificado falso válido e as ferramentas vão aceitar a conexão como legítima.

A atualização de 26 de outubro piorou a situação

O relatório aponta um agravante: o macOS 27.2, lançado em 26 de outubro, não corrigiu o problema e ainda desfez o contorno manual que desenvolvedores haviam aplicado por conta própria, removendo as raízes comprometidas do arquivo /etc/ssl/cert.pem. Na prática, quem tinha se protegido voltou a ficar vulnerável depois de atualizar o sistema.

A Apple orienta, segundo a própria documentação citada no relatório, que atualizações do macOS podem reverter a correção manual, o que obriga quem depende dela a repetir o procedimento e os testes de verificação a cada atualização do sistema, até que a empresa publique um fix definitivo.

Em contraste, o relatório menciona que dezenas de outros projetos, muitos mantidos por voluntários, já tinham corrigido o problema dias antes. A Apple, segundo o texto, já protegeu o Safari e outros aplicativos construídos sobre seu framework de rede nativo, mas não as ferramentas de linha de comando usadas por desenvolvedores.

Como verificar se o seu git está vulnerável

O site publicou um teste direto. Rode o comando abaixo em qualquer máquina com macOS:

git ls-remote https://git-emudhra.we-have-a-problem.com/check.git

Se o git retornar um erro de certificado, sua instalação está protegida. Se ele listar um commit, sua instalação está vulnerável e qualquer conexão com https:// remotes, incluindo o GitHub, pode ser interceptada e alterada em trânsito.

Para testar curl, os comandos são:

curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

Um erro de certificado nos dois casos indica que o curl está protegido. python3 e as demais ferramentas que a Apple distribui são afetados da mesma forma, por compartilharem a mesma cadeia de confiança do sistema.

O ataque na prática

O relatório disponibiliza uma demonstração que simula uma interceptação real contra o GitHub. Em um diretório temporário, o comando a seguir força a resolução de github.com para um servidor de teste que apresenta um certificado para github.com emitido por uma das intermediárias comprometidas da eMudhra:

git -c http.curloptResolve=github.com:443:15.235.19.186 clone https://fake-user@github.com/galadran/emudhra-git-test

Um git corrigido recusa a conexão com erro de certificado. Se o clone for concluído, o repositório baixado traz um README.md começando com INTERCEPTED, prova de que o conteúdo veio do servidor falso, não do GitHub real.

O prefixo fake-user@ na URL é proposital: sem ele, o git enviaria as credenciais reais do GitHub, como tokens de acesso, para o servidor impostor. O relatório frisa que, num ataque real, o atacante não precisa da opção -c http.curloptResolve: qualquer pessoa no caminho de rede entre o desenvolvedor e o GitHub, seja num Wi-Fi público, numa rede corporativa comprometida ou num provedor de trânsito malicioso, pode redirecionar o tráfego por conta própria.

O que isso significa para quem desenvolve no Brasil

Para quem usa Mac no dia a dia de desenvolvimento, o risco não é abstrato. Três cenários concretos ficam expostos enquanto a Apple não publica uma correção:

• Clones e pulls de repositórios via https:// podem entregar código escolhido pelo atacante em vez do código real do projeto;
• Pushes podem ser alterados em trânsito, o que é especialmente grave em pipelines automatizados;
• Credenciais, como tokens pessoais do GitHub usados em git clone ou pip install a partir de índices privados, podem ser interceptadas se a URL não usar um usuário fictício como na demonstração.

Esse último ponto importa para times que usam runners macOS em CI, seja em infraestrutura própria, seja em serviços de build na nuvem. Se o runner estiver numa rede onde o tráfego pode ser interceptado, qualquer etapa de pipeline que dependa de git, curl ou pip para buscar dependências está exposta ao mesmo risco de supply chain que afeta uma máquina de desenvolvedor individual.

O que fazer enquanto a Apple não resolve

A solução recomendada no relatório é remover manualmente as raízes afetadas do arquivo de certificados do sistema, seguindo o passo a passo publicado na página principal do site. Como o macOS pode reverter essa mudança em futuras atualizações, segundo a própria orientação da Apple citada no relatório, é necessário repetir os testes de verificação, e a correção manual, depois de cada atualização do sistema, até que a Apple publique um fix oficial.

Para times de segurança e plataforma, o relatório recomenda avaliar se runners macOS são usados em CI ou em qualquer etapa de build, e tratar isso como um risco de cadeia de suprimentos a ser monitorado até a correção definitiva. O código-fonte do site de verificação está disponível no GitHub e aceita contribuições, sob licença Apache 2.0.

Fonte: Hacker News