Nix e Lix corrigem falhas no daemon que permitem obter root localmente

Os projetos Nix e Lix divulgaram em conjunto falhas de segurança em 13 de outubro de 2026. Encadeadas, elas podem dar acesso root em máquinas que rodam seus daemons de compilação de pacotes. Versões corrigidas saíram no mesmo dia. Toda instalação multiusuário de Nix ou Lix em que usuários não confiáveis consigam acessar o daemon deve ser atualizada agora.

O Nix é um gerenciador de pacotes e sistema de build que serve de base para a distribuição Linux NixOS. O Lix é uma implementação separada do Nix. Os dois rodam um serviço em segundo plano, o daemon, que compila software em nome de usuários locais.

As falhas

O alerta conjunto no NixOS Discourse lista vários problemas. O mais grave permite que um usuário local corrompa arquivos que depois são executados como root.

Problema	Quem é afetado	Gravidade
Pedidos de «repair» (reparo) sem privilégios podem substituir arquivos do store antes de serem verificados	Instalações multiusuário em Linux e macOS	Alta, 8,4 de 10 (alerta do Nix)
Um estouro de inteiro em builtins.genList causa uma escrita na memória heap	Sistemas que avaliam código Nix não confiável	Moderada
Fuga da sandbox do macOS quando o perfil de sandbox de um build passa de um limite de tamanho	macOS com sandbox = true ou relaxed	Moderada
O instalador multiusuário deixa arquivos do store pertencendo ao usuário que fez a instalação	Instalações novas pelo instalador via script; o NixOS não é afetado	Moderada, 5,6
O daemon aceita conexões de usuários de build	macOS e FreeBSD; o Linux não é afetado	Baixa, 3,8

Do lado do Nix, foram publicados cinco alertas no GitHub. Nenhum tem ainda número CVE.

Como funciona a escalada para root

O bug principal está no modo como o daemon adiciona arquivos ao store do Nix, o diretório onde fica todo o software compilado. Segundo o alerta do Nix GHSA-jwvx-xq5j-gc56, o daemon descompactava o arquivo enviado diretamente no caminho final dele no store. Só depois verificava o hash desse arquivo.

As versões vulneráveis também deixavam usuários não confiáveis pedir um reparo («repair»), que substitui um caminho já existente no store. Se a verificação do hash falhasse, os arquivos maliciosos ficavam no disco. Quando o daemon roda como root, segundo o alerta, qualquer usuário listado em allowed-users podia executar código como root.

A falha remonta ao Nix 2.1, que adicionou uploads por streaming. A correção impede usuários não confiáveis de usar o modo de reparo. Ela também descompacta os uploads em uma pasta temporária privada e só os move para o lugar certo depois que o hash confere.

O alerta credita a descoberta a Guthrie McAfee Armstrong e a um pesquisador conhecido como joaoviictorti.

Quais versões instalar

Projeto	Versões corrigidas
Nix	2.35.3, 2.34.9, 2.31.6, 2.30.6, 2.28.8
Lix	2.95.4, 2.94.3

Segundo o alerta, os ramos do Nix sem suporte 2.29, 2.32 e 2.33 devem ser considerados vulneráveis. O Lix 2.93 e versões anteriores são afetados, mas não recebem mais manutenção. Há atualizações em andamento para os canais unstable e 26.05 do NixOS.

O gerenciador de pacotes Guix não é afetado.

Um cronograma de meses

O relato da equipe do Lix mostra quanto tempo a coordenação levou. O bug de estouro foi comunicado à equipe em 29 de julho, e as correções ficaram prontas em 29 de agosto. A cadeia de escalada de privilégios no macOS chegou em 12 de setembro, e a fuga da sandbox, em 9 de outubro.

O texto do Lix ressalta que o daemon do projeto não é uma barreira de segurança. Ele recomenda que build farms rodem o daemon como um usuário sem privilégios sempre que possível.

O Tech AI Wire cobriu no mês passado outro problema de cadeia de suprimentos: um binário strip adulterado que podia abrir uma porta dos fundos no NixOS.

O que isso significa para desenvolvedores

• Atualize todas as instalações multiusuário. Qualquer máquina em que mais de uma pessoa ou serviço converse com o daemon do Nix está exposta. Instalações de usuário único correm menos risco, mas também devem ser atualizadas.
• Use o caminho certo para atualizar o Lix. O alerta avisa que um simples nix upgrade-nix pode desinstalar o Lix 2.95.x antes de instalar a nova versão. Use o script de atualização do Lix 2.95.4 no lugar dele.
• Confira a propriedade do store depois de instalações por script. Se o Nix foi instalado com o script multiusuário, o alerta traz comandos para que todos os caminhos do store voltem a pertencer ao root.
• Audite o allowed-users. Até você atualizar, todos nessa lista podem, na prática, virar root. Reduza a lista às contas que precisam compilar.
• Trate código Nix não confiável como não confiável. Sistemas de CI que avaliam pull requests de desconhecidos podem esbarrar no bug de estouro. Rode essas avaliações em máquinas isoladas.