CVE-2026-31431 Copy Fail explicada

CVE-2026-31431 Copy Fail e uma vulnerabilidade de escalacao local de privilegios no kernel Linux que passou muito rapidamente de divulgacao tecnica para prioridade operacional. Em 19 de agosto de 2026, o registro oficial mostra uma falha de alta severidade no componente algif_aead, pacotes de kernel corrigidos publicados por todos os grandes distribuidores Linux e a sua inclusao no catalogo CISA Known Exploited Vulnerabilities desde 1 de maio de 2026. O quadro mudou desde a divulgacao: as mitigacoes temporarias de desativacao de modulo publicadas no final de abril foram uma solucao paliativa, e os fornecedores ja distribuiram kernels corrigidos e comecaram a retirar essas mitigacoes.

Este artigo permanece deliberadamente estreito. Ele nao reproduz o exploit, nao estima prevalencia e nao repete claims de terceiros sobre confiabilidade. Ele se limita ao que as fontes oficiais realmente confirmam: o que a vulnerabilidade afeta, onde a exposicao pesa mais, quais mitigacoes temporarias existem e como validar o estado do patch sem criar pontos cegos nem regressoes operacionais.

Para o processo mais amplo de auditoria de ambientes isolados, veja Auditoria de seguranca de uma rede air-gapped: como auditar um ambiente isolado sem falsa confianca. Para um guia complementar sobre workflows e ferramentas offline-capable, veja Quais ferramentas de seguranca funcionam em redes isoladas sem acesso a internet? Guia pratico de workflows de seguranca offline-capable.

O que e CVE-2026-31431 (Copy Fail)?

CVE-2026-31431 e uma vulnerabilidade do kernel Linux em algif_aead, um componente ligado a interface criptografica do kernel. O registro do NVD herda a descricao upstream do caminho de correcao: o comportamento vulneravel e corrigido ao devolver algif_aead para operacao out-of-place em vez de manter a logica mais complexa in-place introduzida antes.

A severidade oficial que mais importa para defensores agora e a pontuacao kernel CNA de CVSS 3.1 7.8 HIGH, com o vetor AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. O NVD lista duas classificacoes de vulnerabilidade de origens diferentes — CWE-669 (Incorrect Resource Transfer Between Spheres, a classificacao tambem usada pela CISA na KEV) e CWE-1288 (Improper Validation of Consistency within Input, atribuida pela Red Hat) — e lista oito referencias de patch kernel.org ligadas a branches estaveis.

No eixo das versoes, o registro upstream e explicito. A regressao foi introduzida pelo commit 72548b093ee3, portanto a CVE afeta o Linux 4.14 e posteriores, com correcoes nas releases estaveis 5.10.254, 5.15.204, 6.1.170, 6.6.137, 6.12.85, 6.18.22 e 6.19.12. As distribuicoes mapeiam isso para suas proprias versoes de pacote: a Ubuntu afirma que o problema afeta todas as releases anteriores a Resolute (26.04), e a SUSE afirma que afeta kernels 4.14 e mais recentes, do SLES 12 SP5 ate o SLES 16.0, com o SLES 11 antigo demais para ser afetado.

Do ponto de vista operacional, os fornecedores estao tratando isso como um problema de local privilege escalation no kernel Linux. Isso importa porque escalacao local de privilegios nao e uma fronteira puramente academica. Se um atacante ja tiver execucao de codigo como usuario normal, ou puder executar uma carga nao confiavel no lugar errado, um caminho confiavel ate root pode alterar muito rapidamente a fronteira de confianca de um bastion, de um host compartilhado ou de um no de containers.

O que os advisories oficiais confirmam ate agora

O quadro oficial ja esta suficientemente claro para sustentar uma triagem imediata.

Fonte	O que confirma	Porque importa
NVD / kernel CNA	`algif_aead` e o componente afetado; a pontuacao CNA CVSS e 7.8 HIGH; o NVD mostra a CVE na CISA KEV.	Estabelece o identificador tecnico, a severidade e o sinal atual de priorizacao.
Ubuntu	Data de divulgacao publica 29 de abril de 2026; advisory publicado em 30 de abril de 2026 e atualizado desde entao: pacotes de kernel corrigidos estao disponiveis para todas as releases suportadas, e a mitigacao temporaria via `kmod` esta sendo revertida. Impacto enquadrado como local privilege escalation, com a parte de containers tratada separadamente.	Fornece versoes corrigidas por release, orientacao defensiva concreta e caveats operacionais.
SUSE	A pagina CVE publica da SUSE classifica o problema como important e marca o estado geral como Resolved, listando os advisories SUSE-SU publicados por produto; a SUSE tambem publicou atualizacoes em 3 de maio de 2026 para todas as distribuicoes SUSE Linux Enterprise e openSUSE Leap mantidas.	Util para validacao em nivel de pacote e triagem de frota.
Red Hat	O boletim de seguranca `RHSB-2026-002` esta classificado como Important e o seu estado agora e Resolved: "All fixes are now available." Existem artigos de acompanhamento separados para RHEL, OpenShift e ROSA, mas sao exclusivos para assinantes.	Confirma que o fornecedor encerrou o problema e mostra onde estao os passos especificos por produto.

