A semana que antecedeu o dia 25 de outubro de 2026 foi o pesadelo de qualquer profissional de cibersegurança: uma enxurrada de vulnerabilidades críticas no PHP e no kernel Linux, uma versão comprometida do LiteLLM, uma falha de severidade máxima no GitLab, uma brecha no Brotli do Node.js e um incidente com uma autoridade certificadora que afetou a confiança no TLS.

Há alguns anos, um acúmulo de problemas como esse ocuparia a lista de tarefas de uma equipe de defesa por um mês inteiro. Na era da IA, tudo isso foi divulgado em uma semana caótica para a cibersegurança, um período excepcionalmente agitado em meio a um mês de outubro que já vinha bastante turbulento. Pesquisas assistidas por IA ajudaram a descobrir pelo menos duas dessas falhas: o PHP2Shell e o bug do Brotli. Além do ritmo frenético de aplicação de correções, as equipes de segurança enfrentaram uma pressão crescente para entregar relatórios de status a outros departamentos, à diretoria, aos clientes e à imprensa.

Além da gravidade, os problemas se destacaram pela variedade de respostas que exigiram. Alguns demandaram patches emergenciais e atualizações de runtime; outros pediram contenção, troca de credenciais ou a substituição de pacotes de certificados confiáveis desatualizados. Em vários casos, instalar a versão mais recente foi apenas o começo de um longo processo de remediação.

Com tantos problemas surgindo ao mesmo tempo, o principal desafio foi separar o risco real do alarde e definir prioridades. Veja a nossa avaliação.

PHP2Shell: a manchete mais barulhenta, com limites no mundo real

O PHP2Shell gerou o maior frenesi na mídia entre todos os casos e, com ele, uma enorme dor de cabeça para as equipes de segurança, levando muitas organizações a tirar seus sites do ar e buscar correções emergenciais. O nome se refere a duas vulnerabilidades de segurança de memória no núcleo do PHP, CVE-2026-109618 e CVE-2026-109619, que afetam as versões do PHP da 5.4 até a 8.5.11. Ambas receberam pontuação 9.2 no CVSS v4.0 e podem permitir a execução remota de código (RCE) sem autenticação em servidores PHP vulneráveis. Nas configurações de maior risco, um exploit já demonstrado consegue acionar a vulnerabilidade antes mesmo de o código da aplicação ser executado, o que significa que a autenticação no nível da aplicação não oferece nenhuma proteção.

Como o PHP está por trás de cerca de 69% dos sites cuja linguagem de programação no servidor é conhecida, agências governamentais dos Estados Unidos, da Europa e de outras regiões pediram que as organizações aplicassem as correções imediatamente, e algumas recomendaram isolar ou tirar do ar os sistemas afetados expostos à internet caso não fosse possível corrigi-los rapidamente. Sites governamentais na Holanda, na Alemanha, na França e em outros países foram temporariamente desativados por precaução. O projeto PHP lançou as correções em 21 de outubro nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, além de backports apenas em código-fonte para os ramos 7.4, 8.0 e 8.1, que já chegaram ao fim do ciclo de vida. A distribuição das correções foi complicada por um vazamento público prematuro, que obrigou a antecipar o cronograma de divulgação coordenada.

Embora as falhas claramente merecessem estar perto do topo da lista de correções, as primeiras evidências indicaram que elas eram bem mais difíceis de transformar em arma do que se temia inicialmente. Segundo a Sansec, a exploração bem-sucedida exige condições específicas e conhecimento sobre o alvo, e as provas de conceito (PoCs) públicas não funcionavam contra uma instalação padrão do PHP.

Em 22 de outubro, a ESET estava entre as nove empresas de segurança que disseram à NBC News não ter observado nenhum ataque bem-sucedido, mesmo com mais de 200 exploits de prova de conceito em circulação. O desafio da remediação vai além dos servidores web óbvios: o PHP também pode estar embutido em appliances, dispositivos de rede, interfaces de gerenciamento e produtos de terceiros, e os ramos do PHP em fim de ciclo de vida não recebem versões binárias regulares do projeto original.

Kernel Linux: relatórios se tornaram públicos antes de as correções ficarem prontas

Como se os problemas do PHP não fossem graves o bastante, em 21 de outubro a Zero Day Initiative (ZDI), da Trend Micro, enviou vários relatórios sobre vulnerabilidades ainda não corrigidas do kernel Linux para o endereço privado de segurança do kernel, mas copiando também listas de discussão públicas. Com isso, detalhes técnicos de vulnerabilidades sem correção amplamente disponível vieram a público, o que levou Greg Kroah-Hartman, mantenedor do kernel estável, a questionar por que os relatórios haviam sido enviados a listas públicas sem patches.

