Black October 2026: PHP2Shell e os outros ataques

Em 48 horas, órgãos públicos europeus tiraram sites do ar por precaução, o GitLab corrigiu uma falha com nota 10,0, um pacote popular de IA foi envenenado no PyPI e descobriu-se que a chave privada de uma autoridade certificadora valia 4. A imprensa batizou a semana de Black October.

Neste artigo eu organizo o que aconteceu, explico o PHP2Shell, que é o centro da história, e separo o que está confirmado do que é rumor. Usei fontes primárias dos descobridores, dos fornecedores e dos próprios projetos, e marquei os pontos em que elas discordam.

Atualizado em 24 de outubro de 2026. A situação ainda evolui, então confira os avisos oficiais antes de agir.

O Black October não é o que parece

Não existe uma campanha única por trás do nome. É um rótulo da imprensa para incidentes que vieram a público entre 19 e 23 de outubro. Não achei a origem do termo, e um veículo que investigou também não encontrou o post do X que o teria criado.

Duas análises chegaram à mesma ideia: foi uma onda de divulgações, não uma onda de ataques. Muita coisa que apareceu nessa semana é antiga:

as chaves fracas da eMudhra foram geradas em abril de 2025;
o grupo de ransomware SafePay atua desde agosto de 2024;
a campanha da Lazarus que a Kaspersky descreveu começou em julho de 2025;
a OVHcloud diz que a máquina do desenvolvedor foi comprometida em outubro de 2025.

A semana foi o momento em que a conta chegou. Isso muda a pergunta de quem defende. A pergunta deixa de ser só “já apliquei o patch?” e passa a incluir “o que aconteceu no meu ambiente antes do patch?”.

O mapa em cinco grupos

Mapa do Black October em cinco grupos: software de base, segredos e cadeia de suprimentos, certificados, IA no ataque e ameaças persistentes — Ilustração 1: os incidentes do Black October agrupados por tema, com o fio condutor entre eles.

Software de base: PHP2Shell, Node.js, GitLab e SonicWall.
Segredos e cadeia de suprimentos: LiteLLM, OVHcloud CLI, Rank Math PRO, ConnectWise Cloud Backup e Railway.
Certificados e confiança: eMudhra e a validação de TLS do Node.js.
IA no ataque: Cairn, ARTEX e a descoberta do próprio PHP2Shell.
Ameaças persistentes: SafePay, Lazarus e o sequestro de relays do Tor.

Vou começar pelo PHP2Shell porque ele explica bem o clima da semana, e depois passo pelos outros grupos.

PHP2Shell, dia a dia

Na quarta-feira, 21 de outubro, o PHP publicou correções de emergência para duas falhas críticas no próprio motor da linguagem: a CVE-2026-109618 e a CVE-2026-109619, ambas com nota 9,2 (crítica) no CVSS v4.0. As duas podem permitir execução remota de código, sem autenticação e em condições específicas.

Linha do tempo com os principais eventos da semana do PHP2Shell, de 17 a 23 de outubro — Ilustração 2: a semana do PHP2Shell, entre a primeira tentativa de exploração e o novo alerta do PHP.

A Amazon registrou uma tentativa de exploração num honeypot em 17/10, quatro dias antes da divulgação, e diz que não sabe como o atacante soube da falha durante o período de sigilo. Detalhes vazaram em 20/10, e o PHP antecipou o patch. Na madrugada de 21/10, a Amazon já via provas de conceito na telemetria. A Cloudflare relatou ataques às 7h43 UTC, e as correções saíram às 14h UTC. Em seguida, sites públicos saíram do ar. No dia 23, o PHP alertou para uma terceira falha, a CVE-2026-115560, que só ocorre em configurações raras.

O que dizem os registros oficiais

As fontes de referência são os registros do CVE.org e os avisos de segurança do próprio PHP no GitHub (GHSA). Os dois concordam em tudo o que importa:

	CVE-2026-109618	CVE-2026-109619
Título oficial	RCE via OOM corruption	RCE via stale global state
Quem atribuiu	PHP Group (CNA)	PHP Group (CNA)
Nota	9,2, crítica (CVSS v4.0)	9,2, crítica (CVSS v4.0)
Vetor	`AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H`	`AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H`
Afetadas no registro	antes de 8.2.35, 8.3.36, 8.4.27 e 8.5.12	antes de 8.2.35, 8.3.36, 8.4.27 e 8.5.12
Publicação	21/10/2026	21/10/2026