Um segundo sinal operacional e o status KEV. O NVD observa explicitamente que essa CVE esta no catalogo CISA Known Exploited Vulnerabilities, com Date Added: May 1, 2026 e Due Date: May 15, 2026. Mesmo que sua organizacao nao siga prazos federais dos EUA, isso continua sendo um sinal de priorizacao util: a vulnerabilidade ja nao e apenas "nova" ou "interessante". Ela ja esta na classe de problemas que defensores devem tratar como urgentes.

Essa listagem nao e especulativa. O boletim da Red Hat publica uma linha do tempo de remediacao segundo a qual quem reportou publicou um post de blog, um write-up tecnico e uma prova de conceito em 29 de abril de 2026, que um modulo Metasploit foi publicado no mesmo dia, e que a CISA adicionou a CVE a KEV dois dias depois. A Ubuntu confirma que o exploit publicado visa implantacoes sem workloads containerizados. Este artigo nao reproduz nada disso — mas um exploit publico funcional e um sinal de triagem, e explica por que os cronogramas dos fornecedores se comprimiram dessa forma.

Onde Copy Fail mais importa

Nao se trata de uma falha edge exposta a Internet e exploravel sem autenticacao. A exposicao depende da existencia de um ponto de apoio local ou de um caminho de execucao num sistema Linux. Ainda assim, isso deixa varios cenarios de alto valor.

Hosts com usuarios locais ou execucao local de codigo

A Ubuntu afirma que, em implantacoes sem workloads containerizados, a vulnerabilidade permite a um usuario local elevar privilegios ate root. Isso significa que a primeira pergunta nao e "Meu servico exposto a Internet e diretamente exploravel de fora?" A primeira pergunta e se o host ja pode executar codigo nao confiavel ou semi-confiavel sob uma conta de baixo privilegio.

Exemplos tipicos incluem:

hosts Linux administrativos compartilhados
bastions ou jump hosts usados por varias equipes
runners de CI e sistemas de build
servidores multiusuario com acesso shell
servidores de administracao adjacentes a infraestrutura de identidade

Ambientes containerizados

A Ubuntu tambem documenta uma preocupacao separada para implantacoes containerizadas que possam executar workloads potencialmente maliciosos: a vulnerabilidade pode facilitar container escape scenarios. O boletim RHSB-2026-002 da Red Hat traz secoes de mitigacao especificas por produto para OpenShift 4 e para OpenShift gerenciado (ROSA Classic, ROSA HCP, ARO e OpenShift Dedicated), o que confirma que o fornecedor trata plataformas de containers como um trilho operacional proprio. A SUSE faz a mesma distincao pelo outro lado: Rancher Prime, RKE2 e K3s nao sao diretamente afetados, mas containers privilegiados executando workloads nao confiaveis ainda podem ser um caminho ate a falha do kernel, por isso a SUSE aponta para Pod Security Admission e controles equivalentes em vez de um patch de produto.

Essa distincao importa. Uma equipe de frota nao deve escrever "container escape" como claim geral para qualquer implantacao Kubernetes ou containerizada. A formulacao correta e mais estreita: a documentacao do fornecedor diz que ambientes containerizados merecem atencao separada e que a triagem de nos de containers nao deve ser misturada com uma fila simples de patching de workstations e servidores.

Sistemas administrativos e sistemas adjacentes a identidade

Mesmo sendo uma vulnerabilidade do kernel Linux e nao uma vulnerabilidade de Active Directory ou Entra, root local no host Linux errado continua a importar para equipes de identidade e infraestrutura. Bastions, nos de provisioning, runners de automacao, appliances VPN, PAM jump hosts e sistemas Linux usados para administrar Windows ou infraestrutura cloud fazem parte do plano efetivo de identidade. Uma escalacao local de privilegios nesses pontos pode mudar o modelo de confianca em torno de credentials, tokens, chaves de gestao e caminhos de automacao.