Os dois problemas mais graves, ambos classificados com CVSS 9.0 pela ZDI, afetam o KSMBD, o servidor SMB integrado ao kernel Linux. O ZDI-CAN-33549 é um underflow de inteiro no caminho do SMB Direct que pode levar a RCE, enquanto o ZDI-CAN-33774 é uma condição de corrida que também pode resultar em RCE. Explorar o ZDI-CAN-33549 exige uma interface compatível com RDMA, um compartilhamento KSMBD com permissão de escrita e a negociação do SMB Direct, o que reduz bastante o número de sistemas expostos a esse ataque específico. Outros relatórios tratavam de vulnerabilidades de escalonamento local de privilégios na pilha de rede e no driver gráfico da VMware, além de um problema de divulgação de informações no código de destino NVMe (NVMET).

Para remediar, as equipes de segurança precisaram acompanhar cada relatório separadamente, consultar os boletins das distribuições e restringir os serviços expostos sempre que possível, enquanto aguardavam correções verificadas. As atualizações do kernel também exigiam reiniciar o sistema no kernel corrigido e conferir a versão em execução, e não apenas confirmar que um novo pacote havia sido instalado.

LiteLLM: comprometido, não apenas vulnerável

Em 21 de outubro, atacantes publicaram no PyPI uma versão maliciosa do LiteLLM, a 1.107.0, e enviaram imagens comprometidas aos registros oficiais de contêineres do projeto. De acordo com o relatório de incidente do projeto, o pipeline de lançamento foi invadido com credenciais do GitHub CLI associadas a três desenvolvedores. Um dos tokens roubados pertencia a um proprietário da organização do projeto no GitHub, o que permitiu aos atacantes desativar as proteções de branch e alterar o fluxo de lançamento para apontar para um repositório falso muito parecido com o original. O LiteLLM, um proxy em Python para provedores de LLM, tem cerca de 23 milhões de downloads semanais, e a versão maliciosa ficou disponível no PyPI por aproximadamente duas horas antes de ser colocada em quarentena. Foi o segundo ataque à cadeia de suprimentos do projeto em 2026, depois que as versões maliciosas 1.82.7 e 1.82.8 apareceram em março.

O payload combinava um ladrão de credenciais com um trojan de acesso remoto (RAT) de segundo estágio. Ao abusar dos mecanismos de inicialização do Python, incluindo um arquivo .pth, ele era executado toda vez que o Python iniciava, mesmo que a aplicação nunca importasse o LiteLLM. Ou seja, a execução não dependia da exploração de uma falha na aplicação: bastava rodar o Python em um ambiente afetado.

Os ambientes afetados precisavam ser tratados como potencialmente comprometidos, e não apenas vulneráveis. Segundo o LiteLLM, isso incluía ambientes que executaram litellm==1.107.0 e contêineres que rodaram imagens afetadas distribuídas com as tags v1.107.0, latest, main-latest ou main-stable durante os intervalos de comprometimento. Remover ou substituir o pacote não era suficiente: as equipes precisavam determinar se o código malicioso havia sido executado, conter os sistemas afetados, reconstruí-los a partir de fontes limpas e trocar os segredos expostos usando um ambiente limpo. Também era necessário revisar os logs de nuvem, de controle de código-fonte e de CI/CD em busca de atividades não autorizadas.

Node2Shell: do Node.js ao HTTP2Shell

O Node2Shell (CVE-2026-111497) é uma escrita fora dos limites (out-of-bounds write) no decodificador Brotli do Google, que vem embutido no Node.js. Uma entrada comprimida malformada pode causar travamentos, vazamento de memória ou, potencialmente, RCE quando uma aplicação descomprime dados Brotli controlados por um atacante. Isso pode acontecer por meio de descompressão explícita, corpos de requisição comprimidos ou respostas descomprimidas automaticamente. O Node.js classifica a falha como de alta severidade, enquanto a vulnerabilidade mais ampla do Brotli tem pontuação 9.2 no CVSS v4.0. Segundo a Aikido, pesquisadores demonstraram a execução de código contra a imagem oficial e sem modificações do Node.js 24.22.0 no Linux ARM64. Embora o exploit não funcionasse em todas as tentativas, a demonstração mostrou que a exploração era viável na prática, ainda que não fosse confiável em todos os casos.

O Node.js lançou as correções em 21 de outubro nas versões 22.23.4, 24.22.1 e 26.12.1, e o Bun veio em seguida com a versão 1.4.4 ou posterior. As versões 25.x, 23.x, 20.x e anteriores do Node.js estão em fim de ciclo de vida e não receberão a correção. Em poucos dias, a história foi além do Node.js. O mesmo decodificador é compilado nos pacotes Python Brotli e brotlicffi, além de outros softwares HTTP, o que levou os pesquisadores a rebatizar o problema como HTTP2Shell. Assim, o desafio operacional não era apenas atualizar um único runtime, mas identificar cada contêiner, implantação serverless e biblioteca que trazia o decodificador vulnerável. O problema foi corrigido na origem no Brotli 1.2.1. Vale destacar que o Codex Security, da OpenAI, havia relatado o bug subjacente, e a correção já estava no código-fonte do Brotli desde fevereiro sem ter sido reconhecida como uma questão de segurança.