Em português, o vetor diz que o ataque vem pela rede, sem privilégios e sem interação do usuário, com impacto alto em confidencialidade, integridade e disponibilidade. Mas ele também marca complexidade alta (AC:H) e requisitos de ataque presentes (AT:P). É por isso que o texto deste artigo diz “sem autenticação, em condições específicas”. A nota 9,2 já considera essas condições, e ela continua crítica.

Os avisos detalham o que são essas condições:

CVE-2026-109618: a prova de conceito completa foi validada com os limites padrão de entrada e de memory_limit, em servidores com vários workers no modelo prefork. O PHP confirma a execução remota de código em mod_php. No PHP-FPM ele considera o código suscetível, mas diz que nenhum exploit completo foi demonstrado. Para FrankenPHP e LSAPI, a avaliação é de suscetibilidade provável, sem validação.
CVE-2026-109619: a exploração exige duas requisições, uma que deixa estado da requisição acessível e outra que age sobre ele, atendidas pelo mesmo worker, com uma interrupção entre as duas. Os casos confirmados dependem de session.upload_progress.enabled, que vem ligado por padrão, ou, no PHP 8.5, de fatal_error_backtraces. O caminho de sessão foi validado contra mod_php e PHP-FPM.
Impacto: execução de código com as permissões da conta do worker web.

O registro da CVE inclui ainda a avaliação SSVC que a CISA anexa a vulnerabilidades (ADP Vulnrichment): exploração “none”, automatizável “no” e impacto técnico “total”. Ela reflete o momento da avaliação e não anula as tentativas observadas por outras fontes, mas combina com o debate que aparece mais adiante.

O bug, explicado sem mistério

Para entender o PHP2Shell, ajuda saber como o PHP atende um site. Um servidor mantém processos chamados workers, e cada worker atende uma requisição depois da outra. O PHP prepara a memória da requisição, roda o código e limpa tudo no final. O defeito aparece quando essa preparação é interrompida no meio.

Quatro passos que mostram como um erro de memória deixa estado interno corrompido para a requisição seguinte — Ilustração 3: o fluxo do PHP2Shell em alto nível. O worker sobrevive à falha e reaproveita um estado quebrado.

Pense num garçom que está montando uma mesa quando alguém o interrompe. Ele para no meio, com a mesa pela metade. O próximo cliente senta nela e encontra talheres apontando para um lugar que já foi desmontado. O PHP faz algo parecido: com falta de memória, ele aborta com um erro fatal enquanto os dados internos estão incompletos. A rotina de limpeza então trata como válido o que está quebrado, e o worker segue vivo e reutiliza esse estado na requisição seguinte.

É isso que o aviso do PHP descreve nas duas CVEs. A CVE-2026-109618 é a corrupção causada pela falta de memória, que deixa dados internos meio construídos. A CVE-2026-109619 é o estado global obsoleto: dados que sobrevivem depois de a memória a que se referem ter sido liberada, e que uma requisição posterior no mesmo worker acaba usando.

A Wiz detalha quatro defeitos agrupados nas duas CVEs, todos no tratamento de erro fatal. Dois são do tipo use-after-free, em que o programa usa memória que já devolveu ao sistema. Um deles está no tratamento de progresso de upload da sessão. Há ainda um vazamento remoto de memória, que sai num cookie PHPSESSID, e uma confusão de tipos no OPcache, o cache de código do PHP. A Wiz compara esse vazamento ao Heartbleed, a falha de 2014 que expunha memória de servidores. Todo gatilho conhecido é uma requisição multipart/form-data, o formato de envio de arquivos.

Quatro pontos tornam isso diferente da maioria das falhas que você lê por aí:

A falha está no PHP, não na aplicação. Um site com código impecável é afetado do mesmo jeito. A Wiz demonstrou execução remota de código em imagens padrão de WordPress, Drupal e Joomla, e a Calif cita uma lista bem maior de sistemas, com a ressalva de que o defeito é do motor.
Não exige login, mas exige as condições certas. O atacante não precisa de credencial nem da ajuda de ninguém. O vetor oficial, porém, marca complexidade alta e requisitos de ataque, e a Sansec observa que a exploração pede conhecimento específico do servidor alvo.
A configuração do servidor muda o risco. A execução de código está confirmada em mod_php, onde o ataque pode agir antes de qualquer código da aplicação rodar. No PHP-FPM, o caminho de sessão da CVE-2026-109619 foi validado, e para o resto o PHP fala em suscetibilidade provável, sem exploit completo demonstrado.
O bug é velho. Segundo a Wiz, a Calif e a Sansec, o código vulnerável existe desde o PHP 5.4. O registro oficial lista só as séries 8.2 a 8.5, e o PHP diz que as séries 8.1 e anteriores já não recebem atualizações do projeto. A Calif lembra que Stefan Esser já tinha achado, em 2004, uma execução de código ligada ao limite de memória, e que um relatório de 2020 e uma auditoria de 2024 tocaram em problemas relacionados, sem exploração comprovada.

Hoje o PHP está em cerca de 69% dos sites cuja linguagem de servidor se conhece, segundo a W3Techs (23/10/2026). Esse é o número que sustenta as manchetes sobre “70% da internet”. Ele é uma fatia de sites identificáveis, e não uma contagem absoluta, então desconfie de quem fala em um número fixo de milhões de sites.

Onde a IA entra

As fontes contam a história de formas diferentes.

Calif. Ryan Austin descreve o uso de agentes e de um assistente de LLM para revisar código-fonte e generalizar achados, sem arranjo especial nem modelo de acesso restrito. Ele não nomeia os modelos. A estratégia foi partir do histórico de vulnerabilidades do alvo, porque os modelos tendem a olhar o código recente, e não o obscuro. A pesquisa nasceu da iniciativa Patch the Planet, da OpenAI. A descoberta inicial foi em 1º de agosto, e o PHP confirmou uma prova de conceito em 15 de agosto.
Wiz. A empresa cita o Wiz Atlas, o Gemini 4 Argon e o GPT-5.6 Sol, usados na descoberta, no desenvolvimento do exploit, na detecção de ataques e na validação do patch, e para adaptar exploits a versões, configurações e layouts de memória diferentes. Ela fala em exploits para várias aplicações em horas e num pesquisador que concluiu em uma semana o que levaria meses a uma equipe, uma afirmação dela, sem dados de apoio no texto. Na linha do tempo da Wiz, a primeira descoberta foi em 19 de agosto, e o PHP só reconheceu o relato em 21 de setembro.

São duas trilhas de descoberta paralelas, e a Calif lista Wiz e OpenAI como co-descobridoras. Os avisos oficiais do PHP creditam quatro relatores, pelos nomes de usuário lcfr-hax, sagitzadik-wiz, tomash-areion e amyb-oai, os dois primeiros ligados à Calif e à Wiz. As datas diferem entre elas, e eu não consegui reconciliar todos os detalhes.

Na prática, a IA muda o custo do trabalho. As falhas estavam lá havia mais de uma década. Transformar uma corrupção de memória num caminho de erro obscuro em execução de código era trabalho de poucos especialistas, porque a cadeia de passos é longa e depende de versão e configuração. Os modelos reduzem esse custo. A Amazon viu provas de conceito poucas horas depois do patch e argumenta que a análise assistida por IA encurta o tempo entre correção e exploit, um raciocínio dela, sem dados no post.

Existe um freio, e ele importa. A Sansec afirma que os exploits públicos que testou não funcionam numa instalação padrão do PHP. A IA acelera o ataque, mas não derruba sozinha o efeito da configuração do servidor.

Estão explorando de verdade?

Depende de quem você pergunta, e vale separar tentativa de comprometimento.

A Amazon diz que o PHP2Shell vê tentativas amplas de exploração, mas que não está claro se alguma funcionaria em sistemas reais.
O watchTowr registrou exploração das duas CVEs na sua rede de honeypots em 21/10.
A CISA disse em 21/10 que não tinha observado exploração, e as duas CVEs não estavam no catálogo de vulnerabilidades exploradas (KEV) até 23/10, segundo as fontes que consultei.
O registro da CVE traz a avaliação SSVC da CISA, com exploração “none” e ataque não automatizável (“Automatable: no”), reforçando que o ataque depende de condições do alvo.
A Sansec revisou sua avaliação em 22/10: exploração em massa é menos provável do que ela esperava, porque nenhuma requisição única funcionando contra qualquer servidor vulnerável foi demonstrada.

