CISA inclui falha de escalonamento para root no Linux em catálogo de exploração ativa

CVE-2026-31431, conhecida como Copy Fail, permite que um usuário local sem privilégios corrompa o cache de páginas do núcleo e execute código com UID 0 em sistemas Linux vulneráveis.

Componente	Núcleo Linux em distribuições entregues desde 2017, com exposição associada ao subsistema AF_ALG e ao módulo algif_aead quando carregado no host.
Vetor	Execução local por usuário sem privilégios, processo comprometido em contêiner ou job malicioso de CI com acesso ao sistema vulnerável; a falha não é explorável remotamente de forma isolada.
Impacto	Corrupção controlada do cache de páginas em memória de arquivos legíveis, incluindo binários setuid, permitindo execução de código com privilégios de root.
Prioridade	Aplicar atualizações do núcleo nos ramos corrigidos ou desabilitar o recurso afetado, restringir acesso local e revisar workloads com contêineres, SSH e pipelines.
Versões	Correções informadas nos ramos 6.18.22, 6.19.12 e 7.0 do núcleo Linux.
Artefatos	Exploit público inicial em Python com 732 bytes e variantes observadas em Go e Rust em repositórios abertos.
Mitigação	Agências civis federais dos Estados Unidos receberam prazo de correção até 15 de maio de 2026; ambientes privados devem priorizar hosts multiusuário, contêineres e servidores expostos por acesso inicial.

Resumo técnico

CVE-2026-31431 é uma vulnerabilidade de escalonamento local de privilégios no núcleo Linux, classificada com CVSS 7.8, que passou a integrar o catálogo de vulnerabilidades exploradas da CISA após evidência de abuso em ambiente real. A falha, também conhecida como Copy Fail, permite que um processo sem privilégios altere o conteúdo em memória associado ao cache de páginas de arquivos legíveis. Quando o arquivo alvo é um binário privilegiado, como /usr/bin/su, essa alteração pode modificar a execução do binário sem gravar mudanças no disco, abrindo caminho para código executado com UID 0.

O risco é elevado porque o vetor exige apenas execução local, baixo privilégio e nenhuma interação do usuário. A vulnerabilidade não fornece acesso remoto por si só, mas se torna crítica quando combinada com uma etapa anterior de comprometimento, como conta SSH de baixo privilégio, shell obtido em aplicação, execução maliciosa em pipeline de CI/CD ou foothold dentro de contêiner. Em infraestruturas Linux compartilhadas, clusters Kubernetes, hosts Docker, ambientes LXC e servidores com múltiplos usuários, a falha transforma uma presença limitada em controle administrativo do sistema.

Fluxo técnico

A causa técnica envolve um bug lógico no template criptográfico de autenticação do núcleo Linux. A condição vulnerável foi formada pela interação de três mudanças separadas introduzidas em 2011, 2015 e 2017, cada uma descrita como inofensiva isoladamente, mas combinadas em um estado incorreto de transferência de recurso entre contextos internos do núcleo. Esse comportamento permite que um atacante faça uma sobrescrita controlada de 4 bytes no cache de páginas mantido pelo núcleo, atingindo dados sensíveis em memória sem depender de técnicas mais frágeis, como corrida de tempo, adivinhação de endereço ou bypass complexo de layout.

O cache de páginas representa a cópia em memória de arquivos lidos e executados pelo sistema. Ao corromper esse conteúdo, o atacante consegue influenciar o que será executado pelo processo consumidor, mesmo que o arquivo em disco permaneça intacto e sem alteração de hash persistente. A exploração pública demonstra que um payload pequeno em Python consegue acionar o caminho vulnerável e escalar privilégios de um contexto comum para root. Variantes em Go e Rust ampliam o risco operacional porque reduzem dependências de runtime e facilitam empacotamento em ferramentas usadas após acesso inicial.

Em contêineres, o ponto sensível está no acesso ao subsistema AF_ALG quando o módulo algif_aead está carregado no núcleo do host. Processos dentro de contêineres Docker, LXC ou workloads em Kubernetes podem ter acesso a esse subsistema por padrão, dependendo da configuração do host e do perfil de isolamento aplicado. Se o processo comprometido conseguir executar o exploit e o host estiver vulnerável, a falha pode romper a barreira esperada entre contêiner e máquina física, convertendo uma execução confinada em controle do host.

Superfície afetada

A superfície inclui distribuições Linux entregues desde 2017 que incorporaram o comportamento vulnerável e ainda não receberam o núcleo corrigido. O alvo mais importante não é apenas o servidor exposto diretamente à internet, mas qualquer sistema onde um atacante possa obter execução local de baixo privilégio. Isso inclui bastion hosts, servidores de build, runners de CI, nós de Kubernetes, hosts de virtualização, servidores com usuários administrativos separados e máquinas onde contas de serviço executam código de terceiros.

Ambientes de nuvem exigem atenção especial porque a presença de Linux em instâncias, imagens de contêiner, appliances virtuais e nós gerenciados aumenta a probabilidade de que um acesso inicial limitado seja suficiente para alcançar privilégios administrativos no host. A vulnerabilidade também reduz a efetividade de controles que assumem que o usuário local não privilegiado não consegue alterar binários privilegiados, pois o ataque modifica a representação em memória durante a execução e não precisa substituir o arquivo em disco.

