Black October: a semana em que a IA ofensiva quebrou a internet

Se o seu time de tecnologia andou estranho nas últimas semanas — reunião fora de hora, deploy em sexta à noite, aquele silêncio tenso no canal de infra — existe uma explicação bem concreta. O mercado global de segurança já batizou o período: Black October.

Não houve um grupo de ransomware coordenando nada. Não houve uma marca específica na mira. O que aconteceu foi mais incômodo: entre 20 e 23 de outubro de 2026, várias das tecnologias que sustentam a internet moderna revelaram falhas críticas simultaneamente.

No dia 21 de outubro, especificamente, saíram ao mesmo tempo: a correção crítica do PHP, a release de segurança do Node.js, o patch de severidade máxima do GitLab e o pacote envenenado do LiteLLM no PyPI. Um único dia que obrigou boa parte do mercado a refazer o plano da semana.

E aqui está a parte que muda o jogo a médio prazo. Parte relevante dessas descobertas veio de pesquisa ofensiva assistida por IA. Bugs que dormiam no código-fonte há anos — esperando alguém com tempo, paciência e profundidade suficiente para encontrá-los — foram identificados, testados e publicados em uma fração do tempo que isso levaria antes. No caso do GitLab, a falha alcança instalações desde a versão 7.0, ou seja, esteve ali por mais de uma década sem que ninguém a visse.

A conclusão prática é desconfortável: a janela entre "a falha existe" e "a falha está sendo explorada" encolheu. O ciclo de patch mensal que funcionava em 2023 não funciona mais.

Abaixo, caso a caso: o que quebra no seu negócio, o detalhe técnico que importa e o passo a passo de mitigação.

1. PHP: RCE sem autenticação em 70% da internet

CVE-2026-109618 e CVE-2026-109619 — divulgadas em 21/10/2026, classificadas como críticas pelo próprio projeto PHP.

O impacto no negócio

O PHP roda por trás de mais de 70% dos sites do mundo: WordPress, Drupal, Joomla, Magento e aquele sistema interno que "ninguém mexe desde 2019 porque funciona".

Um atacante não precisa de login, senha vazada ou engenharia social. Ele envia requisições especialmente formatadas e passa a executar comandos com os privilégios do processo web. Traduzindo para consequência de negócio: leitura do wp-config.php com as credenciais do banco, dump da base de clientes, implante de webshell persistente e redirecionamento de checkout. Em e-commerce, o padrão clássico é a injeção de skimmer na página de pagamento — o site continua funcionando perfeitamente enquanto os cartões vazam.

Para efeito de LGPD, uma base de clientes exfiltrada por aqui é incidente de segurança com dever de comunicação à ANPD. E a comunicação exige que você saiba o que vazou — o que, sem log adequado, é exatamente o que ninguém consegue responder.

O detalhe técnico

São falhas de corrupção de memória do tipo use-after-free (CWE-416). A CVE-2026-109618 é descrita pelo projeto como RCE via OOM corruption: quando o processo estoura o limite de memória, o PHP é interrompido no meio da requisição com estruturas internas apenas parcialmente inicializadas. Manipular esse estado permite execução de código.

O vetor de maior risco é o mod_php, mas a execução de código também foi validada contra PHP-FPM — então rodar FPM não tira você da lista.

Como saber se você está exposto: toda instalação não corrigida está. O que vale conferir é se a mitigação paliativa não está sendo anulada pela própria aplicação:

// A mitigação oficial é memory_limit = -1 (sem limite, o caminho de OOM
// nunca é alcançado). Qualquer lib que reimponha um limite em runtime
// reabre a condição de corrupção de memória:
ini_set('memory_limit', '256M');   // comum em plugins de WP, geradores de PDF e rotinas de import

Se o seu php.ini define memory_limit = -1 mas um plugin chama ini_set() com um valor finito, você voltou ao estado vulnerável sem perceber.

Como saber se você está exposto — procure por este padrão no seu código:

const zlib = require('node:zlib');

app.post('/webhook', (req, res) => {
  // corpo comprimido vindo de fora, descomprimido sem validação prévia
  const payload = zlib.brotliDecompressSync(req.body);
});

É isso que coloca você no vetor: descomprimir Brotli controlado pelo atacante. Vale também para bibliotecas que fazem isso por baixo dos panos — middlewares que honram Content-Encoding: br na entrada, e clientes HTTP que buscam conteúdo comprimido de fontes externas.

Como saber se você está exposto — e por que a conferência ingênua engana:

$ cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
19.4.2
# Parece atualizado: é o patch de 12/10.
# E NÃO corrige a CVE-2026-110264. Só a partir de 19.4.3.

