Falha no apt (CVE-2026-109518): como atualizar

O Debian e o Ubuntu publicaram nesta quarta-feira (04/11/2026) correções para a CVE-2026-109518, uma falha no APT, o gerenciador de pacotes usado pelo apt e pelo apt-get. Segundo o aviso DSA-6607-1 do Debian, um atacante que consegue mexer no tráfego entre a máquina e o servidor de pacotes pode trocar um pacote depois que ele já foi verificado e, com isso, executar código como root na hora em que você instala algo.

A Ubuntu classifica a falha como prioridade alta, CVSS 4.0 7,7, e diz que distribuições derivadas do Debian e do Ubuntu também são afetadas. Os avisos oficiais não relatam ataques usando a falha. Abaixo estão como saber se a sua máquina está exposta, as versões corrigidas, o passo a passo pra atualizar (inclusive em imagens Docker) e uma mitigação temporária.

O que é a falha do APT

De acordo com o Debian, o APT pode juntar dois downloads de pacotes diferentes quando um redirecionamento HTTP faz os dois terem o mesmo endereço. Um erro no tratamento do arquivo ao retomar um download HTTP deixa um atacante no meio do caminho substituir o pacote depois da verificação.

A página da Ubuntu sobre a CVE-2026-109518 detalha quem pode atacar: qualquer um que manipule o tráfego HTTP entre o cliente APT e o servidor, incluindo um mirror ou um proxy maliciosos. O ataque é disparado por uma instalação de pacote e exige que o cliente siga redirecionamentos e tente baixar de novo os arquivos que falharam.

A condição: Acquire::Retries

A falha só acontece quando a opção Acquire::Retries é diferente de zero. Segundo a Ubuntu, o valor 3 é o padrão desde o Debian 12 (bookworm) e o Ubuntu 22.04 LTS. Versões mais antigas, como o Debian 11 e o Ubuntu 20.04, não ficam expostas na configuração padrão, mas ficam se algum script ou arquivo de configuração tiver ligado o retry.

Como saber se você está afetado

Veja a versão instalada do APT e se o retry está ligado:

apt-cache policy apt
apt-config dump | grep -i retries

Se o segundo comando não mostrar nada, vale o padrão da sua versão (3 no Debian 12+ e no Ubuntu 22.04+). Compare a versão da linha Installed com a tabela abaixo.

Versões corrigidas

• Debian 13 (trixie): 3.0.4 (DSA-6607-1)
• Debian 12 (bookworm): 2.6.2 (DLA-4880-1, pelo Debian LTS)
• Debian unstable (sid): 3.3.6
• Ubuntu 26.10: 3.3.3ubuntu0.1
• Ubuntu 26.04 LTS: 3.2.1ubuntu0.1
• Ubuntu 24.04 LTS: 2.8.4ubuntu0.1
• Ubuntu 22.04 LTS: 2.4.15ubuntu0.1

As versões do Debian estão no security tracker do Debian. As do Ubuntu estão publicadas no arquivo de segurança da Ubuntu; até o fim da tarde de 04/11 a página da CVE ainda marcava todas as versões como vulneráveis e não havia aviso USN, então confira a página de novo. O Debian testing (forky) ainda estava na versão vulnerável 3.3.5.

Como atualizar o apt com segurança

Tem uma ironia aqui: pra corrigir o apt você usa o próprio apt. Como a falha depende do retry, uma precaução simples (sugestão nossa, não está nos avisos) é desligar o retry só nos comandos da atualização:

sudo apt-get -o Acquire::Retries=0 update
sudo apt-get -o Acquire::Retries=0 install --only-upgrade apt
apt-cache policy apt

Se o download falhar por instabilidade de rede, rode de novo. Depois, siga com as atualizações normais (sudo apt upgrade). O APT não é um serviço em execução, então não precisa reiniciar nada por causa dele.

Docker e imagens de VM

Containers e imagens baseadas em Debian ou Ubuntu levam o APT junto. Até a imagem base oficial ser atualizada, dá pra garantir a versão corrigida no Dockerfile:

RUN apt-get -o Acquire::Retries=0 update \
 && apt-get -o Acquire::Retries=0 install -y --only-upgrade apt \
 && rm -rf /var/lib/apt/lists/*

E refaça a imagem puxando a base mais nova:

docker build --pull --no-cache -t minha-app .

Faça o mesmo com golden images, AMIs, templates de VM e runners de CI, senão toda máquina nova nasce vulnerável. Se você gerencia muitos containers, um painel ajuda a ver o que roda onde (falamos disso em painéis pra Docker).

Mitigação temporária se não der pra atualizar agora

Os avisos oficiais não trazem workaround. Como a Ubuntu diz que a falha exige Acquire::Retries diferente de zero, desligar o retry até o patch chegar reduz o risco (sugestão nossa):

echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-sem-retry

• Use só mirrors e proxies de confiança e evite rodar apt em redes que você não controla, como Wi-Fi público.
• Os avisos descrevem o ataque por HTTP e não dizem se fontes em HTTPS estão protegidas. Não conte com isso como solução.
• Sem retry, um download que falha não tenta de novo sozinho: pipelines de CI com rede instável podem quebrar mais.

O que checar depois do patch

• Rode apt-cache policy apt em cada servidor, container e runner de CI.
• Atualize as imagens base e templates.
• Se criou o arquivo da mitigação, pode removê-lo: sudo rm /etc/apt/apt.conf.d/99-sem-retry.
• Não há indicadores de ataque publicados. Se uma máquina instalou pacotes por uma rede, mirror ou proxy que você não controla, vale revisar o que foi instalado (/var/log/apt/history.log).

Essa é a segunda falha que dá root em Linux nas últimas semanas; se ainda não viu, confira também a falha no kernel Linux que dá root remoto.

Resumo

• O quê: CVE-2026-109518 no APT; atacante no meio do tráfego HTTP troca pacote verificado e roda código como root.
• Quem: Debian 12+, Ubuntu 22.04+ e derivados na configuração padrão; versões antigas só com retry ligado.
• O que fazer: atualizar o apt (com -o Acquire::Retries=0 no comando) e refazer imagens.

Fontes: Debian DSA-6607-1, Debian security tracker, Ubuntu CVE-2026-109518 e The Hacker News.