Resumindo: há muita tentativa, e comprometimento confirmado em larga escala ainda não apareceu em fonte primária. Isso não é motivo para esperar.

Sobre os governos: Países Baixos, França, Alemanha, Finlândia, Bélgica e Tchéquia tiraram sites do ar por precaução, e há relatos de serviços do Reino Unido fora do ar. O CERT-EU orientou isolar sistemas expostos que não pudessem ser corrigidos, e o NCSC do Reino Unido sugeriu considerar desligá-los quando não houvesse mitigação. Nenhum governo relatou invasão até onde consegui apurar.

E a prova de conceito?

Calif: publicou a pesquisa técnica completa, com os quatro componentes da falha, vídeos de demonstração e a história da descoberta. Não publicou código de exploit. A pesquisa da Calif é a leitura que eu mais recomendo.
Wiz: demonstrou execução de código em WordPress, Drupal e Joomla e descreve os indicadores a procurar. Também não publicou o código.
watchTowr: diz que reproduziu as falhas e não divulgou detalhes antes dos patches.
PHP: os avisos de segurança (GHSA) do repositório oficial descrevem cada falha, e o projeto publicou ramos de código com a correção para o 7.4, o 8.0 e o 8.1.

Uma ferramenta chamada “php2shell” vazou antes do prazo, e repositórios de terceiros com exploits funcionais apareceram no GitHub. Não vou linkar nenhum deles. São códigos sem verificação para uma falha ainda sob ataque, em séries do PHP que nem sempre têm correção oficial, e esse tipo de repositório também é um vetor conhecido de código malicioso disfarçado. O que eles revelam, e isso importa para quem defende, é que a exploração costuma exigir condições específicas, como funcionalidades de sessão ligadas ou limites de memória fora do padrão. É coerente com a avaliação da Sansec.

Segredos e cadeia de suprimentos

Aqui está o grupo que mais machucou. Quase todos os casos terminam na mesma frase: rotacione tudo o que estava ao alcance.

LiteLLM. A versão maliciosa 1.107.0 ficou no PyPI por cerca de duas horas (das 11h39 às 13h23 UTC de 21/10), com imagens Docker no ar até cerca das 14h20 UTC. Ela instalava um ladrão de credenciais e um carregador de código remoto em arquivos que rodam sempre que um processo Python inicia, mesmo sem importar o LiteLLM. Quem instalou deve presumir que a exfiltração deu certo e rotacionar tudo o que o host acessava. A versão segura é a 1.106.2, e a LiteLLM atualizou o relato em 23/10 para corrigir premissas anteriores. Circula o número de “23 milhões de downloads por semana”, mas esse é o volume da biblioteca inteira. A Wiz estima cerca de 49 mil downloads da versão maliciosa. É o segundo incidente da LiteLLM no ano.

OVHcloud CLI. Em 19/10, os binários de cinco releases (v0.11.0 a v0.15.0) foram trocados por builds maliciosos, e ficaram no ar por cerca de 94 minutos, com cerca de 250 downloads. O alarme veio de um cliente cujo CI conferia o SHA-256 do arquivo e começou a falhar. A OVHcloud diz que uma conta de desenvolvedor no GitHub foi comprometida e que os releases não eram imutáveis, e rastreia a invasão até uma extensão de navegador maliciosa na máquina pessoal do desenvolvedor, instalada em outubro de 2025. É a versão da própria empresa, e a StepSecurity liga o caso ao malware GlassWorm. A versão limpa é a 0.16.0.

Rank Math PRO. O pacote 3.0.123 circulou com código malicioso entre 20h02 UTC de 15/10 e 7h12 UTC de 16/10. Sites que ativaram o pacote nessa janela devem ser tratados como comprometidos, e a versão limpa é a 3.0.124. A versão gratuita do WordPress.org não foi afetada. Relatos citam como sinais administradores com nome começando por wpsupport_, um arquivo falso class-wp-cache-util.php e tarefas agendadas estranhas.

ConnectWise Cloud Backup (antigo SkyKick). A Microsoft atribuiu a campanha ao Storm-0940, grupo alinhado à China que ela rastreia desde 2021. Ele usou credenciais de quatro aplicativos da ConnectWise para se autenticar em ambientes de clientes, aproveitando a confiança já estabelecida entre os tenants. Houve tentativa de login em mais de 2.250 tenants, e esse número mede alvos, não vítimas: a própria Microsoft diz que a maioria não foi comprometida. A Huntress confirmou acessos indevidos em 162 tenants até 16/10, número que subiu para 173 em relatos posteriores. Um dos aplicativos chegou a atribuir a si mesmo a função de Administrador Global, e credenciais adicionadas a aplicativos podem funcionar como backdoor mesmo depois de o aplicativo original ser desativado. Como a credencial foi obtida, ninguém explicou.

