Estudo de Caso completo — Como foi descoberta, como funciona, como testar, como replicar (em ambiente seguro) e como corrigir a vulnerabilidade crítica que afeta quase todas as distribuições Linux desde 2017.
Este repositório tem fins exclusivamente educacionais. As informações aqui presentes são voltadas para profissionais de segurança, pesquisadores e estudantes de cibersegurança. Nunca utilize qualquer técnica descrita aqui em sistemas sem autorização explícita. O uso indevido dessas informações pode configurar crime previsto na Lei nº 12.737/2012 (Lei Carolina Dieckmann) e no Marco Civil da Internet (Lei nº 12.965/2014).
- Visão Geral
- Como Foi Descoberta
- Como a Vulnerabilidade Funciona
- Sistemas Afetados
- Cenários de Exploração
- Como Testar (Lab Seguro)
- Replicando o Exploit
- Como Corrigir
- Indicadores de Comprometimento (IOCs)
- Lições Aprendidas
- Referências
| Campo | Detalhe |
|---|---|
| CVE ID | CVE-2026-31431 |
| Apelido | CopyFail |
| Tipo | Local Privilege Escalation (LPE) — Escalada de Privilégio |
| CVSS Score | 8.8 (High) / potencialmente Crítico em cadeia |
| Componente | Linux Kernel — mecanismo de cópia de dados |
| Versões | Kernel Linux ≤ 7.0 (distribuições desde 2017) |
| Descoberto por | Theori (empresa de segurança) |
| Divulgado em | Março de 2026 |
| Patch upstream | Disponível ~1 semana após divulgação responsável |
| Status CISA | Catalogado como explorado ativamente — KEV Catalog |
| Prazo CISA | Agências federais devem corrigir até 15/05/2026 |
A vulnerabilidade CopyFail foi descoberta pela empresa de segurança Theori durante análise de código do kernel Linux, especificamente no subsistema responsável por copiar dados entre espaços de memória.
Março/2026 → Pesquisadores da Theori identificam comportamento anômalo no kernel
Março/2026 → Divulgação responsável (Responsible Disclosure) à equipe de segurança do kernel
~1 semana depois → Patch upstream disponível no kernel.org
Maio/2026 → Código de exploração (PoC) divulgado publicamente
01/05/2026 → Microsoft publica análise técnica
04/05/2026 → CISA adiciona ao KEV Catalog (Known Exploited Vulnerabilities)
15/05/2026 → Prazo para correção em agências federais dos EUA
O kernel Linux possui rotinas internas responsáveis por copiar dados entre diferentes regiões de memória (userspace ↔ kernelspace). A falha recebe o nome CopyFail porque o componente afetado deixa de copiar determinados dados quando deveria. Isso corrompe estruturas de dados sensíveis dentro do kernel, abrindo uma janela de exploração para escalada de privilégio.
O Linux kernel gerencia memória em dois espaços distintos:
- Userspace: onde processos normais (usuários) operam, com acesso restrito
- Kernelspace: espaço privilegiado, com acesso total ao hardware e aos dados do sistema
┌─────────────────────────────────────┐
│ USERSPACE │
│ Processo do Atacante (uid=1000) │
│ → chama syscall maliciosa │
└────────────────┬────────────────────┘
│ syscall
▼
┌─────────────────────────────────────┐
│ KERNELSPACE │
│ Rotina de cópia de dados │
│ → BUG: falha em copiar metadados │
│ → corrompe estrutura de controle │
│ → atacante manipula ponteiro │
│ → executa código como root │
└─────────────────────────────────────┘
- Trigger: O atacante (usuário local sem privilégios) invoca uma syscall específica que aciona a rotina de cópia defeituosa
- Corruption: A falha ao copiar dados corrompe uma estrutura de controle do kernel (ex: struct de credenciais ou ponteiro de função)
- Control Flow Hijack: O atacante aproveita a corrupção para redirecionar a execução do kernel
- Privilege Escalation: O processo do atacante passa a rodar com
uid=0(root), obtendo controle total do sistema
// Versão VULNERÁVEL (simplificada, didática)
int kernel_copy_data(struct user_request *req) {
struct kernel_buffer kbuf;
// BUG: copia apenas parte dos dados, ignorando campos críticos
// Campos de segurança (security_context) não são copiados!
memcpy(&kbuf.data, req->data, req->size);
// → kbuf.security_context permanece não inicializado (lixo de memória)
process_buffer(&kbuf); // usa dados corrompidos
return 0;
}
// Versão CORRIGIDA
int kernel_copy_data(struct user_request *req) {
struct kernel_buffer kbuf;
// FIX: copia o struct inteiro, incluindo campos de segurança
if (copy_from_user(&kbuf, req, sizeof(struct kernel_buffer)))
return -EFAULT;
process_buffer(&kbuf);
return 0;
}| Distribuição | Versão | Status |
|---|---|---|
| Red Hat Enterprise Linux | 10.1 | ✅ Vulnerável |
| Ubuntu LTS | 24.04 | ✅ Vulnerável |
| Amazon Linux | 2023 | ✅ Vulnerável |
| SUSE Linux | 16 | ✅ Vulnerável |
| Debian | Estável recente | ✅ Vulnerável |
| Fedora | Recente | ✅ Vulnerável |
| Kubernetes (nodes) | Todos sobre kernel ≤7.0 | ✅ Vulnerável |
⚠️ Qualquer distribuição Linux rodando kernel ≤ 7.0 expedida desde 2017 é potencialmente vulnerável.
Um usuário sem privilégios em um servidor compartilhado (ex: ambiente de hospedagem, VPS) executa o exploit e obtém root.
Internet → [RCE via vulnerabilidade web] → shell limitado → [CopyFail] → root
Conforme análise da Microsoft: a falha pode ser encadeada com um exploit entregue pela internet (ex: RCE em aplicação web), resultando em comprometimento total do servidor.
Usuário Linux é enganado a abrir link ou anexo malicioso que aciona o exploit localmente.
Ator malicioso compromete conta de desenvolvedor open source e injeta o exploit em código amplamente distribuído.
Servidor em nuvem comprometido pode expor todas as VMs, containers, aplicações e bancos de dados de clientes na mesma infraestrutura.
⚠️ SOMENTE em ambiente controlado e isolado — VM sem acesso à rede externa!
# Ferramentas necessárias
sudo apt install -y git build-essential libssl-dev bc flex bison
# Verificar versão do kernel atual
uname -r
# Verificar se está na faixa vulnerável (≤ 7.0)
# Exemplo de saída vulnerável: 6.8.0-51-generic# 1. Criar VM isolada (recomendado: VirtualBox ou QEMU)
# Use uma ISO de Ubuntu 24.04 ou Debian Bookworm
# 2. Confirmar que a VM NÃO tem acesso à internet de produção
# (use rede host-only ou NAT isolado)
# 3. Criar usuário sem privilégios para simular atacante
sudo adduser testuser
su - testuser
# 4. Verificar que testuser não tem sudo
sudo whoami # deve retornar: "testuser is not in the sudoers file"# Script de verificação (NÃO explora, apenas verifica)
#!/bin/bash
KERNEL_VERSION=$(uname -r | cut -d. -f1,2)
MAJOR=$(echo $KERNEL_VERSION | cut -d. -f1)
MINOR=$(echo $KERNEL_VERSION | cut -d. -f2)
echo "[*] Kernel detectado: $(uname -r)"
if [ "$MAJOR" -lt 7 ] || ([ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 0 ]); then
echo "[!] POTENCIALMENTE VULNERÁVEL ao CVE-2026-31431 (CopyFail)"
echo "[!] Verifique se o patch foi aplicado pelo seu fornecedor de distribuição"
else
echo "[+] Versão do kernel fora do range afetado"
fi
# Verificar se patch foi aplicado (via changelogs do pacote)
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i "CVE-2026-31431" && \
echo "[+] Patch CVE-2026-31431 encontrado no changelog" || \
echo "[?] Patch não detectado no changelog — verifique manualmente"🔒 Esta seção é estritamente educacional. O código abaixo é uma representação didática simplificada do vetor de ataque — não é o exploit real (que não é divulgado aqui por razões éticas).
#!/usr/bin/env python3
"""
CVE-2026-31431 (CopyFail) — Representação Didática
Propósito: Educação em segurança ofensiva/defensiva
NÃO USE EM SISTEMAS SEM AUTORIZAÇÃO
"""
import ctypes
import os
import sys
def check_environment():
"""Verifica se estamos em ambiente de lab"""
kernel = os.uname().release
print(f"[*] Kernel: {kernel}")
print(f"[*] UID atual: {os.getuid()}")
if os.getuid() == 0:
print("[-] Já somos root. Exploit não necessário.")
sys.exit(0)
def demonstrate_concept():
"""
Demonstração conceitual do vetor de ataque:
1. Identificar a syscall vulnerável
2. Construir payload que aciona a cópia incompleta
3. Monitorar corrupção de memória
4. Redirecionar fluxo para escalar privilégio
Em um exploit real:
- O atacante usa técnicas como heap spray ou ROP chains
- Abusa da janela entre a corrupção e o uso do dado corrompido
- Sobrescreve credenciais do processo (uid → 0)
"""
print("[*] Conceito: trigger da rotina de cópia defeituosa")
print("[*] Conceito: monitorar corrupção de struct kernel_buffer")
print("[*] Conceito: redirecionamento de fluxo de execução")
print("[*] Ver: https://xint.io/blog/copy-fail-linux-distributions")
def main():
check_environment()
demonstrate_concept()
print("\n[i] Para análise técnica completa, consulte:")
print(" → https://xint.io/blog/copy-fail-linux-distributions")
print(" → https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation/")
if __name__ == "__main__":
main()# Em terminal separado, monitorar logs do kernel
sudo dmesg -w | grep -E "(oops|panic|null pointer|exploit|cve)"
# Monitorar chamadas de sistema
sudo strace -e trace=all -p <PID_DO_PROCESSO>
# Verificar alterações de UID em tempo real
watch -n 0.5 'cat /proc/self/status | grep -E "^(Uid|Gid)"'# Ubuntu / Debian
sudo apt update && sudo apt upgrade -y linux-image-generic
sudo reboot
# Verificar versão após reinicialização
uname -r
# Red Hat / CentOS / Amazon Linux
sudo dnf update -y kernel
sudo reboot
# SUSE
sudo zypper update -t package kernel-default
sudo reboot# Checar changelog do kernel instalado
apt changelog linux-image-$(uname -r) | grep CVE-2026-31431
# Via CVE tracker do Ubuntu
# https://ubuntu.com/security/CVE-2026-31431
# Via Red Hat CVE Database
# https://access.redhat.com/security/cve/CVE-2026-31431# Limitar execução de binários SUID (reduz superfície de ataque)
find / -perm -4000 -type f 2>/dev/null
# Habilitar auditoria de syscalls suspeitas
sudo auditctl -a always,exit -F arch=b64 -S all -k syscall_audit
# Monitorar tentativas de escalada de privilégio
sudo apt install -y auditd
sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes# Ativar proteções do kernel
# /etc/sysctl.conf — adicionar:
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.perf_event_paranoid = 3
kernel.unprivileged_bpf_disabled = 1
net.core.bpf_jit_harden = 2
# Aplicar
sudo sysctl -p- Identificar todos os sistemas Linux com kernel ≤ 7.0
- Priorizar servidores expostos à internet ou em datacenters
- Aplicar patches de cada distribuição (não apenas upstream)
- Revisar logs de autenticação por escalonamentos suspeitos
- Verificar presença de binários SUID não autorizados
- Checar crontabs e serviços rodando como root
- Comunicar equipe de segurança e gestão
- Documentar e reportar se houver evidências de exploração
# Sinais de possível exploração:
# 1. Processos de usuário comum rodando como root
ps aux | awk '$1 != "root" && $2 == "0"'
# 2. Novos binários SUID criados recentemente
find / -perm -4000 -newer /etc/passwd -type f 2>/dev/null
# 3. Entradas suspeitas em /etc/passwd
grep "uid=0" /etc/passwd
# 4. Logs de kernel com mensagens de corrupção
dmesg | grep -iE "(oops|BUG:|corruption|cve)"
# 5. Conexões de rede não autorizadas
ss -tulnp | grep LISTEN-
Patch Management é crítico — O patch upstream estava disponível em ~1 semana, mas distribuições demoram mais para entregar. Monitore seus fornecedores ativamente.
-
Defense in Depth — LPE sozinha não basta; o atacante precisa de acesso inicial. Controle quem tem acesso ao sistema.
-
Encadeamento de vulnerabilidades — CVEs isolados de "baixo risco" podem se tornar críticos quando combinados. Avalie risco em contexto, não apenas pelo CVSS isolado.
-
Supply Chain é vetore real — Código open source amplamente usado pode ser vetor de ataque. Implemente verificação de integridade de pacotes.
-
Kubernetes e containers não são imunes — Se o kernel host é vulnerável, containers sobre ele também são afetados.
-
Sempre copie structs completos — Nunca copie campos individuais de structs de controle do kernel sem garantir que todos os campos críticos sejam inicializados.
-
Use
copy_from_user()corretamente — Funções de cópia do kernel têm semântica específica. Leia a documentação antes de usar. -
Code review de segurança — Mudanças no kernel precisam de revisão focada em segurança, não apenas funcionalidade.
-
Atualizações de kernel são prioridade — Não são apenas "manutenção de rotina". Vulnerabilidades de kernel são frequentemente críticas.
-
Inventário de ativos é fundamental — Você não pode corrigir o que não sabe que tem. Mantenha inventário atualizado de sistemas Linux e suas versões de kernel.
-
Plano de resposta a incidentes — Tenha um playbook pronto para vulnerabilidades críticas com prazo agressivo (tipo CISA KEV).
- CISA KEV Catalog — CVE-2026-31431
- Theori — Descoberta técnica da CopyFail
- Microsoft Security Blog — Análise da vulnerabilidade
- CopyFail — Site oficial da vulnerabilidade
- Jorijn Schrijvershof — Explicação detalhada
- Olhar Digital — Cobertura em português
- Ubuntu Security — CVE Tracker
- Red Hat — CVE Database
Encontrou algo desatualizado ou quer adicionar um cenário de teste? Abra uma issue ou PR!
Por favor, respeite o código de conduta: este repositório é para educação e defesa — não para atividades maliciosas.
MIT License — use para aprender, ensinar e defender sistemas. Nunca para atacar.
"Conhecer o ataque é o primeiro passo para construir a defesa."
⭐ Se este estudo de caso foi útil, deixe uma estrela no repositório!