Passo a passo de mitigação

1. Inventarie. php -v em cada host, incluindo containers e o PHP da CLI (que frequentemente é outra versão do que serve a web).

2. Atualize para a linha segura:

   Linha	Versão mínima segura
   8.2	8.2.35
   8.3	8.3.36
   8.4	8.4.27
   8.5	8.5.12

3. Reinicie os serviços. systemctl restart php8.x-fpm e o Apache/Nginx. Sem restart, o processo antigo segue vulnerável em memória — esse passo é esquecido com uma frequência alarmante.

4. Cuidado ao conferir a versão em distro. Debian, Ubuntu e RHEL fazem backport da correção mantendo o número de versão antigo. Valide pelo advisory da sua distribuição (apt changelog php8.x ou o errata do fornecedor), não pelo php -v isolado.

5. Se não puder atualizar hoje, o advisory oficial descreve mitigações parciais: memory_limit=-1 aplicado de forma que a aplicação não consiga sobrescrever, post_max_size baixo, e limite de memória via container/cgroup. O próprio advisory desaconselha RLIMIT_AS e RLIMIT_DATA. São paliativos, não correção.

6. Rodando PHP 7.x, 8.0 ou 8.1? Não existe patch — essas linhas estão fora de suporte. A recomendação é isolar esses servidores da internet pública até a modernização. Não é exagero: é a única mitigação real quando não haverá correção.

7. Audite. Procure arquivos criados ou modificados no webroot nos últimos 15 dias e requisições anômalas com corpo grande nos logs do período.

2. Node.js: o risco mora numa biblioteca que você não escolheu

CVE-2026-111497 — release de segurança de 21/10/2026, com 10 vulnerabilidades corrigidas, 4 delas de severidade alta.

O impacto no negócio

Node.js sustenta APIs, microsserviços, painéis administrativos e portais em nuvem na maioria das empresas que modernizaram stack nos últimos anos. É tipicamente a camada que fala com banco de dados, gateway de pagamento e serviços internos — comprometer o processo Node costuma significar acesso às credenciais de tudo que ele consome.

Vale notar que a falha do Brotli não foi a única: a mesma release corrigiu dois bypasses de validação de hostname em certificados TLS (CVE-2026-105483 e CVE-2026-106069) e uma falha de truncamento de nome em DNS (CVE-2026-105482). Na prática, isso significa que sua aplicação podia aceitar como legítimo um certificado que não é — abrindo caminho para interceptação de tráfego entre serviços.

O detalhe técnico

A CVE-2026-111497 é uma escrita fora dos limites (out-of-bounds write) no decodificador Brotli embarcado no Node. Dados comprimidos malformados fazem o decoder escrever além do buffer interno, causando crash, vazamento de memória do processo e, sob certas condições, execução de código.

O ponto importante para dimensionar risco: você só está exposto se a aplicação (ou alguma biblioteca dela) descomprime dados Brotli controlados pelo atacante. Um servidor que apenas comprime respostas não está no vetor. O risco está em quem aceita Content-Encoding: br em requisições de entrada ou busca conteúdo comprimido de fontes externas.

Existe PoC público desde menos de um dia após a release — por ora demonstrando apenas o crash, não a execução de código. A severidade é disputada: o Node classifica como alta, o time de segurança do Ubuntu tratou como média.

Passo a passo de mitigação

1. Atualize:

   Linha	Versão mínima segura
   22.x	22.23.4
   24.x (LTS)	24.22.1
   26.x	26.12.1

2. Node 20, 23 ou 25? Fora de suporte, sem correção. Migração para linha suportada é o único caminho.

3. Reconstrua as imagens de container. Este é o ponto cego real. Rodar node -v em produção e ver versão corrigida não significa nada se o Dockerfile continua apontando para uma imagem base antiga — o próximo deploy reintroduz a falha com o carimbo de aprovação do seu CI/CD. Fixe a tag da imagem base, rebuilde e republique.

4. Mitigação de borda enquanto o rebuild não sai: remova o header Content-Encoding: br de requisições vindas de tráfego não confiável no reverse proxy ou WAF, ou desative a descompressão Brotli na camada de aplicação.

5. Revise as integrações TLS. Se sua aplicação faz chamadas a serviços internos por IP, as falhas de validação de certificado desta mesma release merecem uma conferida nos logs de conexão.

3. GitLab self-managed: CVSS 10.0, e 10.0 é o teto da escala

CVE-2026-110264 — patch crítico publicado em 21/10/2026.

O impacto no negócio

Se a sua empresa hospeda a própria instância do GitLab, trate isso antes de qualquer outra coisa desta lista.