Railway. Em 21/10 a empresa disse que um terceiro pode ter acessado variáveis de ambiente criptografadas e, para algumas, obtido o conteúdo descriptografado. Pausou deploys e pediu que todos os clientes rotacionem todos os segredos. Segundo a cobertura, a Railway relaciona o caso a uma série de ataques contra provedores de inferência de IA.

A semana dos certificados

eMudhra. Oito chaves privadas de autoridades certificadoras intermediárias foram geradas com tão pouca aleatoriedade que puderam ser recalculadas a partir dos certificados públicos, em menos de um segundo no notebook do pesquisador Scott Helme. Segundo o The Register, o valor de uma delas era o número 4, quando uma chave P-384 deveria ser um número aleatório de 384 bits. Outros pesquisadores encontraram valores como 56, 115, 66 e 230.

A Mozilla recebeu o relato em 17/10 e publicou em 20/10. A eMudhra diz que revogou as oito intermediárias em 18/10 e que nenhum certificado final foi emitido com elas, o que é declaração da empresa. Segundo ela, a causa foi uma etapa de uma cerimônia de geração de chaves, em 30/04/2025, que produziu um segundo conjunto de chaves fracas junto com as fortes. A causa raiz ainda não foi confirmada. Não há uso malicioso comprovado, e uma notícia que circulou sobre a empresa deixar o mercado de TLS não aparece na declaração oficial.

O risco que sobra está no software que não atualiza sozinho a lista de certificados confiáveis: clientes de API, containers, pipelines de build e dispositivos embarcados. O Go registrou a CVE-2026-111943 para o caso, e o Firefox, a CVE-2026-113470. A release de 21/10 do Node.js também inclui uma atualização do pacote de certificados raiz ligada à eMudhra.

Node.js e a validação de TLS. A mesma release corrige falhas de nota alta na forma como o Node confere nomes de host, certificados e consultas DNS. Uma delas envolve endereços IP escritos de formas incomuns, como 0127.0.0.1, em que um certificado emitido para um endereço podia ser aceito para outro.

Minha leitura: o caso eMudhra mostra que a segurança de uma cadeia de confiança vale o que vale a geração de uma chave. Vale perguntar o que o seu software confia, onde está a lista de certificados raiz dentro de cada container e de cada pipeline, e quem a atualiza.

Software de base, além do PHP

Node.js (CVE-2026-111497). Uma escrita fora dos limites no decodificador Brotli, que pode causar falha, vazamento de memória ou execução remota de código quando a aplicação descomprime dados Brotli não confiáveis com node:zlib. O aviso do Node.js a classifica como alta, e quem a reportou foi o OpenAI Codex Security, outra falha achada por IA. As correções são as versões 22.23.4, 24.22.1 e 26.12.1. O aviso não menciona as linhas 20 e 25, então confira o cronograma de releases. Uma análise independente lembra que a aplicação pode ser atingida sem chamar o Brotli no próprio código, porque o fetch() do Node e o parser de corpo do Express 5 descomprimem conteúdo br. As fontes não relatam exploração. A mesma release corrige 10 CVEs.

GitLab (CVE-2026-110264). Nota 10,0, o máximo do CVSS. É um integer overflow no compilador de expressões regulares e atinge instalações self-managed desde a versão 7.0, de 2014. As correções saíram em 21/10 em sete linhas, e o GitLab.com já está corrigido. O GitLab diz que a exploração exige condições que não detalhou, e as reportagens não registram ataques nem PoC público. Ela é separada da CVE-2026-97229, também nota 10, de 12/10, então quem atualizou só naquela data ainda está exposto. Não consegui abrir o aviso oficial, então confira nele as versões corrigidas para a sua série.

SonicWall SMA1000 (CVE-2026-102255). Um SSRF sem autenticação, nota 10,0, corrigido em 6/10. Operadores de sensores viram tentativas de exploração a partir de 8/10, enquanto o aviso da SonicWall dizia não ter evidência de exploração na data da publicação.

