Fragnesia: nova falha no kernel Linux permite escalada para root via XFRM ESP-in-TCP (CVE-2026-46300)
Nova vulnerabilidade no subsistema XFRM do kernel Linux (CVE-2026-46300) permite que atacantes locais escalem para root via corrupção de page cache. PoC público, patches em distribuição. Terceira falha da família após Dirty Frag e Copy Fail.
Distribuições Linux começaram a liberar correções para uma nova falha de elevação de privilégio local no kernel, batizada de Fragnesia e oficialmente registrada como CVE-2026-46300. O bug reside no subsistema XFRM ESP-in-TCP e permite que um atacante sem privilégios obtenha root sobrescrevendo arquivos do sistema. Um proof-of-concept já é público, embora ainda não haja relatos de exploração ativa. A Microsoft, que detalhou o problema, recomenda aplicação imediata dos patches.
O que aconteceu
A maior parte das principais distribuições Linux passou a notificar usuários sobre uma vulnerabilidade no kernel que possibilita elevação de privilégio para root. A falha foi nomeada Fragnesia pelos pesquisadores da Microsoft que a analisaram e recebeu a identificação CVE-2026-46300.
O bug localiza-se no subsistema XFRM ESP-in-TCP, parte do stack de rede do kernel responsável por encapsular tráfego IPsec sobre TCP. Um atacante local com acesso ao sistema, mesmo sem privilégios elevados, consegue explorar a falha para sobrescrever arquivos sensíveis e, com isso, obter um shell como root.
Patches estão sendo distribuídos por Debian, Ubuntu, Red Hat, SUSE e outros mantenedores. Um exploit demonstrativo já circula publicamente, embora não haja, no momento, relatos confirmados de exploração na natureza voltada especificamente para a Fragnesia.
Como o ataque funciona
A técnica explorada pela Fragnesia segue uma cartilha familiar para quem acompanhou recentes ataques de elevação no Linux: obtenção de uma primitiva de escrita arbitrária em memória do kernel, seguida da corrupção do cache de páginas correspondente a um binário executável de alto privilégio, normalmente /usr/bin/su.
Com a corrupção, o usuário não privilegiado consegue executar o binário modificado e cair direto em um shell com permissões root. Importante: a exploração não está restrita ao binário su. Como a primitiva permite alterar qualquer arquivo legível pelo usuário, o atacante pode optar por sobrescrever /etc/passwd, /etc/sudoers ou outros caminhos críticos, ampliando as opções de persistência.
“De forma análoga ao Dirty Frag, a Fragnesia explora uma vulnerabilidade no subsistema XFRM ESP-in-TCP para obter uma primitiva de escrita em memória do kernel. Essa primitiva é então usada para corromper a memória de cache de páginas do binário /usr/bin/su, o que leva à execução de um shell com privilégios de root.”
Equipe de threat intelligence da Microsoft
Riscos e quem está exposto
- Servidores Linux multiusuário em ambientes corporativos onde contas locais não-privilegiadas existem em volume (hospedagem, universidades, plataformas SaaS multi-tenant)
- Hosts compartilhados de CI/CD em que runners executam jobs de terceiros
- Containers e runtimes que compartilham o kernel do host — uma fuga de container combinada com Fragnesia leva direto a root no nó
- Workstations com múltiplos usuários ou estações compartilhadas em laboratórios
- Sistemas embarcados rodando kernels desatualizados em produção — IoT e equipamentos industriais
- Qualquer cenário pós-comprometimento: um atacante que ganhe shell de baixo privilégio via outra falha pode usar a Fragnesia como degrau para root
Análise
Fragnesia é a terceira falha da mesma família a aparecer em curto intervalo: Dirty Frag e Copy Fail compartilham a mesma classe de vulnerabilidade no subsistema de redes do kernel. A Microsoft já havia confirmado, em 8 de maio, atividade limitada in-the-wild que poderia indicar exploração de Dirty Frag ou Copy Fail. O Copy Fail está confirmado como explorado ativamente; o Dirty Frag tem indícios. Agora, com a Fragnesia tendo PoC público desde o primeiro dia, é razoável esperar exploração organizada em semanas — não meses.
A repetição em um subsistema relativamente pouco visitado por revisões de segurança aponta um problema mais profundo: o XFRM/IPsec do kernel virou superfície fértil para bugs explorativos porque combina lógica complexa de gerenciamento de estado, manipulação de buffers e baixa cobertura de fuzzing histórico em comparação com áreas mais expostas, como filesystems ou sockets de rede. Esse padrão lembra o que aconteceu com io_uring entre 2022 e 2024, quando uma sequência de bugs forçou várias distros e provedores cloud a desabilitar o recurso por padrão.
Para defensores, o sinal é claro: classes de vulnerabilidade tendem a aparecer em ondas. Aplicar o patch da Fragnesia é o passo óbvio, mas a postura sustentável é assumir que mais bugs no mesmo subsistema vão aparecer e construir mitigação compensatória — restrição de uso de XFRM/IPsec em hosts que não precisam dele, hardening por seccomp/landlock, e mais investimento em telemetria de execução de binários sensíveis como su, sudo e passwd.
Recomendações práticas
- Aplicar imediatamente os pacotes de atualização do kernel disponibilizados pela distribuição em uso
- Em hosts onde reboot imediato não é viável, considerar mitigações temporárias como bloquear o uso do subsistema XFRM via /etc/modprobe.d quando o IPsec não for necessário
- Monitorar execuções e modificações em binários setuid sensíveis: /usr/bin/su, /usr/bin/sudo, /usr/bin/passwd
- Habilitar auditd com regras específicas para alterações no page cache de binários privilegiados quando o stack de detecção suportar
- Inventariar ambientes multi-tenant e shared hosting — esses são os alvos mais óbvios para abuso da Fragnesia
- Verificar a versão do kernel em imagens base de containers e atualizar Dockerfiles para que pipelines de CI passem a usar imagens patched
- Caçar artefatos do PoC público em endpoints (hashes, nomes de arquivos, padrões de execução) e correlacionar com alertas de baixa severidade que possam indicar tentativas de exploração
- Revisar políticas de acesso local: contas de serviço ou desenvolvimento com shell não deveriam coexistir com workloads sensíveis no mesmo host
Fonte: SecurityWeek





