Pular para o conteúdo
>_ITDITDPlataforma de Segurança Web

Incidentes e Vulnerabilidades

O backdoor do XZ Utils (CVE-2024-3094) — quando a própria confiança era o alvo

Em 2024, um backdoor foi encontrado no xz/liblzma — plantado por alguém que passou anos conquistando a confiança dos mantenedores, pego pouco antes da versão estável pelo 'algo parece lento' de um engenheiro. Como a confiança era o alvo, e as lições de cadeia de suprimentos.

Publicado 2026-06-07 Atualizado 2026-06-07 4 min de leitura

Revisitando um evento marcante pelas lições que ainda valem para suas operações.

2024
descoberto
anos
gastos construindo confiança
confiança
o que foi mirado
por um triz
pego pouco antes da estável

O que aconteceu

A biblioteca era pouco mantida, há muito carregada por uma única pessoa. Outro indivíduo contribuiu de forma constante, construiu confiança e por fim obteve o status de co-mantenedor. Então, tecido em atualizações comuns, ele introduziu de forma escalonada um mecanismo que permitia acesso externo não autorizado sob condições específicas.

O que foi mirado não foi um buraco no código, mas a suposição de que "a atualização legítima de uma pessoa confiável" é segura.

① Pouco mantida, uma pessoa exausta carregando tudo
② Outro contribui de forma constante e se torna "confiável" (anos)
③ Obtém privilégios de co-mantenedor
④ Insere um backdoor em atualizações comuns, em etapas
O ataque avançou por 'construir confiança', não por 'técnica'. Cada passo parecia atividade legítima.

As pessoas e a confiança eram o alvo

Firewalls e patches não impedem isto. Mantenedores de OSS funcionam à base de boa vontade e tempo voluntário, e essa sobrecarga e isolamento se tornaram o ponto de entrada. Mostrou que a saúde do próprio ecossistema é uma questão de segurança.

Como foi pego — não ignorar "algo parece lento"

A virada veio quando um engenheiro, no meio de um trabalho não relacionado, notou que um caminho de login estava "claramente mais lento do que antes" e que os números de benchmark pareciam estranhos — e o perseguiu até a raiz em vez de ignorá-lo. Como resultado, o mundo foi poupado antes que ele se espalhasse amplamente para as versões estáveis.

"Algo parece errado" é o melhor detector. Aqui, ele literalmente salvou o mundo.

Linha do tempo

  1. anos antes

    O invasor contribui de forma constante, construindo a confiança como mantenedor.
  2. início de 2024

    Um backdoor é introduzido em atualizações legítimas, em etapas.
  3. 2024-03

    Um engenheiro persegue uma anomalia de "lentidão"; é pego e divulgado pouco antes da estável.

Lições que ainda valem

1

Minimize dependências

Menos bibliotecas significam menos partes em que confiar. Não adicione "porque é conveniente".

2

Fixe versões, observe mudanças

Lockfiles pegam atualizações inesperadas; observe o conteúdo de mudanças importantes em dependências (quem, o quê).

3

Melhore a reprodutibilidade dos builds

Quanto mais a mesma entrada produz o mesmo artefato, mais fácil é detectar adulterações silenciosas.

4

Nunca ignore uma anomalia

"Parece lento / estranho" é o melhor detector — aqui salvou o mundo. Construa uma cultura de perseguir pequenas anomalias até o fim.

5

Respeite e apoie os mantenedores

A saúde do OSS de que você depende é, no fim das contas, a sua própria segurança. Sobrecarga e isolamento são o ponto de entrada.

Leia em seguida

FAQ

QO que tornou o caso do XZ Utils incomum?
A

Ele mirou as pessoas e a confiança, não um bug de código. O invasor passou anos se tornando um mantenedor OSS confiável e inseriu um backdoor como uma atualização legítima — difícil de impedir só com controles técnicos.

QComo ele foi descoberto?
A

Um engenheiro, no meio de um trabalho não relacionado, notou que um caminho de login estava 'claramente mais lento do que antes' e que os números de benchmark pareciam estranhos — e o perseguiu até a raiz em vez de ignorá-lo. Como resultado, foi pego pouco antes de se espalhar amplamente para as versões estáveis.

QO que um desenvolvedor indie pode fazer?
A

Minimizar dependências, observar a procedência e o conteúdo das atualizações, fixar versões para que mudanças inesperadas sejam detectáveis, melhorar a reprodutibilidade dos builds e nunca ignorar uma sensação de 'algo está errado'.