IA no ataque

A IA apareceu nos três papéis, e é a primeira vez que eu consigo escrever isso com fontes diferentes.

Descobre falhas: PHP2Shell (Calif, Wiz e OpenAI) e o bug do Brotli no Node.js (OpenAI Codex Security).
Opera ataques: o ARTEX, framework open source de pentest com agentes de LLM, foi usado pelo Storm-0940, segundo a Microsoft. Em uma das campanhas houve mais de 200 logins bem-sucedidos em menos de quatro minutos, e o pico foi de cerca de 2.900 falhas de login por minuto em 11/10. O Cairn, plataforma open source de agentes de IA, foi abusado contra sites de e-commerce e pagamento. A NorForge encontrou três grupos de atividade, um deles com mais de 1.100 projetos, e estimou uma taxa de sucesso de cerca de 10%. A Reuters, citada pela SecurityWeek, relata mais de 100 organizações invadidas, entre elas Deere e SharkNinja. A NorForge não nomeou vítimas, então esse número depende da reportagem e não tem verificação independente. Uma fonte cita cerca de US$ 50 por invasão, mas é uma alegação isolada.
É alvo: o LiteLLM é um gateway de IA, e a Railway ligou o seu incidente a ataques contra provedores de inferência. Ambientes de IA concentram chaves de nuvem e de modelos, e atacantes perceberam.

Não confunda isso com “a IA fez tudo sozinha”. Em todos os casos havia um humano escolhendo alvos, e as falhas descobertas ainda dependiam de condições específicas.

Ameaças persistentes e anonimato

SafePay. O alerta conjunto AA26-293A, de 20/10 (CISA, FBI e Serviço Secreto, com Alemanha e Reino Unido), diz que o grupo atingiu pelo menos 600 vítimas desde agosto de 2024. Entra por credenciais expostas, força bruta, VPN e cinco vulnerabilidades já conhecidas, a mais recente de setembro de 2024. Na recuperação, interrompe o serviço de cópias de sombra e reseta NAS de backup para a configuração de fábrica, o que reforça um recado antigo: backup precisa ser offline, imutável e testado.

Lazarus, Operation FlashHole. A Kaspersky descreveu em 21/10 uma campanha contra organizações sul-coreanas, ativa desde julho de 2025, com pelo menos três vítimas. Os atacantes abusaram do CrossWeb EX, um software de segurança financeira, e usaram sites falsos de currículo hospedados no GitHub Pages. Um dos componentes de malware usa criptografia pós-quântica (ML-KEM-1024), e a Kaspersky atribui à Lazarus com confiança média a alta.

Tor. Entre 1º e 5/10, mais de 300 relays de saída foram reconfigurados para redirecionar logins SSH para 12 servidores de interceptação. No pico, em 4/10, eles chegaram a 7,46% da capacidade de saída da rede. Só foram afetados logins por senha, feitos via Tor, por quem aceitou uma chave de host nova. Logins por chave SSH não podiam ser repassados. O Tor Project marcou os relays como inválidos em 4/10, e nenhum permanecia no consenso às 17h UTC de 5/10. Um operador ligou o caso a um servidor de gerenciamento com o backdoor Ebury, instalado a partir de uma senha reutilizada.

O que ficou de fora, e por quê

Algumas listas que circularam misturam fatos com rumor, então deixei estes itens de fora:

Zeabur e TeamUpdraft/UpdraftCentral aparecem só numa lista, sem fonte independente.
Os dados do State Bank of India (3.897 registros de cerca de 375 mil) e da varejista Mr. Max (1,7 milhão de clientes) vêm de um tweet ou de lugar nenhum.
A violação da Universidade Yonsei, em 22/10, não foi ligada ao PHP2Shell por nenhuma fonte, e um analista pede que ela não seja apresentada assim.
A narrativa de “bancos infiltrados” é, nas palavras de um analista, uma alegação em tela, não uma constatação.
Node2Shell e WP2Shell aparecem como nomes na imprensa, mas só o primeiro tem fonte primária, e eu o tratei pelo número da CVE.

O que une tudo isso