Esse tambem e o motivo pelo qual equipes que ja executam Auditar a seguranca do Active Directory: checklist pratica ou Endurecimento do Active Directory: o que bloquear primeiro e como validar nao deveriam tratar hosts Linux administrativos como estando fora do perimetro de garantia de identidade. Se seus caminhos administrativos ja derivam com o tempo, o mesmo padrao operacional descrito em Desvio de acesso privilegiado no Active Directory: como os direitos admin voltam depois de auditorias costuma aplicar-se tambem a bastions e a tooling Linux adjacente.

Mitigacoes temporarias e seus tradeoffs

A historia da mitigacao temporaria e importante porque a orientacao oficial do fornecedor nao a descreve como um simples interruptor neutro.

No momento da divulgacao, a equipe de seguranca da Ubuntu publicou uma mitigacao que desativa o modulo afetado algif_aead por meio do pacote kmod. A Ubuntu ja atualizou esse advisory: pacotes de kernel corrigidos ja estao disponiveis e a mitigacao via kmod sera revertida, portanto bloquear o modulo e um fallback para hosts que ainda nao podem aplicar a atualizacao de kernel, nao o destino final. A SUSE documenta um workaround equivalente via modprobe (blacklist algif_aead mais install algif_aead /bin/false) e ja publicou atualizacoes para todas as distribuicoes SUSE Linux Enterprise e openSUSE Leap mantidas.

A Red Hat e a excecao que vale a pena conhecer. No RHEL, o codigo afetado esta compilado dentro do kernel e nao pode ser bloqueado como modulo; o paliativo documentado e, por isso, um argumento de boot — initcall_blacklist=algif_aead_init, ou initcall_blacklist=af_alg_init para bloquear totalmente a interface AF_ALG — com um aviso explicito sobre o impacto de performance em qualquer coisa que use funcoes criptograficas do kernel. Uma regra modprobe copiada de um runbook Debian ou SUSE nao tem nenhum efeito ali.

Cada uma dessas opcoes ganha tempo, e cada uma vem com tradeoffs.

A mitigacao nao e neutra no comportamento

A Ubuntu adverte explicitamente que a mitigacao desativa um modulo usado para aceleracao criptografica por hardware. O comportamento esperado e um fallback para funcoes criptograficas em userspace, mas a Ubuntu tambem observa que algumas aplicacoes podem nao lidar bem com essa transicao. Alem disso, aplicacoes ja em execucao podem ser afetadas se o modulo for desativado ou descarregado, e um reboot pode ser necessario para forcar um comportamento de fallback consistente.

Isso significa que a decisao de mitigacao deve ser tratada como uma alteracao operacional real, nao como um simples flag de emergencia sem efeito colateral.

Etapa de mitigacao	Beneficio	Tradeoff a validar
Desativar `algif_aead` via mitigacao fornecida pelo fornecedor	Reduz a exposicao antes que todos os fixes do kernel estejam totalmente implantados	Pode afetar comportamento criptografico acelerado por hardware e processos de longa duracao; nao disponivel como bloqueio de modulo no RHEL, onde e necessario um argumento de boot
Descarregar o modulo imediatamente	Pode encurtar a janela de exposicao em sistemas em execucao	Pode exigir validacao de servico ou reboot para garantir caminhos de fallback ativos
Aplicar pacotes de kernel corrigidos	Elimina a necessidade de uma postura baseada apenas em workaround	Exige disciplina padrao de rollout de kernel, planejamento de reboot e validacao de versao

A regra pratica e simples: se voce usar o workaround, documente que ele e temporario, valide aplicacoes dependentes de criptografia e confirme depois que o sistema atinge um estado de kernel corrigido em vez de permanecer indefinidamente numa postura de mitigacao temporaria.

Como verificar exposicao e estado do patch

A sequencia mais segura e vendor-first. Nao assuma que um simples headline de versao de kernel visto em redes sociais basta para determinar se uma frota esta exposta.

Verificacoes em Ubuntu

A Ubuntu fornece comandos concretos em seu advisory:

uname -r

dpkg -l 'linux-image*' | grep ^ii

dpkg -l kmod

A Ubuntu tambem documenta como verificar se o modulo afetado ainda esta carregado:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Essas verificacoes sao uteis mesmo para alem da Ubuntu porque refletem a logica correta: verificar o kernel em execucao, verificar os pacotes instalados e verificar separadamente o estado do modulo.

Verificacoes em SUSE

