Programação Por Equipe DevBras

Capa do artigo: Falha no kernel Linux explorada: como checar e atualizar

Falha no kernel Linux explorada: como checar e atualizar

A CISA confirmou ataques à CVE-2026-46300 do kernel Linux, que dá root. Veja se seu servidor está afetado, as versões corrigidas e como atualizar.

Em 28/10/2026 a CISA, agência de cibersegurança dos EUA, colocou a CVE-2026-46300 do kernel Linux no seu catálogo de vulnerabilidades exploradas em ataques (KEV). A falha, apelidada de “Fragnesia”, permite que um usuário local sem privilégio vire root. Segundo a CISA, ela está sendo usada junto com o PHP2Shell (CVE-2026-109618 e CVE-2026-109619) pra plantar webshells PHP e rodar comandos como root.

A correção existe desde maio de 2026. Ou seja: servidor Linux que não atualizou o kernel e reiniciou desde então provavelmente ainda está exposto. Abaixo está o que a falha faz, como saber se você está afetado, as versões corrigidas nas principais distros, como atualizar e o que conferir depois.

O que é a CVE-2026-46300

O bug está no código de rede do kernel. Segundo a descrição no NVD, a função skb_try_coalesce(), que junta buffers de pacotes, perdia a marca SKBFL_SHARED_FRAG (que indica que um pedaço do pacote aponta pra memória compartilhada, como o page cache). Mais adiante, o ESP, protocolo usado pelo IPsec, confia nessa marca pra decidir se pode decifrar os dados “no lugar”. Sem a marca, ele decifra por cima de páginas do page cache, a cópia dos arquivos que o kernel mantém na memória.

Na prática, de acordo com a Red Hat, um atacante local com poucos privilégios consegue escrever bytes no page cache de arquivos somente leitura, incluindo arquivos sensíveis do sistema, e usar isso pra sobrescrever binários privilegiados e virar root. A Red Hat descreve a falha como uma variante do “Dirty Frag”, divulgado em maio.

  • Nota: CVSS 3.1 de 7.8 (alta), vetor local, baixa complexidade, sem interação do usuário (NVD e Red Hat).
  • Prioridade na Ubuntu: alta, com a justificativa “escalada de privilégio local trivial”. A Ubuntu também diz que a falha pode permitir fuga de container.
  • Exploração: confirmada pela CISA, que deu às agências federais dos EUA prazo até 31/10/2026 pra corrigir e exigiu triagem forense. O tracker do Debian aponta prova de conceito pública.
  • Correção: commit upstream f84eca581739 (“net: skbuff: preserve shared-frag marker during coalescing”), de maio de 2026.

Por que é grave mesmo sendo “local”

Falha local costuma parecer menos urgente, porque o atacante já precisa estar dentro da máquina. O problema é que existe uma porta de entrada pronta: o PHP2Shell, que dá execução remota de código sem login em PHP vulnerável. A cadeia descrita pela CISA é:

  1. O atacante explora o PHP2Shell e passa a rodar comandos como o usuário do servidor web (por exemplo www-data).
  2. Usa a CVE-2026-46300 pra virar root.
  3. Deixa webshells PHP e passa a controlar o servidor inteiro.

Também vale pra qualquer máquina com vários usuários, runners de CI que rodam código de terceiros e hosts de containers: container não tem kernel próprio, ele usa o kernel do host.

Como saber se você está afetado

O que importa é o kernel que está rodando, não o pacote instalado. Veja com:

uname -r

Pra listar os kernels instalados:

# Debian / Ubuntu
dpkg -l 'linux-image*' | grep ^ii

# RHEL / AlmaLinux / Rocky
rpm -q kernel

Compare a versão com a tabela abaixo. Se a versão rodando for igual ou mais nova que a corrigida da sua distro, a falha está corrigida. Se você instalou o kernel novo mas não reiniciou, ainda está vulnerável.

Versões corrigidas

Kernel oficial (kernel.org)

Conferido nos ChangeLogs oficiais do kernel.org: a correção entrou nas versões estáveis 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91 e 6.18.33 (todas de 23/05/2026), na 7.0.10 e na 7.1. A falha afeta kernels a partir do 3.9, segundo o NVD.

Distribuições

  • Ubuntu 22.04 LTS: 5.15.0-181.191 (HWE: 6.8.0-124.124~22.04.1)
  • Ubuntu 24.04 LTS: 6.8.0-124.124 (HWE: 6.17.0-35.35~24.04.1)
  • Ubuntu 25.10: 6.17.0-35.35
  • Ubuntu 26.04 LTS: 7.0.0-22.22
  • Ubuntu 18.04 e 20.04: marcados como não afetados na prática pela Canonical, porque o exploit depende do módulo espintcp, que só existe a partir do kernel 5.6.
  • Debian 11 (bullseye): 5.10.257-1 (DLA-4606-1) ou, no pacote linux-6.1, 6.1.174-1~deb11u1 (DLA-4607-1)
  • Debian 12 (bookworm): 6.1.174-1 (DSA-6306-1)
  • Debian 13 (trixie): 6.12.90-1 (DSA-6295-1)
  • RHEL 8.10: kernel-4.18.0-553.125.1.el8_10
  • RHEL 9.8: kernel-5.14.0-687.10.1.el9_8
  • RHEL 10.2: kernel-6.12.0-211.16.1.el10_2

