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 2 de maio de 2026, o registro oficial mostra uma falha de alta severidade no componente algif_aead, mitigacoes publicadas por grandes distribuidores Linux e a sua inclusao no catalogo CISA Known Exploited Vulnerabilities em 1 de maio de 2026.

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 tambem mostra a classificacao CWE-669 e lista varias referencias de patch kernel.org ligadas a branches estaveis.

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; artigo de mitigacao publicado em 30 de abril de 2026; impacto enquadrado como local privilege escalation, com a parte de containers tratada separadamente.	Fornece orientacao defensiva concreta e caveats operacionais.
SUSE	O estado de produto e pacote e exposto publicamente na pagina CVE da SUSE, com referencias de workaround e advisory.	Util para validacao em nivel de pacote e triagem de frota.
Red Hat	O boletim publico `RHSB-2026-02` aparece como Important e Ongoing; existem paginas publicas separadas para RHEL e OpenShift.	Confirma tratamento ativo do fornecedor e caminhos 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.

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. A orientacao publica da Red Hat para OpenShift e ROSA confirma que o fornecedor trata a exposicao managed e OpenShift como um trilho operacional separado, o que e o enquadramento defensivo correto.

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.

A Ubuntu informa que sua equipe de seguranca publicou uma mitigacao que desativa o modulo afetado algif_aead por meio do pacote kmod enquanto os pacotes de kernel corrigidos sao distribuídos. A SUSE documenta um workaround semelhante que bloqueia o modulo por configuracao modprobe.

Isso e util, mas 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
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

A pagina publica de boletins da Red Hat mostra RHSB-2026-02 como ongoing, e a Red Hat tambem publica orientacoes publicas sobre como determinar se um produto e afetado por uma CVE especifica usando a base de dados CVE da Red Hat e os links de advisory associados. A Red Hat tambem publicou paginas publicas separadas para RHEL e OpenShift sobre CVE-2026-31431, que e o caminho correto para validacao por produto.

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.
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