A SUSE expoe uma pagina CVE publica com estado de produto/pacote e versoes corrigidas publicadas. Para ambientes geridos por SUSE, o caminho autoritativo e comparar os pacotes relacionados ao kernel instalados com as versoes listadas na pagina CVE e nos advisories vinculados, em vez de confiar numa formulacao generica por familia de distribuicao.

Verificacoes em Red Hat

O boletim RHSB-2026-002 da Red Hat esta agora marcado como Resolved e declara que todos os fixes estao disponiveis. Duas paginas da Red Hat sao realmente publicas e trazem o estado autoritativo do produto: o proprio boletim e a pagina CVE da Red Hat para CVE-2026-31431, que lista os produtos afetados, as erratas publicadas, a classificacao Important da propria Red Hat e a sua atribuicao de CWE. Os artigos de how-to sobre RHEL, OpenShift 4 e ROSA/OpenShift Dedicated linkados a partir dessas paginas sao conteudo exclusivo para assinantes, portanto um engenheiro enviado a eles precisa primeiro de uma conta Red Hat.

O que registrar durante a triagem

Para cada sistema ou grupo de clusters, registrar pelo menos:

versao atual do kernel em execucao
versao do pacote de kernel instalado
se algif_aead esta carregado
se uma mitigacao temporaria foi aplicada
estado do advisory do fornecedor para aquela linha de produto
se ainda ha reboot pendente apos patch ou mitigacao

Isso basta para transformar um headline ruidoso sobre vulnerabilidade numa fila real de remediacao. Se voce ja executa revisoes recorrentes de infraestrutura, a mesma disciplina de evidencia descrita em Auditoria recorrente de Active Directory: por que as auditorias anuais derivam e como funciona o monitoramento continuo de postura se aplica aqui: capturar o estado, repetir a verificacao apos a remediacao e manter a prova de que a mitigacao temporaria foi realmente retirada.

O que validar depois de aplicar os fixes

Uma resposta a Copy Fail nao deve terminar em "o pacote foi atualizado". A fase de validacao e o lugar em que mais se escondem mitigacoes temporarias, reboots pendentes e rollouts parciais.

Area de validacao	Como e o sucesso
Estado do kernel em execucao	O host esta realmente executando o kernel corrigido esperado e nao apenas carregando o pacote no disco.
Estado do modulo	`algif_aead` esta desativado ou ausente onde a mitigacao temporaria ainda e necessaria, e seu estado e compreendido apos o patch completo — incluindo reverter a mitigacao assim que o kernel corrigido estiver em execucao, que e o que a Ubuntu agora instrui.
Estado de reboot	Sistemas que precisam de reboot para completar a mitigacao ou ativar o kernel corrigido nao ficam em estado ambiguo.
Comportamento da aplicacao	Servicos dependentes de criptografia continuam a funcionar corretamente depois da desativacao do modulo ou substituicao do kernel.
Postura de nos de containers	Nos que hospedam workloads containerizadas sao verificados pelo caminho do fornecedor para OpenShift, ROSA, OSD ou a orientacao especifica da distribuicao relevante.
Evidencia de frota	Cada ambiente possui uma fonte de fornecedor registrada, um estado de patch e uma acao residual se o workaround ainda estiver no lugar.

O erro operacional central seria tratar o workaround como identico a um fix totalmente validado. A documentacao do fornecedor nao apoia isso. O workaround compra tempo; o kernel corrigido e a validacao pos-mudanca fecham o ciclo. Para visibilidade de logs e escalonamento em torno de sistemas de identidade adjacentes, isso pode ser combinado com Monitoramento de seguranca AD: eventos que importam quando o host Linux afetado esta num caminho administrativo ou alimenta uma revisao de incidente mais ampla.

Por que essa CVE continua importante para equipes de identidade e infraestrutura

Copy Fail nao pertence ao catalogo de vulnerabilidades AD/Azure da EtcSec, e este artigo nao deve fingir o contrario. Mas continua importante para equipes de identidade e infraestrutura porque root local no sistema Linux errado muda mais do que um unico host.

Exemplos:

bastions usados para administrar Windows ou infraestrutura cloud
nos Linux que guardam credentials de automacao ou segredos de configuracao
nos OpenShift ou de containers adjacentes a fronteiras internas de confianca
jump systems em ambientes segmentados ou air-gapped

Esse e o motivo correto para cobrir essa CVE aqui. Nao porque ela se encaixa de forma limpa no catalogo existente, mas porque a confianca da infraestrutura, os caminhos administrativos e a evidencia de remediacao continuam importantes quando o sistema afetado esta proximo do plano de identidade.

CVE-2026-31431 (Copy Fail): o que a vulnerabilidade do kernel Linux afeta e como mitiga-la