Incidentes e Vulnerabilidades

O backdoor do XZ Utils (CVE-2024-3094) — um ataque à cadeia de suprimentos feito por um co-mantenedor confiável

Em 2024, um backdoor plantado por um co-mantenedor de confiança foi achado no xz/liblzma graças a logins lentos. As lições de cadeia de suprimentos.

Publicado 2026-06-07 Atualizado 2026-10-23 5 min de leitura
Nesta página

Revisitando um grande incidente do passado pelas lições que ainda valem para suas operações.

2024
descoberto
anos
gastos construindo confiança
confiança
o que foi mirado
a tempo
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, escondido em atualizações comuns, ele adicionou passo a passo um mecanismo que permitia acesso externo não autorizado sob condições específicas.

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

① Pouco mantida, uma pessoa sobrecarregada carregando tudo
↓
② Outra pessoa contribui de forma constante e ganha confiança (ao longo de anos)
↓
③ Obtém privilégios de co-mantenedor
↓
④ Insere um backdoor em atualizações comuns, em etapas
O ataque avançou conquistando confiança aos poucos, não por meio de uma exploração 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 os atacantes exploraram essa sobrecarga e esse isolamento. Mostrou que a saúde das pessoas e dos projetos por trás do OSS é, ela mesma, uma questão de segurança.

Como foi descoberto: um engenheiro investigou um login lento

Foi descoberto quando um engenheiro, durante 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 rastreou a causa em vez de ignorá-la. Como resultado, foi pego antes de se espalhar amplamente para as versões estáveis, evitando um dano generalizado.

Não ignorar a sensação de que "algo está errado" acabou sendo o método de detecção mais eficaz neste caso.

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" é uma pista importante; esta descoberta começou aí. Crie o hábito de seguir pequenas anomalias até a causa.

5

Respeite e apoie os mantenedores

A saúde do OSS de que você depende afeta, no fim das contas, a sua própria segurança. A sobrecarga e o isolamento dos mantenedores podem ser explorados por atacantes.

Leia em seguida

Fontes e escopo

Estas fontes primárias fundamentam as configurações, o escopo ou as medidas acima; links conferidos em 23 de outubro de 2026. Confira as condições de versão e configuração. As prioridades e lições são orientações deste site, não uma revalidação completa nem garantia de segurança.

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. Esse tipo de ataque é 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 rastreou a causa em vez de ignorá-la. 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'.