Fragnesia permite escalada local para root no núcleo Linux por corrupção do cache de páginas

A vulnerabilidade CVE-2026-46300 afeta o subsistema XFRM ESP-in-TCP e permite escrita determinística em arquivos somente leitura mantidos no cache de páginas, com impacto direto em privilégios locais.

Componente	Subsistema XFRM ESP-in-TCP do núcleo Linux, associado ao processamento de tráfego ESP encapsulado sobre TCP.
Vetor	Exploração local por usuário sem privilégios, acionando uma falha lógica no caminho ESP/XFRM para obter escrita arbitrária de bytes no cache de páginas.
Impacto	Modificação de conteúdo de arquivos somente leitura na memória do cache de páginas e escalada local para root, incluindo corrupção do binário /usr/bin/su em provas de conceito.
Prioridade	Aplicar o núcleo corrigido; quando a atualização ainda não estiver disponível, aplicar as mesmas mitigações usadas para Dirty Frag e reduzir acesso local desnecessário.
Artefatos	Vulnerabilidade rastreada como CVE-2026-46300, apelidada de Fragnesia, com pontuação CVSS 7.8 e prova de conceito pública.
Mitigação	Desabilitar esp4, esp6 e funcionalidades relacionadas de xfrm/IPsec quando não forem necessárias, endurecer contêineres e monitorar elevação anormal de privilégio.

Resumo técnico

A vulnerabilidade Fragnesia, registrada como CVE-2026-46300, é uma falha de escalada local de privilégio no núcleo Linux que atinge o subsistema XFRM ESP-in-TCP. O problema permite que um usuário local sem privilégios alcance uma primitiva de escrita em memória do núcleo e altere bytes de arquivos somente leitura enquanto eles estão representados no cache de páginas. O impacto prático é a possibilidade de corromper conteúdo carregado em memória sem alterar o arquivo em disco pelo fluxo normal de permissões, criando uma condição útil para transformar acesso local limitado em execução privilegiada como root. A pontuação CVSS informada é 7.8, compatível com uma falha local que exige presença no sistema, mas produz comprometimento significativo de confidencialidade, integridade e controle operacional.

Fragnesia pertence à mesma área de superfície que vulnerabilidades recentes conhecidas como Copy Fail e Dirty Frag, mas não é tratada como a mesma falha. O ponto central é uma falha lógica no processamento de ESP/XFRM, não uma condição de corrida instável. A exploração demonstrada usa corrupção determinística do cache de páginas e pode atingir binários como /usr/bin/su, um alvo sensível porque participa de fluxos de autenticação e troca de identidade local. A existência de prova de conceito pública aumenta a pressão operacional sobre servidores multiusuário, hosts de virtualização, ambientes com acesso shell compartilhado, estáções de desenvolvimento, nós de CI/CD e cargas em contêiner que preservem caminhos suficientes para alcançar o recurso vulnerável do núcleo.

Fluxo técnico

O caminho vulnerável está relacionado ao suporte do núcleo Linux para XFRM ESP-in-TCP, mecanismo ligado a processamento de IPsec e encapsulamento de ESP sobre TCP. A exploração parte de um usuário local sem privilégios e abusa de uma inconsistência lógica nesse subsistema para construir uma primitiva de escrita arbitrária de bytes no cache de páginas. Em vez de depender de uma janela de tempo entre verificação e uso, o comportamento descrito é determinístico: o atacante prepara as condições locais, aciona o caminho vulnerável e obtém a capacidade de modificar conteúdo que o núcleo mantém em memória para arquivos marcados como somente leitura no sistema de arquivos.

A consequência técnica relevante é que a barreira tradicional de permissão do arquivo não impede a alteração temporária da página em cache. Quando um binário privilegiado, biblioteca ou outro artefato sensível é representado no cache de páginas, a corrupção em memória pode mudar o comportamento observado durante a execução. A prova de conceito citada usa /usr/bin/su como exemplo de alvo para chegar a root, mas o risco defensivo não deve ser interpretado como limitado a esse binário específico. O padrão de ataque é mais amplo: obter escrita em bytes de conteúdo mapeado pelo cache, direcionar essa escrita a um arquivo que participa de um fluxo privilegiado e então acionar o componente alterado para herdar o efeito da corrupção.

