Um relatório privado de bug chega ao público
A Zero Day Initiative (ZDI) da Trend Micro deu início ao “Black October” em 22 de outubro, quando publicou erroneamente um cache de vulnerabilidades não corrigidas do kernel Linux na lista de discussão pública do Linux Kernel, em vez da lista de segurança privada. O mantenedor estável do Linux, Greg Kroah-Hartman, desafiou publicamente a ZDI na lista, exigindo uma explicação pela divulgação prematura de exploits zero-day.
Criticamente, o vazamento expôs duas vulnerabilidades graves de Server Message Block (SMB), ambas classificadas com CVSS 9.0 e capazes de execução remota de código. Uma falha, um integer underflow no SMB Direct (ZDI-CAN-33549), permitia buffer overflows manipulando valores de tamanho de buffer. A segunda, uma race condition no ksmbd (ZDI-CAN-33774), permitia a execução remota de código sem autenticação.
Os relatórios chegaram antes que as correções estivessem amplamente disponíveis, expondo milhões de sistemas. Esta não foi uma publicação deliberada ou evidência de um ataque ativo, mas sim uma divulgação acidental, ressaltando a pressão crescente sobre a divulgação coordenada de vulnerabilidades. O design do SMB, que processa dados de rede externos para compartilhamento de arquivos, tornou esses bugs particularmente perigosos, lembrando a epidemia de WannaCry de 2017.
Por que bugs no SMB podem se tornar um problema para todos
Server Message Block, ou SMB, é o protocolo de rede que permite o compartilhamento de arquivos e pastas. Sua arquitetura o torna inerentemente perigoso: serviços que lidam com dados de rede recebidos, como o SMB, geralmente são executados antes do login, tornando-os acessíveis a atacantes não autenticados. Essa exposição direta à internet amplia o raio de impacto de qualquer falha.
Vimos esse perigo em primeira mão em 2017 com o WannaCry, um surto de ransomware que explorou uma vulnerabilidade do SMB no Windows. Embora os bugs atuais do Linux sejam distintos, o WannaCry serve como um lembrete claro de quão rapidamente as falhas no SMB podem comprometer redes inteiras. As vulnerabilidades de SMB do kernel Linux, ambas classificadas como 9.0 na escala de severidade CVSS, apresentam riscos semelhantes de execução remota de código.
Além das falhas críticas no SMB, outros problemas relatados incluem:
- Escalações de privilégio local na pilha de rede (
skb_zerocopy) - Uma escalação de privilégio local no driver gráfico da VMware (
vmwgfx) - Um vazamento de informações no código de destino NVMe (
nvmet)
A exposição a essas vulnerabilidades adicionais varia drasticamente com base na configuração e implantação do sistema. Embora não sejam tão catastroficamente imediatas quanto as RCEs de SMB, essas questões ressaltam a fragilidade sistêmica revelada durante o "Black October".
Black October foi um acúmulo de divulgações
O Black October não foi apenas um vazamento do Linux; foi um dilúvio. A exposição acidental de vulnerabilidades não corrigidas do kernel chegou em meio a uma tempestade de divulgações críticas de segurança, levando organizações globais ao limite. Mais notavelmente, duas falhas graves no PHP (CVE-2026-109618, CVE-2026-109619) forçaram governos na França, Holanda e Finlândia a tirar sites públicos do ar para correções emergenciais.
Este não foi um ataque coordenado, mas sim uma pressão simultânea de várias frentes. Relatórios adicionais se acumularam:
- O comprometimento da autoridade certificadora da eMudhra, necessitando de revogações rápidas em nível de navegador.
- Um bug no GitLab com CVSS 10 que remonta a 2014.
- Uma correção de execução remota de código no Node.js.
- Relatórios de agentes de IA não autorizados aparecendo em contas bancárias dos EUA.
Esta onda de divulgações públicas, embora intensa, não é equivalente a uma onda de ataques confirmados. Muitos desses problemas, incluindo os bugs do Linux kernel detalhados pelo Phoronix, haviam sido descobertos semanas ou meses antes. As organizações estavam simplesmente correndo para corrigi-los à medida que se tornavam de conhecimento público. Várias vulnerabilidades do Linux Kernel postadas acidentalmente na lista de discussão pública do Kernel - Phoronix Este "Outubro Negro" serviu como uma prévia clara: o gargalo mudou da descoberta de bugs para a rapidez em corrigi-los.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
A IA acelera a descoberta; a aplicação de patches define o ritmo
A IA acelerou a descoberta de falhas legadas, mas a aplicação de patches orientada por humanos permanece teimosamente lenta. Os mantenedores agora enfrentam uma "onda de patches de vulnerabilidade", à medida que ferramentas de IA como o Mythos da Anthropic descobrem centenas de bugs críticos em produtos como o SharePoint, superando vastamente a capacidade humana. A equipe do Google Chrome, por exemplo, agora envia atualizações de segurança duas vezes por semana.
Isso cria uma janela cada vez menor para os defensores. As correções públicas revelam inerentemente o que mudou, fornecendo aos atacantes um roteiro para o desenvolvimento de exploits. Simultaneamente, os defensores ganham acesso a ferramentas de segurança assistidas por IA, potencialmente nivelando o campo de jogo assim que a enxurrada inicial de bugs facilmente detectáveis diminuir.
Prioridades práticas emergem desta nova realidade. As organizações devem:
- Inventariar todos os sistemas voltados para a internet
- Atualizar o PHP e outros softwares afetados imediatamente
- Ficar atentos às correções do Linux kernel, verificando se o ksmbd está habilitado
- Desabilitar componentes não utilizados
- Automatizar processos de patching seguro sempre que possível
A aplicação de patches deve se tornar uma operação contínua, não uma tarefa trimestral. O NCSC recomenda uma política de "atualização por padrão", priorizando sistemas expostos à internet e substituindo softwares legados que não podem ser corrigidos.
Perguntas Frequentes
O que aconteceu no vazamento de vulnerabilidade do Linux kernel?
A Zero Day Initiative da Trend Micro enviou acidentalmente relatórios de vulnerabilidades não corrigidas para a lista de discussão pública do Linux kernel em vez de um canal de segurança privado.
Por que as falhas de SMB no Linux foram consideradas perigosas?
As duas falhas relatadas foram classificadas com CVSS 9.0 e poderiam permitir a execução remota de código em códigos relacionados ao SMB que processam tráfego de rede.
O vazamento significa que os sistemas Linux estavam sendo atacados ativamente?
Não necessariamente. A divulgação tornou as vulnerabilidades públicas, mas o vídeo descreve uma onda mais ampla de divulgações de vulnerabilidades, em vez de confirmar ataques explorando essas falhas específicas.
O que os administradores Linux devem fazer?
Aplique as atualizações de distribuição relevantes prontamente, verifique se o ksmbd está habilitado e desabilite serviços ou componentes expostos não utilizados enquanto aguarda as correções.