Segredos vazaram em quase tudo. LiteLLM, Railway, OVHcloud, Rank Math e ConnectWise terminaram em “rotacione credenciais”. O atacante moderno prefere roubar a chave a arrombar a porta.
A IA descobre, opera e é alvo, e o prazo entre divulgação e tentativa de exploração encolheu para horas.
Ativo sem dono é a porta aberta. Um meme do Daily Dark Web resumiu: alguém pergunta “usamos PHP?”, a resposta é “não”, e no canto está um servidor com PHP 7.4 cujo dono saiu em 2019.
A investigação vem antes do patch. Uma análise da D3 Security, que vende plataforma de SOC, defende que o Black October foi “um problema de investigação antes de ser um problema de patch”. Descontado o interesse comercial, o ponto vale: depois de corrigir, olhe para trás.

Como se proteger

PHP

Descubra onde você tem PHP. Procure em aplicações legadas, sistemas internos, painéis, intranets e hospedagens que ninguém lembra de ter contratado.
Atualize para as versões corrigidas: 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Cuidado com o 8.2, cujo suporte acaba em 31/12/2026.
Séries sem suporte (8.1 e anteriores) não têm release oficial. Use pacotes de distribuição ou de fornecedor LTS com a correção portada, ou os ramos de código que o PHP publicou, ou migre para uma versão suportada. Confirme a correção no changelog do pacote (com zgrep em Debian e Ubuntu, ou rpm -q --changelog em RHEL e derivados).
Confirme a versão que atende a web. O binário de linha de comando pode ser diferente do que roda no servidor.
Reinicie todos os workers depois de atualizar. Sem isso, processos antigos continuam rodando.
Se não puder atualizar agora, o PHP lembra que só a atualização resolve por completo, mas indica mitigações parciais: – desativar session.upload_progress.enabled, no php.ini, no pool do FPM ou na configuração do servidor, e não por ini_set() ou .user.ini; – reduzir o post_max_size (8M sem uploads, 32M com uploads), além de limitar o aninhamento (max_input_nesting_level), as variáveis de entrada, as partes multipart e os uploads; – definir memory_limit=-1 de modo que a aplicação não consiga sobrescrever. Esse ajuste tem custo: uma única requisição pode consumir toda a memória do servidor, então monitore e reverta depois do patch; – no PHP 8.5, fatal_error_backtraces=0; – não usar RLIMIT_AS nem RLIMIT_DATA, que podem provocar a própria falha de alocação, e não confiar em esconder erros, que não ajuda; – bloquear multipart/form-data no servidor ou no WAF, só depois de avaliar o impacto, porque isso quebra uploads.
Procure sinais de ataque desde 17/10. A Wiz lista requisições multipart incomuns seguidas de erros de limite de memória, respostas HTTP 500 repetidas, cookies PHPSESSID grandes ou malformados e troca anormal de workers. A Amazon sugere procurar POSTs com a string PHP_SESSION_UPLOAD_PROGRESS. O watchTowr acrescenta webshells novas, tarefas agendadas inesperadas, contas criadas por processos PHP e conexões de saída que ninguém explica. Preserve logs e configuração antes de mexer em qualquer coisa, e investigue, em vez de bloquear no automático, os IPs que a Amazon publicou, que são de infraestrutura compartilhada.
Rotacione segredos de aplicações com indício de comprometimento. Um dos defeitos vaza memória do processo, e a Sansec lista senhas, tokens de sessão, chaves de API e chaves privadas como conteúdo possível.
Hospedagem gerenciada: pergunte ao provedor qual versão está rodando e se os workers foram reiniciados.
Para a CVE-2026-109619, o aviso do PHP sugere ainda eliminar erros fatais em caminhos que o atacante alcança e, se o desempenho permitir, usar pm.max_requests=1 no FPM, para que cada worker atenda uma única requisição. Se o upload progress não for necessário, vale mantê-lo desativado mesmo depois do patch.
CVE-2026-115560: o PHP diz que só afeta quem define o session.serialize_handler como php_binary ou php_serialize e depois o troca para php em tempo de execução, com o upload progress ligado. O caso é improvável. Desativar o session.upload_progress.enabled cobre os dois problemas.

Janelas de exposição: você estava no caminho?