Há diferenças importantes em relação a Dirty Frag. Fragnesia recebeu correção própria e não exige os mesmos requisitos de privilégio em nível de host descritos para a falha anterior. Restrições de AppArmor sobre namespaces de usuário sem privilégio podem dificultar a exploração ao exigir desvios adicionais, mas são descritas apenas como mitigação parcial. Isso significa que controles de isolamento podem reduzir caminhos exploráveis em algumas distribuições ou perfis, porém não substituem o núcleo corrigido quando o subsistema vulnerável está presente e alcançável.

Superfície afetada

A superfície de risco inclui sistemas Linux que exponham o subsistema XFRM ESP-in-TCP vulnerável a usuários locais. O contexto informado não lista versões específicas do núcleo, pacotes de distribuição ou ramos de suporte afetados, portanto inventariar a exposição exige correlacionar o estado real do host com os avisos do fornecedor da distribuição e com a presença das funcionalidades xfrm, esp4, esp6 e IPsec relacionadas. O ponto operacional é que o acesso local é a pré-condição principal: contas shell, jobs de automação, usuários de build, sessões de suporte, workloads em contêiner e processos com baixa permissão podem ser suficientes se conseguirem alcançar o caminho vulnerável.

Servidores multiusuário e plataformas de execução compartilhada merecem atenção especial porque uma escalada local transforma uma conta restrita em controle do host. Em ambientes de contêiner, o risco depende da configuração do isolamento, do acesso a namespaces, do perfil AppArmor ou equivalente, de capacidades concedidas, de montagem de arquivos sensíveis e da visibilidade do núcleo do hospedeiro. Mesmo quando o contêiner não contém /usr/bin/su útil para o atacante, a primitiva de corrupção de cache de páginas deve ser tratada como capacidade perigosa, pois pode afetar outros binários e fluxos de execução disponíveis no ambiente.

A notícia também ocorre em um cenário de interesse ativo por explorações locais de Linux. Um ator identificado como berz0k foi observado anunciando em fóruns criminosos uma exploração zero day de escalada local para Linux por US$ 170.000, alegando funcionamento em múltiplas distribuições, estabilidade sem travamento do sistema e uso de um payload .so em /tmp. Esses detalhes não confirmam relação direta com Fragnesia e não devem ser usados como atribuição. Ainda assim, reforçam que falhas locais de Linux com impacto em root têm valor operacional para intrusão pós-comprometimento, fuga de restrições locais e consolidação de acesso.

• Hosts Linux com XFRM ESP-in-TCP vulnerável e acesso local concedido a usuários ou processos não confiáveis.
• Ambientes com esp4, esp6, xfrm ou IPsec habilitados sem necessidade operacional clara.
• Servidores de build, runners de CI/CD, bastions, estáções de engenharia e plataformas multiusuário onde contas restritas coexistem no mesmo núcleo.
• Contêineres com isolamento fraco, perfis permissivos, namespaces de usuário sem restrição ou acesso desnecessário a recursos do hospedeiro.

Hunting e telemetria

A detecção deve partir da hipótese de pós-exploração local. Como a vulnerabilidade permite alteração em memória de arquivos somente leitura, controles baseados apenas em integridade de arquivo em disco podem não registrar modificação persistente. A telemetria deve combinar eventos de identidade, execução de processos, carregamento de módulos, uso de namespaces, chamadas relacionadas a xfrm, tentativas de acionar binários privilegiados e mudanças repentinas de UID efetivo. Em servidores com EDR ou auditoria do núcleo, priorize correlação entre processos de usuário comum e subsequente execução como root sem caminho administrativo esperado, como sudo, automação autorizada ou sessão interativa legítima.

Logs de autenticação e auditoria devem ser revisados para uso incomum de /usr/bin/su, criação de shells privilegiados, alterações de contexto de segurança e execução de binários sensíveis por contas que normalmente não administram o sistema. Em ambientes que coletam auditd, procure chamadas execve envolvendo /usr/bin/su, shells, interpretadores e ferramentas de pós-exploração imediatamente após atividade incomum de rede ou manipulação de namespaces. Quando houver telemetria de núcleo, investigue interações locais com xfrm, IPsec e ESP que partam de processos sem justificativa funcional.