O servidor de GitLab não guarda só código. Ele guarda o código proprietário da empresa, as variáveis de CI/CD com segredos de produção, os tokens de deploy e as chaves que publicam em nuvem. Comprometer o GitLab não é comprometer um sistema — é receber o molho de chaves de todos os outros, com a documentação de como usá-los junto.

O cenário de pior caso aqui não é vazamento de dados: é injeção de código malicioso no seu produto, distribuído aos seus clientes pela sua própria esteira assinada. Foi exatamente assim que o LiteLLM caiu na mesma semana.

A mesma release ainda corrige CVE-2026-15723 (CVSS 8.2, tomada de conta via vinculação OmniAuth→LDAP) e CVE-2026-112212 (CVSS 7.5, envenenamento de cache de discovery OAuth/OIDC). No total, 12 correções.

O detalhe técnico

É um integer overflow no compilador de expressões regulares do GitLab, permitindo execução de código por usuário não autenticado. A falha alcança instalações desde a versão 7.0 — mais de uma década de exposição.

Dois avisos que separam quem corrigiu de quem acha que corrigiu:

• Não há workaround. O GitLab não publicou mitigação por configuração. Atualizar é a única correção.
• Os patches de 12 de outubro não resolvem. Se você aplicou 19.2.8, 19.3.5 ou 19.4.2 naquela janela e considerou o assunto encerrado, você ainda está vulnerável.

Passo a passo de mitigação

1. Atualize hoje para 19.5.1, 19.4.3, 19.3.6 ou o backport da sua linha: 19.2.9, 19.1.9, 19.0.10 ou 18.11.13.
2. Tire a interface web da internet pública. Acesso só por VPN interna ou lista de IPs. Para a maioria das empresas, não existe motivo real para o GitLab interno estar exposto ao mundo.
3. Audite os logs antes de considerar encerrado — production.log e gitlab-rails, procurando requisições anômalas a endpoints não autenticados no período anterior ao patch.
4. Se houver qualquer indício de acesso, rotacione tudo que o GitLab guardava: variáveis de CI/CD, Project e Group Access Tokens, Runner tokens, chaves de deploy e chaves SSH cadastradas. O patch fecha a porta; ele não invalida o que já foi copiado.
5. Quem usa GitLab.com (SaaS) já foi mitigado pela própria fabricante — mas os passos 3 e 4 continuam valendo se você tem integrações com segredos de longa duração.

4. O que nenhum patch conserta: as chaves que já foram copiadas

A semana não foi só sobre software desatualizado. Ela expôs o elo que update nenhum resolve: credenciais.

LiteLLM 1.107.0 — pacote envenenado no PyPI e no Docker Hub

Biblioteca amplamente usada para integrar aplicações a modelos de IA. Em 21/10/2026, wheels maliciosos e imagens Docker oficiais foram distribuídos após atacantes usarem credenciais roubadas do GitHub para publicar a release. É o segundo comprometimento de cadeia de suprimentos do projeto no ano.

O detalhe técnico que mais importa: o stealer executa no startup do Python. Os sete wheels continham arquivos (cook.pth, cook.py, sitecustomize.py) que rodam quando o interpretador sobe — você não precisava nem importar o LiteLLM para ser comprometido. O payload coleta credenciais de nuvem, SSH, CI/CD, navegador e ferramentas de IA, e estabelece um canal de execução remota horária. A exfiltração vai para um domínio sósia, litellm[.]dev.

Como você pegou a versão envenenada — e como detectar:

# requirements.txt sem pin resolveu para a 1.107.0 durante a janela:
litellm

# Detecção (o stealer roda no startup do Python, não é preciso importar nada):
find / \( -name "cook.pth" -o -name "cook.py" \) 2>/dev/null

Mitigação: fixe a versão 1.106.2 (a última segura), remova cook.pth, cook.py e sitecustomize.py de site-packages, reconstrua os containers a partir de imagem limpa e rotacione todas as credenciais alcançáveis a partir de uma máquina sabidamente limpa — rotacionar de dentro do host comprometido só entrega as chaves novas. Clientes do registry privado enterprise não foram afetados.

Railway e Zeabur — segredos de clientes acessados

Railway: acesso não autorizado a sistemas internos entre 20 e 22 de outubro, com decriptação de um subconjunto de variáveis de ambiente de clientes. O relatório preliminar aponta até 1,85% dos workspaces afetados. A Railway classificou o caso como parte de uma campanha contra provedores de inferência de IA e orientou todos os usuários a rotacionar segredos — inclusive os que foram removidos da plataforma no passado, já que apagar a variável não revoga a chave por trás dela.

