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

Social Media Auto Publish Powered By : XYZScripts.com