Para contêineres e CI/CD, a busca deve incluir runners que criaram processos privilegiados inesperados, jobs que escreveram ou carregaram objetos compartilhados em /tmp, mudanças anormais em permissões efetivas e execuções fora do grafo esperado do pipeline. O artefato .so em /tmp aparece no anúncio criminoso separado e não é indicador confirmado de Fragnesia; use esse padrão apenas como pista de comportamento suspeito em conjunto com outros sinais de escalada local. A ausência de exploração observada em campo não elimina a necessidade de hunting, porque prova de conceito pública reduz o tempo entre divulgação e adaptação por operadores ofensivos.

• Execução incomum de /usr/bin/su, shells ou interpretadores imediatamente seguida por UID efetivo 0 sem evento administrativo correspondente.
• Atividade local de processos sem privilégio envolvendo xfrm, IPsec, esp4, esp6 ou namespaces de usuário em hosts que não usam esses recursos.
• Criação ou carregamento de arquivos .so em /tmp associada a tentativa de elevação de privilégio, tratada como sinal auxiliar e não como IoC exclusivo da falha.
• Divergência entre integridade em disco e comportamento em execução de binários privilegiados, especialmente quando hashes permanecem inalterados mas o fluxo de privilégio muda.
• Eventos de contêiner ou pipeline que resultem em escape lógico de permissões, execução como root fora do modelo esperado ou abuso de capacidades do núcleo.

Mitigação

A ação prioritária é instalar o núcleo corrigido fornecido pela distribuição ou pelo mantenedor do ambiente. Como Fragnesia recebeu correção própria, aplicar apenas mitigação temporária não deve ser considerado encerramento do risco. Em frotas grandes, a resposta deve começar por inventário de hosts Linux, identificação de versões do núcleo, verificação de uso real de xfrm/IPsec e classificação de sistemas com acesso local não confiável. Servidores expostos a múltiplos usuários, runners de CI/CD e hospedeiros de contêiner devem entrar na primeira onda de atualização porque a pré-condição local é mais provável nesses ambientes.

Quando a atualização não puder ser aplicada de imediato, a mitigação recomendada é reduzir a superfície ESP/XFRM de forma explícita: desabilitar esp4, esp6 e funcionalidades correlatas de xfrm/IPsec se elas não forem necessárias para o serviço. Também é necessário restringir acesso shell local, remover contas sem uso, limitar execução interativa em servidores compartilhados, revisar permissões de jobs automatizados e endurecer perfis de contêiner. Restrições de AppArmor para namespaces de usuário sem privilégio podem aumentar o custo de exploração, mas não devem ser tratadas como compensação completa em hosts vulneráveis.

A validação pós-correção deve confirmar que o sistema inicializou com o núcleo atualizado, que módulos ou funcionalidades desabilitadas permaneceram bloqueados após reinicialização e que workloads dependentes de IPsec continuam funcionando apenas onde o recurso é necessário. Equipes de segurança devem manter hunting por alguns ciclos de retenção de logs, porque uma tentativa anterior de exploração pode não deixar alteração persistente no arquivo em disco. Em caso de suspeita de comprometimento, a resposta deve isolar o host, preservar memória e logs relevantes quando possível, revisar contas locais e chaves, rotacionar segredos acessíveis ao host e reconstruir sistemas críticos a partir de imagens confiáveis se houver evidência de controle como root.

• Aplicar o núcleo corrigido e reiniciar os hosts para garantir que a versão vulnerável saiu de execução.
• Desabilitar esp4, esp6 e recursos xfrm/IPsec sem uso operacional confirmado.
• Reduzir acesso local desnecessário, especialmente contas shell, usuários de build e sessões administrativas compartilhadas.
• Endurecer contêineres com perfis AppArmor adequados, restrição de namespaces de usuário sem privilégio e remoção de capacidades desnecessárias.
• Monitorar escalada local anormal, execução de /usr/bin/su, shells como root e atividade de xfrm por processos sem justificativa.
• Rotacionar credenciais e segredos expostos a hosts onde houver indício de exploração ou obtenção de privilégio root.