Zeabur: dois incidentes, em agosto e outubro. O de outubro atingiu clusters compartilhados em nove regiões, com cerca de 321 mil contas e 3,2 milhões de registros de variáveis de ambiente. A Zeabur anunciou o encerramento das operações entre 1º e 31 de dezembro de 2026 — se você tem carga lá, isso deixou de ser um problema de segurança e virou um prazo de migração.

A regra que a maioria das empresas erra

Atualizar o software fecha a porta para o próximo invasor, mas não revoga a chave que já foi copiada. Um segredo exfiltrado antes do patch continua válido depois dele, e vai continuar válido até alguém rotacionar manualmente. Atacantes sabem disso e frequentemente esperam semanas antes de usar o que coletaram — justamente porque a empresa já deu o incidente por encerrado.

Rotação obrigatória, nesta ordem:

1. Tokens de API de IA (OpenAI, Anthropic, Google Cloud) e de gateways de pagamento — são os de monetização mais rápida e os alvos declarados desta campanha;
2. Credenciais de bancos de dados em produção;
3. Tokens de acesso e chaves SSH de GitHub/GitLab;
4. Chaves de provedor de nuvem (AWS/GCP/Azure) e webhooks com segredo compartilhado.

O checklist para repassar à sua equipe técnica

Copie e mande para o responsável pela TI ou para o fornecedor do seu site. Todas as perguntas pedem resposta objetiva — não um "está tudo certo".

1. Inventário. Levantamos todos os servidores, sites e APIs com PHP e Node.js, incluindo os que ninguém mexe há anos?
2. Atualização. As versões estão nas linhas seguras, e os serviços foram reiniciados depois do patch?
3. GitLab. Se temos instância própria, aplicamos o patch de 21/10 — e não paramos nos patches de 12/10, que não corrigem a CVE-2026-110264?
4. Contêineres e CI/CD. As imagens Docker e as esteiras foram reconstruídas, para que o próximo deploy não reintroduza a versão vulnerável?
5. Fim de suporte. Algum ambiente roda PHP ≤ 8.1 ou Node 20/23/25? Qual é o plano e o prazo, já que não haverá correção?
6. Rotação de chaves. Trocamos as credenciais dos serviços expostos — a partir de uma máquina limpa — e não apenas aplicamos o patch?
7. Auditoria. Olhamos os logs do período anterior ao patch procurando tentativas de exploração, ou estamos assumindo que não houve?

Se a resposta a qualquer uma delas for "acho que sim", a resposta é não.

O que o Black October ensina para além deste mês

Patch é higiene, não estratégia. O que mudou em outubro de 2026 não foi a quantidade de falhas — foi a velocidade com que elas passam de desconhecidas a exploradas em massa. Pesquisa ofensiva assistida por IA está disponível para os dois lados do balcão, e o lado que explora não precisa aprovar janela de manutenção.

Muita empresa acredita estar protegida porque o site "continua no ar". É exatamente esse o problema: falhas silenciosas não derrubam nada. Elas mantêm portas abertas para exfiltração — e, quando aparecem, aparecem como comunicação à ANPD, não como alerta de monitoramento.

O Black October foi a emergência desta semana. Mas o que reprova empresas em auditoria quase nunca é a CVE do noticiário — são as mesmas falhas recorrentes, que estavam lá antes de outubro e continuarão depois. Reunimos as 10 que mais aparecem nos nossos testes de invasão em um PDF gratuito de 10 páginas: As 10 falhas que reprovam empresas em auditoria de segurança.

Fontes e Referências

PHP (CVE-2026-109618 / CVE-2026-109619)

• Advisory oficial: Security advisory: Critical remote code execution vulnerabilities, update now — php.net
• GitHub Security Advisory: GHSA-w8hw-w9fx-j79w
• Registros CVE: CVE-2026-109618 | CVE-2026-109619
• Alerta governamental: Canadian Centre for Cyber Security — AL26-026
• Versões suportadas: php.net/supported-versions

Node.js (CVE-2026-111497 e demais)

• Release de segurança oficial: October 2026 Security Releases — nodejs.org
• Registro CVE: CVE-2026-111497
• Calendário de suporte: Node.js Releases

GitLab (CVE-2026-110264)

• Patch crítico oficial: GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
• Registro CVE: CVE-2026-110264

Cadeia de suprimentos e nuvem

• LiteLLM — análise técnica: Datadog Security Labs
• LiteLLM — cobertura do incidente: The Hacker News
• Railway — orientação de rotação de segredos: BleepingComputer
• Zeabur — comunicado de incidente: zeabur.com/blogs
• Zeabur — encerramento das operações: BleepingComputer

Conecte-se com o autor para networking e mais pesquisas técnicas: LinkedIn | X/Twitter