Fontes: Ubuntu, Debian e Red Hat (as versões EUS/AUS do RHEL estão na página da Red Hat). Em outras distros, procure a CVE-2026-46300 no tracker de segurança dela.

Como atualizar

Debian e Ubuntu

sudo apt update && sudo apt upgrade
sudo reboot

A Ubuntu lembra que o unattended-upgrades instala o pacote sozinho, mas não reinicia. Pra saber se a máquina está esperando reboot, veja se o arquivo /var/run/reboot-required existe.

RHEL, AlmaLinux, Rocky e Fedora

sudo dnf upgrade --refresh 'kernel*'
sudo reboot

Sem poder reiniciar agora: Livepatch

Na Ubuntu, a CVE aparece no aviso de Livepatch LSN-0122-1, então máquinas com Livepatch ativo podem receber a correção sem reboot. Confira com canonical-livepatch status. Mesmo assim, planeje o reboot pra entrar no kernel corrigido de vez.

Docker e Kubernetes

Atualizar a imagem do container não resolve: o kernel é o do host. Atualize os hosts e os nodes do cluster. No Kubernetes, faça um node por vez: kubectl drain, atualiza, reinicia, confere a versão e kubectl uncordon. Em serviço gerenciado (EKS, GKE, AKS), atualize a imagem dos node pools pra versão que o provedor publicou com a correção. Se você roda containers como root, vale rever isso também: um processo sem privilégio dá mais trabalho pro atacante.

Paliativo se não der pra atualizar hoje

A Ubuntu diz que esta falha pode ser mitigada do mesmo jeito que o Dirty Frag: bloqueando os módulos ESP do IPsec. A receita oficial está no blog da Ubuntu sobre o Dirty Frag. Só faça isso se a máquina não usa IPsec (VPNs com StrongSwan, por exemplo), porque vai quebrar.

# 1. impedir que os módulos carreguem
echo "install esp4 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all

# 2. descarregar se já estiverem carregados
sudo rmmod esp4 esp6 2>/dev/null

# 3. conferir
grep -qE '^(esp4|esp6) ' /proc/modules && echo "módulos carregados" || echo "módulos NÃO carregados"

Se os módulos não descarregarem porque estão em uso, só o reboot aplica o bloqueio. A receita da Ubuntu também bloqueia o rxrpc, que é da outra falha do Dirty Frag (CVE-2026-43500). Depois de atualizar o kernel, remova o paliativo:

sudo rm /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all

No RHEL e derivados, siga o boletim de mitigação indicado na página da CVE na Red Hat.

O que checar depois do patch

  1. O kernel novo está rodando? Rode uname -r de novo e compare com a tabela.
  2. Tinha PHP vulnerável exposto? Se o servidor rodava uma versão de PHP afetada pelo PHP2Shell, trate como possível invasão. Procure arquivos PHP novos ou alterados nas pastas do site, por exemplo: sudo find /var/www -name '*.php' -mtime -30 -ls, e desconfie de nomes estranhos, arquivos em pastas de upload e código ofuscado (eval, base64_decode).
  3. Persistência: revise crontab -l de cada usuário e /etc/cron*, usuários novos em /etc/passwd, chaves em ~/.ssh/authorized_keys (inclusive do root) e serviços systemd desconhecidos.
  4. Achou algo? Isole a máquina, preserve os logs e reconstrua a partir de uma base limpa. Com root, o atacante pode ter mexido em qualquer coisa, e só atualizar não remove o acesso dele. Troque as senhas e chaves que estavam na máquina.

Resumo

  • A CVE-2026-46300 (“Fragnesia”) é uma escalada de privilégio pra root no kernel Linux, explorada em ataques segundo a CISA desde 28/10/2026.
  • Ela é encadeada com o PHP2Shell: entra pelo PHP sem login e vira root pelo kernel.
  • Rode uname -r, compare com a versão corrigida da sua distro, atualize e reinicie.
  • Containers usam o kernel do host: atualize hosts e nodes.
  • Se você tinha PHP vulnerável exposto, procure webshells e sinais de persistência.

Leia também: PHP2Shell na lista da CISA: confira o seu PHP e Falha do Magento explorada: como checar e atualizar.

Fontes oficiais: CISA KEV · NVD · commit no kernel.org · Ubuntu · Debian · Red Hat

Avalie este artigo