Incidente	Janela	Quem se preocupar	O que fazer
PHP2Shell	a partir de 17/10 (primeira tentativa registrada)	Quem roda PHP exposto à internet	Atualizar, reiniciar workers e procurar sinais desde 17/10
LiteLLM 1.107.0	21/10, 11h39 a 13h23 UTC (PyPI); Docker até cerca de 14h20 UTC	Quem instalou ou puxou a imagem nesse intervalo	Presumir exfiltração, rotacionar tudo, reconstruir ambientes, fixar a 1.106.2
OVHcloud CLI v0.11.0 a v0.15.0	19/10, 12h47 a 14h21 UTC	Quem baixou nesse intervalo	Tratar o binário como comprometido, usar a v0.16.0, conferir o SHA-256
Rank Math PRO 3.0.123	15/10, 20h02 UTC, a 16/10, 7h12 UTC	Sites que ativaram o pacote	Tratar como comprometido, restaurar backup limpo, usar a 3.0.124
ConnectWise Cloud Backup	atividade confirmada até 16/10; revisar logs desde 15/10 (e 1º/10 se possível)	Clientes Microsoft 365 com os aplicativos conectados	Revisar sign-ins de service principals e mudanças de credenciais, funções e consentimentos
Tor e SSH por senha	1º a 5/10	Quem logou por SSH com senha via Tor aceitando uma chave de host nova	Trocar a senha, verificar o servidor e migrar para chaves SSH
Railway	detectado em 21/10	Clientes da plataforma	Rotacionar todos os segredos e revisar logs

Se você só tiver uma hora

Atualize o PHP e reinicie os workers, ou confirme com o provedor que isso foi feito.
Atualize o Node.js para a versão corrigida da sua linha e o GitLab self-managed para a versão do seu ramo.
Procure LiteLLM 1.107.0, o CLI da OVHcloud v0.11.0 a v0.15.0 e o Rank Math PRO 3.0.123 nos seus ambientes.
Se algum deles apareceu, rotacione credenciais e chaves de API antes de qualquer outra coisa.
Se você usa Microsoft 365 com a ConnectWise, revise as credenciais e os papéis dos aplicativos.
Marque na agenda a revisão da lista de certificados raiz dos seus containers e pipelines.

Glossário de siglas e termos

Sigla ou termo	Significado
RCE	Remote Code Execution, execução remota de código
CVE	Common Vulnerabilities and Exposures
CVSS	Common Vulnerability Scoring System, nota de gravidade de 0 a 10
GHSA	GitHub Security Advisory, aviso de segurança publicado no GitHub
CNA	CVE Numbering Authority, organização que atribui a CVE (aqui, o próprio PHP)
SSVC	Stakeholder-Specific Vulnerability Categorization, método de priorização usado pela CISA
SAPI	Server API, a forma como o PHP é ligado ao servidor web (mod_php, FPM e outras)
OOM	Out Of Memory, falta de memória
Use-after-free	Uso de memória depois de ela ter sido devolvida ao sistema
Worker	Processo do servidor que atende uma requisição depois da outra
FPM	FastCGI Process Manager, gerenciador de processos do PHP
OPcache	Cache de código compilado do PHP
SSRF	Server-Side Request Forgery, quando o servidor é induzido a fazer requisições
Brotli	Algoritmo de compressão usado em conteúdo web
WAF	Web Application Firewall
KEV	Known Exploited Vulnerabilities, catálogo da CISA
CISA	Cybersecurity and Infrastructure Security Agency
NCSC	National Cyber Security Centre
LTS	Long Term Support, suporte de longo prazo
CA	Certificate Authority, autoridade certificadora
TLS	Transport Layer Security
PyPI	Python Package Index, repositório de pacotes Python
CI	Continuous Integration, integração contínua
SSH	Secure Shell
Honeypot	Servidor-isca usado para observar ataques
PoC	Proof of Concept, prova de conceito

Conclusão: o que fazer hoje

Se você só puder guardar uma ideia, guarde esta: o Black October foi menos sobre uma falha e mais sobre o tempo. As falhas eram antigas, os segredos vazaram antes do alerta e as primeiras tentativas de exploração vieram antes do patch. Quem defende precisa olhar para trás tanto quanto para a frente.

Na prática, descubra onde você tem PHP e atualize, procure nos seus ambientes os pacotes e binários comprometidos, rotacione os segredos que estavam ao alcance deles e revise o que o seu software confia em matéria de certificados. O debate sobre exploração em massa vai continuar, mas o seu prazo de correção precisa ser medido em horas.

Se você quer discutir o Black October, trocar achados de logs ou acompanhar como as coisas evoluem, entre no nosso Discord: discord.com/invite/6h6D9W7DFj.