Como Corrigir a Vulnerabilidade APT CVE-2026-109518

O APT, gerenciador de pacotes usado no Debian, Ubuntu e derivados, recebeu correção para a vulnerabilidade APT registrada como CVE-2026-109518. A severidade é High, com score CVSS 4.0 de 7.7 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N).

O problema fica no backend HTTP da biblioteca APT e afeta qualquer frontend baseado nela: apt, apt-get, aptitude e os aplicativos gráficos do Ubuntu. Quem controla o tráfego HTTP entre a máquina e o servidor de arquivos pode trocar um pacote e fazer o APT instalar o.deb do atacante, mesmo que a verificação de assinatura falhe.

O que a vulnerabilidade APT permite fazer

O esquema de assinatura do arquivo de pacotes existe justamente para impedir esse tipo de substituição. A falha contorna essa checagem e engana o APT para que ele conclua a instalação de um pacote não assinado.

Como os scripts do.deb rodam com privilégios de root, o resultado é execução de código como root no host alvo. Um mirror malicioso também consegue usar o mesmo caminho para entregar pacotes não assinados, o que é justamente o motivo pelo qual a documentação trata download de.deb não confiável como comprometimento do sistema.

A exploração exige que o cliente repita um download que falhou. Esse comportamento é controlado pela configuração Acquire::Retries do APT: com o valor em 0, não há retry e a falha não é explorável.

Quais releases estão expostas

No Ubuntu, o valor de Acquire::Retries é diferente de zero por padrão a partir do 22.04 LTS (Jammy). Releases anteriores só são afetadas se essa configuração tiver sido alterada manualmente. As versões corrigidas estão publicadas no aviso de segurança USN-8996-1:

• 26.10 (Stonking): apt 3.3.3ubuntu0.1
• 26.04 LTS (Resolute): apt 3.2.1ubuntu0.1
• 24.04 LTS (Noble): apt 2.8.4ubuntu0.1
• 22.04 LTS (Jammy): apt 2.4.15ubuntu0.1
• 20.04 LTS (Focal): apt 2.0.12+esm1
• 18.04 LTS (Bionic): apt 1.6.19+esm1
• 16.04 LTS (Xenial): apt 1.2.36+esm1
• 14.04 LTS (Trusty): apt 1.0.1ubuntu2.24+esm4

Snap não é afetado, porque usa outro sistema de pacotes. FTP também não entra no vetor, e o uso de HTTPS bloqueia a exploração, já que o ataque depende de manipular tráfego HTTP em texto claro.

Como verificar e aplicar a correção

A checagem compara a versão instalada do source package apt com a tabela acima. O comando consulta o campo de pacote de origem direto no banco local do APT:

Apt list --installed '?source-package(^apt$)'

Para instalar a atualização, a recomendação é fixar Acquire::Retries em zero durante a execução. Isso elimina a janela de exploração enquanto o próprio APT é atualizado, seja por atacante on-path, seja por mirror comprometido.

Sudo apt update && sudo apt upgrade -o Acquire::Retries=0

Se a atualização completa não for possível no momento, dá para mirar apenas o componente afetado, mantendo o mesmo parâmetro:

Sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'`

O unattended-upgrades já vem habilitado a partir do 16.04 LTS e aplica atualizações de segurança a cada 24 horas, então hosts com esse serviço ativo recebem o patch dentro desse intervalo.

TLS no APT como mitigação

Trocar http:// por https:// nos sources reduz a exposição enquanto o patch não é aplicado, e o ajuste vale apenas para os domínios oficiais do arquivo Ubuntu. O comando abaixo edita tanto o /etc/apt/sources.list quanto os arquivos em /etc/apt/sources.list.d, nos formatos.list e.sources:

Sudo sed -Ei 's!http://((([a-z]+\.)?archive|security|ports)\.ubuntu\.com)!https://\1!' /etc/apt/sources.list /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources

Depois rode sudo apt update e confirme que não houve erro. Alguns mirrors comunitários, inclusive espelhos por país, não respondem em HTTPS e vão falhar nessa etapa. a assinatura de arquivo continua sendo uma proteção mais forte que o TLS, porque valida o conteúdo de ponta a ponta e não apenas o transporte.

Containers e painéis

Imagens de contêiner herdaram a versão do APT da base usada na construção. Rebuild não resolve sozinho: é preciso atualizar a imagem base e regerar as camadas derivadas. Distribuições que usam dnf e rpm, como RHEL, AlmaLinux e Rocky, não passam pelo backend HTTP do APT e não são expostas por esse vetor. Por isso, painéis como o cPanel, que rodam sobre base RHEL, não têm exposição por essa falha. Em hosts Debian e Ubuntu com painel, o caminho é o mesmo: atualizar o pacote apt.

Conclusão

A correção existe para todas as releases Ubuntu listadas, com versões explícitas por suíte, e a aplicação é um upgrade comum de pacote. O detalhe operacional que decide a exposição é o Acquire::Retries: onde ele é diferente de zero, o retry abre o caminho para o ataque. Enquanto o patch não estiver aplicado, HTTPS nos sources e retries em zero fecham a janela.

Fonte: https://ubuntu.com/blog/apt-vulnerability-fixes-available