Linux & CloudLinux Risco Alto

RtabRace CVE-2026-68138: usuário local pode derrubar host CloudLinux

RtabRace é uma corrida no traffic control do kernel. CloudLinux 7h/8 expostos devem mitigar namespaces e aplicar o kernel corrigido; outras linhas usam configuração protetiva.

Revisado em 04/09/2026 Leitura técnica
CVE-2026-68138
SeveridadeAlto
Versões afetadasCloudLinux 7 Hybrid e 8 com namespaces não privilegiados; código também presente em outras linhas sob configuração protetiva
Versões corrigidasCL7h/8 kernel 4.18.0-553.150.1.lve.1; LTS kernel-lts 5.14.0-284.1101...els12; mitigação user.max_user_namespaces=0
Status WebinHostMitigação e kernels disponíveis conforme a linha

A RtabRace (CVE-2026-68138) é uma condição de corrida no traffic control do kernel. Um usuário não privilegiado capaz de abrir user namespace pode corromper memória. Em testes CloudLinux, o resultado reproduzível foi panic do host; a elevação observada publicamente em Ubuntu não foi reproduzida nessas linhas.

O que aconteceu

Chamadas concorrentes operavam uma lista global de tabelas de taxa sem a proteção RTNL esperada. A corrida pode liberar a mesma estrutura duas vezes ou usá-la depois da liberação. O proof of concept público cria o contexto de rede necessário por user namespace.

CloudLinux 8 e 7 Hybrid habilitam namespaces não privilegiados na configuração padrão e são os alvos práticos destacados. CloudLinux 9/10, versões LTS e CloudLinux for Ubuntu carregam código vulnerável, mas a configuração padrão impede a cadeia pública; CloudLinux 7 clássico não contém o código.

Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.

Versões e ambientes afetados e corrigidos

Produto ou linhaAfetado / expostoCorrigido / protegido
CloudLinux 7não afetadonenhuma ação para esta CVE
CloudLinux 7 Hybridexposto com user namespaceskernel-4.18.0-553.150.1.lve.1.el7h+ ou mitigação
CloudLinux 8exposto com user namespaceskernel-4.18.0-553.150.1.lve.1.el8+ ou mitigação
CloudLinux 9/10código presente; padrão bloqueia exploit públicomanter configuração protetiva e updates
CloudLinux 8/9 LTScódigo presente; padrão protetivokernel-lts-5.14.0-284.1101...els12+

A exposição é uma propriedade de versão e configuração. Se user.max_user_namespaces for zero e a tentativa unshare falhar, o caminho público fica bloqueado. Aplicações que dependem de namespaces precisam ser testadas antes da mitigação.

Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.

Nível de risco e impacto

Alto para hosts compartilhados expostos. CloudLinux cita CVSS 7,0 e classificação Moderate da Red Hat, mas um usuário de site comprometido pode derrubar todas as contas do host. A disponibilidade multi-tenant justifica tratamento prioritário.

Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.

Como verificar se o servidor ou site está vulnerável

Verifique versão, kernel e capacidade real de criar user namespace. Execute unshare apenas como teste benigno e espere falha quando a mitigação estiver ativa.

uname -r
sysctl user.max_user_namespaces
unshare -Urn true; echo "exit=$?"
kcarectl --patch-info 2>/dev/null | grep CVE-2026-68138

Valor diferente de zero e unshare bem-sucedido indicam que a pré-condição está aberta. Em CL7h/8, compare com o build corrigido. Nas linhas em que o fornecedor não planeja patch por configuração, preserve o bloqueio e documente exceções.

Faça somente inventário defensivo. Não execute prova de conceito em produção. Um exploit pode derrubar o host, alterar dados, apagar vestígios ou atingir outros clientes. Se o resultado for ambíguo, preserve as saídas e compare-as com o boletim do fornecedor.

Como corrigir ou mitigar

Em hosts que não precisam do recurso, defina user.max_user_namespaces=0 de forma persistente e teste workloads. Em CL7h/8, instale o kernel corrigido. CloudLinux informou que 9/10 não receberiam patch específico porque a configuração stock é a proteção; LTS recebeu kernel ELS.

sysctl -w user.max_user_namespaces=0
printf 'user.max_user_namespaces=0\n' > /etc/sysctl.d/99-disable-userns.conf
dnf update 'kernel*'

Antes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.

Validação posterior e resposta a incidentes

Confirme que unshare falha e valide containers, sandboxing e painéis. Procure panics, oops e reinícios inesperados. A mitigação pode afetar aplicações desktop/container; em servidor de hosting, faça teste funcional dirigido.

Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.

Medidas adotadas pela WebinHost

A WebinHost avalia a necessidade de namespaces por host, aplica a mitigação quando segura e compara o kernel com a linha CloudLinux. KernelCare é confirmado por CVE quando existe; o fornecedor não planejou livepatch para linhas sem correção vendor. Imunify360 reduz o primeiro acesso via site comprometido.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Escopo dos planos gerenciados: a WebinHost prioriza falhas críticas e altas na infraestrutura administrada. Sites, temas, plugins, código e credenciais do cliente continuam exigindo atualização e revisão pelo responsável da aplicação, salvo contratação específica. O status deve ser confirmado por servidor; possuir KernelCare ou Imunify360 não é, isoladamente, prova de que todo CVE foi corrigido.

Tutoriais, downloads e serviços relacionados

Use estes materiais para continuar a verificação com segurança:

Referências oficiais e técnicas

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.

Precisa validar seu ambiente?

Conte com gerenciamento técnico de servidores

A atualização de aplicações do cliente e a administração do servidor têm escopos diferentes. Fale com a equipe para avaliar o ambiente e o plano adequado.