Falha de nove anos no núcleo Linux permite execução como root em distribuições populares

A vulnerabilidade CVE-2026-46333 afeta a lógica de privilégios em __ptrace_may_access() e pode expor /etc/shadow, chaves privadas de host SSH e caminhos locais para execução de comandos como root.

Componente	Núcleo Linux, especificamente a lógica de verificação de acesso em __ptrace_may_access().
Vetor	Exploração local por usuário sem privilégios em instalações padrão de distribuições como Debian, Fedora e Ubuntu, com abuso de processos e binários privilegiados.
Impacto	Divulgação de arquivos sensíveis, incluindo /etc/shadow e /etc/ssh/*_key, além de execução de comandos arbitrários como root por caminhos envolvendo chage, ssh-keysign, pkexec e accounts-daemon.
Prioridade	Aplicar a atualização de núcleo fornecida pela distribuição; quando a correção imediata não for possível, elevar temporariamente kernel.yama.ptrace_scope para 2 e revisar credenciais expostas.
Artefatos	CVE-2026-46333, CVSS 5.5, codinome ssh-keysign-pwn, função __ptrace_may_access() e parâmetro kernel.yama.ptrace_scope.
Exposição	A falha teria sido introduzida em novembro de 2016 e permaneceu presente por cerca de nove anos antes da divulgação pública e da liberação de prova de conceito.

Resumo técnico

A vulnerabilidade CVE-2026-46333 é uma falha de gerenciamento inadequado de privilégios no núcleo Linux que afeta a decisão de acesso implementada em __ptrace_may_access(). O problema é relevante porque essa função participa de controles que deveriam impedir que processos locais sem autorização observem ou interajam com contexto privilegiado. Quando essa lógica permite uma decisão incorreta, um usuário local sem privilégios pode transformar uma sessão comum em um ponto de extração de material sensível ou em uma rota de execução com privilégios elevados. A falha recebeu pontuação CVSS 5.5, mas o impacto operacional depende fortemente da presença de usuários locais não confiáveis, serviços multiusuário, contas de baixa permissão, ambientes de desenvolvimento compartilhados, máquinas de salto e instâncias onde processos set-uid expõem memória ou caminhos de execução privilegiados.

A exploração confirmada inclui divulgação de /etc/shadow, exposição de chaves privadas de host em /etc/ssh/*_key e execução de comandos arbitrários como root. Os caminhos de exploração descritos envolvem quatro alvos locais: chage, ssh-keysign, pkexec e accounts-daemon. Esse conjunto é importante porque combina binários, serviços e fluxos comuns em instalações padrão de distribuições amplamente usadas, incluindo Debian, Fedora e Ubuntu. A existência de prova de conceito pública aumenta a urgência para ambientes com qualquer forma de acesso shell por usuários não administradores, mesmo quando o acesso inicial parece limitado, porque o atacante não precisa partir de uma exploração remota do núcleo; basta obter uma conta local ou uma sessão local já existente.

Fluxo técnico

O ponto central da falha está na avaliação de permissão feita por __ptrace_may_access(). Em sistemas Linux, mecanismos relacionados a observação de processos e inspeção de estado precisam diferenciar rigorosamente processos do mesmo usuário, processos privilegiados, processos com atributos especiais e contextos protegidos por credenciais diferentes. A vulnerabilidade permite que essa fronteira seja atravessada em situações em que um usuário local não deveria conseguir acessar conteúdo associado a processos privilegiados. A consequência prática é uma primitiva local confiável: a sessão não privilegiada passa a conseguir obter informação que deveria permanecer restrita ou direcionar uma sequência de abuso contra componentes que executam com privilégios de root.

Os quatro caminhos de exploração citados indicam que o bug não depende de um único binário frágil. Em chage, o risco se relaciona à manipulação de fluxos que lidam com informações de conta e políticas de expiração. Em ssh-keysign, o interesse defensivo é maior porque o componente participa de operações vinculadas a autenticação baseada em host e pode estar próximo de chaves privadas locais. Em pkexec, o impacto é crítico por envolver uma interface tradicionalmente usada para execução autorizada de ações administrativas. Em accounts-daemon, a superfície passa por serviços de conta do sistema que rodam com privilégio e mantêm estado relevante sobre usuários. A falha no núcleo fornece a condição de acesso; os binários e serviços privilegiados fornecem os caminhos concretos para leitura de arquivos ou execução como root.

A exploração exige presença local. Isso limita o cenário em comparação com execução remota direta, mas não reduz o risco em servidores multiusuário, estáções de trabalho corporativas, ambientes de laboratório, instâncias de CI, hosts de compilação, bastions e máquinas onde contas de aplicação, desenvolvedores, operadores ou terceiros têm shell. Em ambientes de nuvem, o vetor também importa quando uma credencial de baixa permissão, uma chave SSH de usuário comum ou uma conta de serviço interativa já foi comprometida. Nesses casos, CVE-2026-46333 pode atuar como etapa pós-exploração para sair do confinamento de usuário e acessar segredos do host.

Superfície afetada

A superfície principal é formada por sistemas Linux com núcleo vulnerável e instalação padrão que inclua os componentes exploráveis descritos. Debian, Fedora e Ubuntu foram citados como distribuições em que instalações padrão podem ser afetadas, mas a avaliação defensiva não deve depender apenas do nome da distribuição. O critério operacional é verificar o pacote de núcleo efetivamente instalado, a disponibilidade de correção no canal oficial da distribuição, a presença dos binários e serviços envolvidos e a existência de usuários locais não confiáveis. Como a falha teria sido introduzida em novembro de 2016, a janela de exposição pode abranger hosts antigos, imagens base reutilizadas, appliances Linux, máquinas de desenvolvimento que recebem atualizações irregulares e instâncias que permanecem presas a versões de núcleo por dependências de driver ou suporte.

Os ativos mais sensíveis são arquivos e materiais que, se lidos por usuário comum, possibilitam comprometimento persistente ou movimentação lateral. /etc/shadow contém hashes de senha locais e metadados de expiração; mesmo sem senha em texto claro, sua exposição permite ataque offline contra credenciais fracas. Arquivos em /etc/ssh/*_key são chaves privadas de host SSH; se copiados, podem permitir personificação do servidor, enfraquecer a confiança de clientes que validam identidade de host ou facilitar ataques em ambientes onde a verificação de chaves é negligenciada. Também há risco para material administrativo que tenha residido na memória de processos set-uid, porque a falha envolve fronteiras de observação e acesso entre processos locais.

A prova de conceito pública altera a priorização. Antes da publicação de um explorador funcional, a correção poderia ser tratada dentro do ciclo normal de atualização de núcleo, conforme exposição local. Depois da disponibilidade pública, o custo de exploração cai e a análise deve considerar usuários internos maliciosos, contas comprometidas e automação de pós-exploração. Sistemas que permitem login de múltiplos usuários, execução de tarefas de build por colaboradores, acesso temporário de fornecedores ou workloads com escapes parciais de aplicação têm prioridade maior do que estáções isoladas sem usuários locais adicionais.

• Hosts Debian, Fedora e Ubuntu com núcleo vulnerável e instalação padrão contendo chage, ssh-keysign, pkexec ou accounts-daemon.
• Servidores com shell para usuários não administradores, bastions, runners de CI, hosts de compilação e máquinas de desenvolvimento compartilhadas.
• Sistemas em que /etc/shadow, /etc/ssh/*_key ou material administrativo em memória de processos set-uid possam gerar escalada adicional, persistência ou movimentação lateral.

Hunting e telemetria

A caça deve começar por inventário e correlação de versão do núcleo. Operadores devem mapear hosts Linux com usuários locais não confiáveis, confirmar a versão de núcleo instalada, registrar o pacote de distribuição correspondente e comparar com o nível de atualização publicado pelo fornecedor. Como a falha é local, telemetria de autenticação e sessão tem valor alto: logins SSH recentes de contas comuns, criação de shells interativos por contas de aplicação, sessões em bastions e execução de comandos administrativos sem histórico compatível devem ser revisados. A existência de PoC torna especialmente importante separar máquinas apenas vulneráveis de máquinas com sinais de exploração ou exposição de credenciais.

Nos endpoints, os sinais mais relevantes envolvem leitura inesperada de arquivos sensíveis, execução incomum dos binários associados e alterações de identidade de processo. Chamadas ou eventos que indiquem acesso a /etc/shadow por processo que não faça parte de rotinas legítimas de autenticação, leitura de /etc/ssh/*_key fora de janelas de administração e execução anômala de chage, ssh-keysign, pkexec ou accounts-daemon por usuários comuns devem ser investigados. Em ambientes com EDR ou auditoria Linux, regras podem observar tentativas de acesso a arquivos de chave, criação de processos filhos privilegiados a partir de sessão de usuário comum e uso repetido de binários set-uid em curto intervalo.

A telemetria de identidade também precisa ser cruzada com artefatos pós-exploração. Se /etc/shadow foi potencialmente acessado, tentativas subsequentes de autenticação local, falhas de login distribuídas e uso de contas antigas podem indicar ataque offline bem-sucedido. Se chaves de host SSH foram expostas, o impacto pode não aparecer no próprio host vulnerável; a defesa deve revisar clientes que confiam nessas chaves, conexões SSH anormais, alterações em known_hosts e alertas de identidade de host divergente. A ausência de log explícito de leitura não deve ser tratada como prova de não exploração, porque a capacidade descrita envolve condições locais de baixo nível e pode não gerar evento de segurança claro sem instrumentação adequada.

• Execução incomum de chage, ssh-keysign, pkexec ou interação com accounts-daemon partindo de contas sem privilégio administrativo.
• Acesso a /etc/shadow ou /etc/ssh/*_key fora de processos e janelas administrativas esperadas.
• Sessões locais recentes de usuários não confiáveis em hosts vulneráveis, especialmente antes da aplicação da correção.
• Elevação inesperada para root, criação de shells privilegiados ou comandos administrativos sem trilha normal de sudo.

Mitigação

A ação principal é instalar a atualização de núcleo fornecida pela distribuição e reiniciar o sistema quando necessário para carregar o núcleo corrigido. Em frotas Linux, a mitigação deve ser tratada como uma mudança de sistema operacional, não apenas como atualização de pacote: confirmar o núcleo ativo após o reboot, validar que instâncias efêmeras e imagens base foram reconstruídas, garantir que templates de nuvem não continuem gerando hosts vulneráveis e revisar exceções em servidores que não podem reiniciar imediatamente. Quando a atualização não puder ser aplicada no mesmo ciclo, a medida temporária indicada é elevar kernel.yama.ptrace_scope para 2, reduzindo a superfície de acesso relacionada a ptrace. Essa compensação deve ser documentada como temporária, porque parâmetro de endurecimento não substitui correção de núcleo.

Hosts que permitiram usuários locais não confiáveis durante a janela de exposição exigem resposta além do patch. Chaves privadas de host SSH devem ser tratadas como potencialmente divulgadas quando o sistema combinou vulnerabilidade, acesso local e exposição relevante. A rotação dessas chaves precisa considerar clientes e automações que validam identidade do servidor, evitando simplesmente trocar arquivos sem atualizar a cadeia de confiança. Senhas locais devem ser avaliadas com foco em contas presentes em /etc/shadow, principalmente contas com senha reutilizada, hashes antigos ou privilégios indiretos. Materiais administrativos que possam ter residido na memória de processos set-uid também devem ser revisados, incluindo tokens temporários, parâmetros sensíveis e credenciais usadas por ferramentas locais.

A contenção deve priorizar sistemas com prova de acesso local, não apenas sistemas vulneráveis no inventário. Em um fluxo prático, primeiro identificar hosts com núcleo afetado; depois separar aqueles com usuários locais não confiáveis ou contas comprometidas; em seguida aplicar atualização ou kernel.yama.ptrace_scope=2; por fim rotacionar segredos onde a exposição é plausível. Para validação, equipes devem confirmar que os binários exploráveis continuam presentes apenas com permissões esperadas, que logs de execução privilegiada não mostram comportamento atípico e que controles de EDR, auditoria ou SIEM conseguem alertar para leitura de /etc/shadow e chaves SSH por processos inesperados.

• Aplicar o pacote de núcleo corrigido da distribuição e validar o núcleo ativo após reinicialização.
• Usar kernel.yama.ptrace_scope=2 como endurecimento temporário quando a atualização imediata não for possível.
• Rotacionar chaves privadas de host SSH em sistemas com acesso local não confiável durante a janela vulnerável.
• Revisar contas locais, hashes em /etc/shadow, uso de set-uid e trilhas de execução de chage, ssh-keysign, pkexec e accounts-daemon.
• Atualizar imagens base, templates de nuvem, runners de CI e hosts de desenvolvimento para impedir recriação de sistemas com núcleo vulnerável.