GitLab: vazamento de credenciais e falhas de autorização

Em 21 de outubro, o GitLab lançou uma atualização de segurança crítica fora do calendário regular (versões 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13) que corrige 12 vulnerabilidades. A falha principal, CVE-2026-110264, com nota 10.0 no CVSS v3.1, é um overflow de inteiro acionado quando o GitLab compila uma expressão regular especialmente elaborada. Em determinadas condições, ela pode permitir que um atacante não autenticado execute código arbitrário no servidor. As versões afetadas remontam ao GitLab 7.0.

As demais correções trataram de exposição de credenciais, envenenamento de cache, desvios de autorização e falhas na aplicação de políticas de associação ou de aprovação de merge requests. Entre os vetores de ataque sem autenticação relatados estavam a exposição de credenciais sensíveis por meio de cabeçalhos de resposta internos e a manipulação de um cache compartilhado de descoberta OAuth/OIDC, enquanto outros problemas exigiam acesso autenticado. O GitLab não divulgou pontuações de severidade individuais nem detalhes sobre a explorabilidade dessas falhas.

O GitLab.com e o GitLab Dedicated já estavam corrigidos, então o trabalho ficou por conta dos administradores de instâncias autogerenciadas. O GitLab recomendou fortemente a atualização imediata, mas com uma ressalva: os backports mais antigos (19.2.9, 19.1.9, 19.0.10 e 18.11.13) incluíam apenas a correção crítica, enquanto os outros 11 problemas só foram corrigidos a partir da 19.3.6. Os administradores também precisaram verificar se todos os componentes da implantação haviam sido atualizados e avaliar a possível exposição de credenciais e de dados de projetos privados, já que aplicar o patch não invalidaria credenciais roubadas nem desfaria alterações não autorizadas.

eMudhra/emSign: confiança em certificados comprometida

O incidente de alta prioridade envolvendo a eMudhra/emSign não tinha relação com nenhuma vulnerabilidade de software. Várias autoridades certificadoras (CAs) intermediárias da eMudhra tinham chaves privadas inseguras, o que significa que atacantes poderiam, em tese, criar certificados que seriam considerados confiáveis por meio da cadeia de certificados emSign afetada. Embora os navegadores já tivessem atualizado seus repositórios de confiança e listas de revogação, algumas ferramentas do ecossistema Python continuavam confiando nas CAs intermediárias comprometidas por meio de seus próprios pacotes de certificados. Isso criou o risco de ataques man-in-the-middle (MITM) contra conexões TLS, incluindo as conexões com python.org e pypi.org.

A Python Software Foundation pediu que os usuários atualizassem imediatamente para, no mínimo, certifi 2026.10.19, pip 26.2.2 e uv 0.13.4, e a equipe principal do Python lançou versões emergenciais (3.15.2, 3.14.10, 3.13.18, 3.12.16 e 3.11.18) para atualizar o pip incluído. As atualizações precisavam chegar a todos os hosts, aplicações e ambientes virtuais existentes. As imagens de contêiner tiveram de ser reconstruídas com o cache de camadas desativado para obter os certificados de sistema mais recentes. A verificação decisiva era confirmar se os clientes implantados rejeitavam os caminhos de confiança comprometidos; apenas atualizar o Python não bastava.

Separando o sinal do ruído

A "Black Week da cibersegurança" mostrou que uma pontuação de severidade raramente conta a história completa. Uma falha do PHP com nota 9.2 que os atacantes tiveram dificuldade para explorar, um bug do GitLab com nota 10.0, relatórios do kernel expostos sem patches e um pacote envenenado que era executado na inicialização do Python exigiram, cada um, uma resposta diferente. O que todos tinham em comum era uma janela de exposição: o tempo entre a divulgação e a correção do último sistema afetado. No caso das falhas vazadas do kernel, essa janela se abriu antes mesmo de existir qualquer correção e, para as versões do PHP em fim de ciclo de vida, ela talvez nunca se feche completamente. É aqui que entra a proteção multicamadas da ESET, que usa detecção comportamental e outros mecanismos de segurança para ajudar a bloquear tentativas de exploração e manter os sistemas protegidos até que os patches sejam aplicados.

Ao mesmo tempo, os sinais nos quais as equipes de defesa confiam ficaram soterrados pelo ruído, desde varreduras em grande parte inofensivas até uma única regra comportamental disparando centenas de milhares de vezes em uma semana. O mais importante foi entender rapidamente quais incidentes realmente afetavam o ambiente de cada organização e o que cada um deles exigia. É exatamente esse o problema que o mecanismo de correlação da ESET, o ESET LiveCortex, e seu modelo especializado em cibersegurança, o ESET NeoCortex, foram criados para resolver: transformar um volume avassalador de dados brutos em incidentes compreensíveis, para que as equipes de defesa possam agir antes que os atacantes atinjam seus objetivos.