• Hosts Linux com núcleo vulnerável e usuários locais, contas de serviço ou acesso SSH de baixo privilégio.
• Nós Docker, LXC e Kubernetes nos quais AF_ALG está acessível a processos de contêiner e algif_aead está carregado no núcleo do host.
• Servidores de CI/CD e runners capazes de executar jobs de repositórios, dependências ou scripts controlados por terceiros.
• Sistemas que dependem de binários setuid, como /usr/bin/su, e mantêm esses artefatos legíveis por usuários comuns.

Hunting e telemetria

A detecção é difícil porque a exploração usa chamadas de sistema legítimas e não exige gravação persistente no arquivo alvo. Como a alteração ocorre no cache de páginas, indicadores baseados apenas em integridade de disco podem não capturar o abuso. A telemetria deve priorizar correlação entre execução de processos sem privilégios, uso incomum de interfaces criptográficas do núcleo, chamadas relacionadas a AF_ALG, abertura de binários setuid e mudança súbita de identidade efetiva para UID 0 por processos que não seguem fluxos administrativos esperados.

Em endpoints, vale correlacionar eventos de execução de scripts curtos ou binários recém-compilados com elevação de privilégio imediata, especialmente quando o processo pai vem de shell interativo, serviço web, runner de CI, agente de automação ou processo de contêiner. Em Kubernetes e Docker, a investigação deve comparar eventos do contêiner com logs do host: um processo aparentemente isolado que precede alterações administrativas no nó, criação de usuários, carregamento de chaves SSH, modificação de unidades systemd ou implantação de binários fora do fluxo normal pode indicar uso da falha como etapa de pós-exploração.

A ausência de IoCs estáveis exige uma abordagem comportamental. Exploits públicos em Python, Go e Rust podem ser renomeados, embutidos em ferramentas maiores ou executados apenas uma vez para obter root. Procurar somente nomes de arquivos ou hashes tende a falhar. A hipótese de investigação deve começar pelo encadeamento: primeiro acesso local limitado, execução curta de artefato, interação com subsistemas do núcleo, execução de binário privilegiado e, em seguida, ações administrativas incompatíveis com a conta original.

• Processos de usuário comum que interagem com AF_ALG ou objetos associados a algif_aead antes de uma elevação para UID 0.
• Execução de scripts Python compactos, binários Go ou Rust recém-criados em /tmp, diretórios de workspace, cache de CI ou camadas graváveis de contêiner.
• Chamadas a binários setuid, como /usr/bin/su, logo após atividade anômala de processo sem privilégio.
• Eventos de contêiner seguidos por criação de processos root no host, alteração de permissões, instalação de chaves ou persistência via systemd, cron ou arquivos de inicialização.
• Divergência entre integridade em disco preservada e comportamento de execução incompatível com o binário esperado.

Mitigação

A resposta prioritária é instalar os pacotes de núcleo corrigidos fornecidos pela distribuição e reiniciar os sistemas afetados para garantir que o núcleo ativo foi substituído. As correções estão associadas aos ramos 6.18.22, 6.19.12 e 7.0, mas a validação deve ser feita pelo pacote específico do fornecedor da distribuição, pois backports podem manter numeração diferente. Inventários devem identificar o núcleo em execução, não apenas o pacote instalado, porque servidores sem reinicialização podem permanecer vulneráveis após atualização.

Quando a atualização imediata não for possível, a contenção deve reduzir a chance de execução local e limitar o caminho de abuso. Isso inclui restringir SSH a contas necessárias, remover usuários obsoletos, limitar execução de código em runners, revisar permissões de contas de serviço, aplicar isolamento de rede e endurecer perfis de contêiner. Em hosts com workloads conteinerizados, administradores devem revisar exposição a AF_ALG, disponibilidade de algif_aead, capacidades concedidas a contêineres e políticas que permitam workloads não confiáveis em nós compartilhados.

Depois da correção, a validação deve incluir busca retroativa por sinais de exploração antes da janela de patch. Como a falha pode alterar execução sem tocar o disco, a equipe deve revisar logs de identidade, EDR, auditoria do núcleo, eventos de contêiner, histórico de CI/CD e mudanças administrativas ocorridas por contas de baixo privilégio. Se houver suspeita de exploração, a resposta deve tratar o host como potencialmente comprometido em nível root: coletar evidências voláteis quando possível, isolar o sistema, rotacionar credenciais usadas localmente, revisar chaves SSH, tokens de pipeline e segredos montados em contêineres, e reconstruir imagens ou nós quando a integridade não puder ser demonstrada.

• Atualizar o núcleo pela distribuição, reiniciar o host e confirmar a versão efetivamente carregada com comando local apropriado.
• Priorizar hosts multiusuário, nós Kubernetes, servidores Docker/LXC, runners de CI/CD e sistemas com acesso SSH de baixo privilégio.
• Restringir execução local desnecessária, remover contas sem uso e limitar jobs capazes de executar código arbitrário.
• Revisar acesso de contêineres ao subsistema AF_ALG e a presença do módulo algif_aead no núcleo do host.
• Rotacionar credenciais e segredos acessíveis no host se houver evidência de elevação, persistência ou ações administrativas anômalas.