Falha no PHP permite executar comandos no servidor mesmo sem login — e expõe 70% dos sites do mundo

Resumo: duas falhas na própria linguagem PHP (linguagem de script que roda no servidor e sustenta a maior parte da web) permitem que qualquer pessoa, sem nenhum login, execute comandos dentro do servidor — e ainda leia a memória do processo, onde ficam senhas, tokens e chaves de API. Batizadas de PHP2Shell e catalogadas como CVE-2026-109618 e CVE-2026-109619, ambas com 9.2 de 10 na escala CVSS, elas estão presentes em quase toda versão do PHP lançada desde 2012. O detalhe que faz esse caso entrar para a história: o defeito existe desde 2004 e só foi transformado em ataque viável agora, por modelos de IA. Os patches saíram em 21/10 — mas informações vazaram antes, PoCs circulam, sensores de segurança já registram tentativas de exploração e o FBI entrou em campo.

Introdução

O PHP é a linguagem que roda por trás de boa parte de tudo o que você acessa: WordPress, Drupal, Joomla, Magento, a Wikipédia (feita em MediaWiki), fóruns, painéis e sistemas internos de empresas. Estimativas colocam o PHP sustentando entre 70% e 80% dos sites do mundo. É por isso que uma falha dentro da própria linguagem — e não em um plugin, tema ou aplicação — tem um alcance difícil de exagerar.

No dia 21 de outubro de 2026, o time de segurança do PHP liberou patches de emergência para duas vulnerabilidades de execução remota de código (remote code execution, ou RCE — quando o atacante consegue rodar os próprios comandos na máquina alvo). As duas foram apelidadas de PHP2Shell e receberam os identificadores CVE-2026-109618 e CVE-2026-109619, com CVSS v4.0 9.2 cada — praticamente o topo da escala de gravidade.

O que torna a situação incomum não é só a nota. É o combo: não exige autenticação, atinge versões antigas do PHP lá atrás, na 5.4, e dá ao atacante execução de código com os privilégios da conta do servidor web — o usuário sob o qual o site roda. Se esse usuário tiver acesso a arquivos de configuração, credenciais de banco de dados ou chaves de API, o atacante herda tudo isso.

E há um segundo fio igualmente grave: as falhas também permitem ler a memória do processo PHP. Essa memória guarda dados de outras requisições, não só da sua — ou seja, senhas, tokens de sessão, chaves de API e certificados que passaram pelo servidor podem ser despejados para quem sabe explorar. Isso funciona até sem chegar ao RCE.

Nenhuma dessas falhas nasceu de um erro bobo de programação. Elas vêm de decisões de arquitetura tomadas há mais de uma década — e ficaram invisíveis porque explorá-las exigia um encadeamento tão complexo que estava no limite do que um ser humano conseguiria fazer na prática.

Duas falhas, um mesmo defeito de fábrica

O ponto central para entender a PHP2Shell é que não são dois bugs isolados. São quatro problemas de segurança de memória, agrupados em dois CVEs, todos nascidos do mesmo padrão de comportamento do PHP.

Toda requisição que chega a um servidor PHP é atendida por um worker (processo trabalhador — o processo que efetivamente executa o código da requisição). Quando uma requisição termina de forma anormal — por exemplo, quando estoura o limite de memória configurado no servidor e o PHP aborta no meio do caminho — o processo de limpeza interna às vezes não termina. O resultado é que o PHP pode deixar para trás estado corrompido na memória, como um ponteiro que aponta para um pedaço de memória que já foi liberado.

A requisição seguinte, atendida pelo mesmo worker, encontra esse lixo e trata como se fosse dado legítimo. A partir daí, o atacante tem um primitivo de corrupção de memória — o passo que separa "barulho interno" de "execução de código".

A parte mais desconfortável é onde esses bugs moram. Segundo a PHP Foundation (fundação sem fins lucrativos que financia e coordena o desenvolvimento do PHP), as duas falhas ficam em partes do PHP que quase toda requisição toca: o gerenciamento de memória e o tratamento de erros. Isso explica as duas coisas ao mesmo tempo — por que as falhas são tão graves e por que foram tão difíceis de corrigir.

A Wiz (empresa de segurança em nuvem) descreve os quatro problemas assim: uma use-after-free (uso de memória já liberada) no desserializador do progresso de upload; outra no backtrace de erro fatal; uma type confusion (confusão de tipos) no OPcache (cache de código compilado do PHP, compartilhado entre os workers); e uma via de vazamento remoto de memória do processo.

Vale o alerta da própria Wiz: esses quatro são os que foram catalogados. Existem variantes rastreadas e provavelmente não rastreadas do mesmo problema. O patch resolve a raiz e elimina todas as variantes na versão corrigida — mas o tamanho real da família de falhas só será conhecido com o tempo.

A falha que dormiu vinte anos

A linha do tempo desse caso é, sozinha, a melhor explicação de por que ele é diferente.

Vinte e dois anos separam a primeira pista da correção. Nesse intervalo, o bug foi encontrado, esquecido, redescoberto e novamente engavetado — sempre pelo mesmo motivo: ninguém conseguia provar que era explorável.

Como o ataque funciona

O ataque não depende de encontrar um site mal configurado nem um plugin desatualizado. Ele explora o motor do PHP. A cadeia tem uma lógica clara: primeiro o atacante força um erro fatal controlado; depois usa o que sobrou desse erro.

Primeiro, o estouro de memória. Todo servidor PHP tem um teto de memória por requisição (memory_limit) e um teto para o tamanho do corpo de um formulário (post_max_size). O pesquisador da Calif.io descreveu uma forma de furar essa barreira: o PHP compara o post_max_size com o tamanho declarado da requisição antes de começar a processá-la, mas não aplica o mesmo limite aos bytes que realmente consome. Assim, é possível enviar uma requisição do tipo multipart (formato de formulário que também carrega arquivos) sem tamanho declarado relevante, que na prática entrega muito mais pressão de memória do que o configurado.

Somado a isso, uma técnica engenhosa: um campo de upload com nome de arquivo vazio não conta para o limite de arquivos enviados, mas o PHP ainda cria seis registros internos para ele. Se o nome do campo for aninhado — no formato de colchetes encadeados — o PHP precisa construir essa hierarquia para cada um dos seis registros. Algumas centenas desses registros ocupam mais que os 128 MiB padrão de memória do PHP, enquanto o corpo inteiro da requisição continua abaixo dos 8 MiB permitidos. Com isso, o atacante escolhe exatamente quando o limite de memória será atingido.

Depois, os pontos de interrupção. Com o erro fatal sob controle, a pergunta é: o que interromper de modo a deixar o processo num estado explorável? A Calif.io encontrou três caminhos, e a Wiz descreveu outros. No núcleo de todos está o mesmo vício de ordem: o PHP incrementa o contador de elementos de uma estrutura interna antes de terminar de preenchê-la. Se a alocação seguinte falhar no meio, o contador já subiu — e a rotina de limpeza vai percorrer o que ainda não existe, tratando bytes velhos como se fossem dados válidos.

A Wiz detalha ainda os efeitos de cada variante: a do progresso de upload deixa o estado global do desserializador "publicado" após a destruição da memória da requisição, e a requisição seguinte pode consumir memória que o atacante controla; a do backtrace de erro fatal mantém um ponteiro para a requisição anterior, criando uma falha de uso após liberação entre requisições; a do OPcache publica um índice local sem publicar o compartilhado, e outro worker acaba usando aquele espaço com um objeto de tipo errado, corrompendo estado compartilhado entre processos.

Por fim, o vazamento de memória. Existe uma variante que não precisa de RCE para causar dano: o PHP pode manter um ponteiro para dados de sessão já liberados e, numa requisição posterior, usar esse ponteiro para codificar o conteúdo da memória do worker dentro de um cookie de sessão devolvido ao atacante. O mais preocupante é que essa via funciona mesmo quando a aplicação nunca chama a função de início de sessão — ela é independente da aplicação que roda em cima. Na prática, é um canal para extrair memória de outras requisições.

Um detalhe que muda a urgência por tipo de servidor: o PHP afirmou que o risco é maior no mod_php, a forma de rodar PHP como módulo do Apache. Nesse cenário, existe exploit demonstrado em que uma requisição não autenticada dispara o ataque antes de qualquer linha de código da aplicação ser executada. Ou seja: não há plugin, firewall de aplicação ou validação de entrada do seu código que possa interceptar.

O que um atacante consegue fazer

Confirmar a exploração não é teoria. A Wiz juntou as falhas em um único script e demonstrou execução de código sem autenticação nas imagens de container mais recentes das principais plataformas do ecossistema. A Calif.io publicou uma lista ainda maior de confirmações.

É importante ler essa tabela com cuidado: a lista não é o limite do problema. Ela reúne os alvos que os pesquisadores escolheram para demonstrar o impacto. Como a falha está no motor do PHP, até um "Olá, mundo" rodando numa versão vulnerável é explorável. Não há dependência de erro no código da aplicação.

E o dano não para na execução de comandos. Com privilégios da conta do worker web, o atacante consegue ler arquivos de configuração, alcançar credenciais de banco, alterar páginas, gravar arquivos permanentes e usar o servidor como ponto de partida para a rede interna. Com o vazamento de memória, ele extrai segredos que pertencem a outros usuários e sistemas — inclusive chaves de API e certificados. Vale notar que esse caminho de vazamento puro pode ser mais difícil de detectar, porque não depende de executar código malicioso no servidor.

Segundo Shahak Shalev, da Malwarebytes, o valor estratégico é justamente poder sequestrar sites reais e usar a reputação deles: hospedar golpes, distribuir arquivos maliciosos por um canal confiável, redirecionar visitantes. A frase dele resume bem: "as oportunidades são infinitas".

A falha em ação: as demonstrações em vídeo

A divulgação coordenada ganhou um site oficial próprio — o php2shell.com — mantido em conjunto por Wiz Research, OpenAI e Calif, com orientação de correção, tabela de versões e as gravações das demonstrações. O endereço circulou rápido: o pesquisador argentino Cristian Borghello, do blog Segu-Info, resumiu o clima ao notar que a falha já tinha "site oficial e videítos" poucas horas depois da liberação dos patches.

Nos três vídeos abaixo, o exploit identifica sozinho qual aplicação está rodando e demonstra execução de comandos antes de qualquer autenticação, em ambientes de teste controlados pelos próprios pesquisadores.

PHP2Shell contra o WordPress. O alvo mais popular da web é comprometido sem credenciais:

PHP2Shell contra o Drupal. A mesma cadeia, adaptada a outro CMS:

PHP2Shell contra o Joomla. Terceiro alvo confirmado na demonstração oficial:

O laboratório Calif.io publicou gravações adicionais no YouTube, incluindo uma em que a falha é explorada contra WordPress e phpMyAdmin rodando sobre nginx — cenário diferente do Apache usado nas demonstrações oficiais. Os vídeos estão nas fontes ao final desta matéria.

Exploração já começou — e o patch vazou antes da hora

A divulgação estava agendada para 22 de outubro, às 11h no horário do leste dos Estados Unidos. Não chegou lá.

Um post num fórum público de tecnologia já listava os dois identificadores de CVE com os detalhes, e um vídeo demonstrado a exploração foi publicado antes da hora por engano. Os pesquisadores da watchTowr (empresa de gestão de superfície de ataque) confirmaram publicamente que as falhas eram reais e disseram ter reproduzido a primeira delas — mas se recusaram a soltar informação técnica antes do patch.

Do outro lado, um detalhe que a PHP Foundation classificou como quebra da divulgação coordenada: uma empresa publicou imagens de container já com a correção seis horas antes da liberação oficial. Como o patch ficou disponível em forma binária enquanto todo mundo ainda esperava, qualquer atacante pôde estudar a correção e trabalhar de trás para frente. A Cloudflare, por sua vez, ativou as regras de proteção nove horas antes da divulgação pública.

Com o patch liberado às 14h UTC de 21/10, o que os sensores viram:

Tentativas de exploração em massa. A Hadrian relatou ter observado a falha sendo explorada "em escala" antes mesmo do patch, com a maioria dos ataques usando a via do progresso de upload de sessão. A Patchstack, a Cloudflare e a Vega também registraram tentativas no mesmo dia; a Vega mencionou ataques usando um exploit público. A watchTowr registrou as primeiras tentativas nos sensores no momento em que os patches saíram, sem sucesso confirmado até então — e avisou que isso não deve durar. "Ninguém conseguiu até agora, mas não esperamos que isso dure muito", disse Jake Knott, chefe de inteligência de ameaças da empresa.

Alerta de governo. O NCSC (National Cyber Security Centre, órgão de segurança cibernética do Reino Unido) emitiu aviso para organizações britânicas atualizarem imediatamente os sistemas que usam PHP — ou tirá-los do ar até conseguirem aplicar a correção.

A repercussão: o FBI, a OpenAI e o ecossistema em alerta

O peso institucional da resposta é o melhor termômetro de que este não é um CVE comum. Em poucas horas, agência de governo, laboratório de IA, imprensa mainstream e comunidade de desenvolvedores reagiram ao mesmo tempo — e nem tudo o que circulou no dia era sobre a PHP2Shell.

O FBI entrou em campo. A Divisão Cibernética do FBI publicou orientação direta para organizações, num post que passou de 19 mil curtidas — sinal de que a mensagem chegou muito além do público técnico. As recomendações são específicas e valem como resumo prático: se a atualização imediata não for viável, a orientação é tirar o sistema do ar até conseguir mitigá-lo por completo; inventariar onde o PHP roda no ambiente, priorizando sistemas expostos à internet e produtos de fornecedores que embutem PHP; monitorar os servidores web em busca de atividade suspeita, incluindo "processos PHP iniciando shells de comando ou baixando arquivos de forma inesperada"; e, em caso de sinais de comprometimento, isolar os sistemas, preservar os logs do servidor web e do PHP e reportar ao escritório local do FBI. A agência também aponta o CERT-EU Security Advisory 2026-018 e o catálogo de vulnerabilidades exploradas da CISA como fontes de acompanhamento — embora, até o fechamento desta matéria, os dois CVEs da PHP2Shell ainda não apareçam na lista KEV da agência americana.

A OpenAI publicou o outro lado da história. A empresa revelou que Calif identificou a falha usando o modelo GPT-5.6 Sol, dentro da iniciativa Patch the Planet (programa da OpenAI para apoiar projetos de código aberto na busca de falhas), e que a própria OpenAI liderou por dois meses uma coalizão de mantenedores, pesquisadores e fornecedores de segurança. O texto explica por que o prazo foi longo: "a correção era bastante intrincada e exigia uma mudança importante no motor do PHP". A OpenAI classifica o caso como "um dos problemas de segurança de maior impacto dos últimos tempos" e afirma que, até onde sabe, a IA de fronteira encontrou a vulnerabilidade antes dos atacantes — o que a empresa chama de "Janela do Defensor". Como contrapartida prática, publicou um verificador de versões do PHP distribuído como skill do Codex, e anunciou US$ 1 bilhão em acesso subsidiado à plataforma Daybreak para organizações com poucos recursos de segurança que protegem serviços essenciais. A coordenação envolveu também o governo americano — a Força de Superinteligência da Casa Branca, o ONCD e a CISA — e parceiros internacionais.

O laboratório que descobriu tudo. A Calif.io publicou o relatório técnico completo, com a história de vinte anos do bug e a decisão de apressar a divulgação depois do vazamento. O material ganhou cobertura do Wall Street Journal e do New York Times — algo raro para uma vulnerabilidade de linguagem e um sinal claro da dimensão do caso.

A imprensa especializada fez o resumo operacional. O The Hacker News publicou uma thread com os pontos que mais importam para quem administra servidor: a falha está no runtime, não no código da aplicação; o mod_php tem caminho de RCE não autenticado em uma única requisição; e — o alerta mais repetido do dia — atualizar o WordPress ou o Laravel sozinho não corrige nada, porque o runtime do PHP continua embaixo. A thread também reforça o limite das mitigações: desligar o progresso de upload bloqueia alguns caminhos da CVE-2026-109619, mas não protege contra a CVE-2026-109618 nem elimina a falha.

Um alerta paralelo no mesmo dia — que não é PHP2Shell. Ainda em 21/10, a plataforma de deploy Railway avisou que detectou "atividade anômala em sistemas que armazenam variáveis de ambiente de clientes" e que um terceiro não autorizado pode ter acessado variáveis de ambiente criptografadas e, em alguns casos, obtido o conteúdo descriptografado — justamente onde costumam ficar chaves de API, credenciais de banco de dados e de registries. A empresa pausou todos os deploys e recomendou que todos os usuários rotacionassem suas variáveis de ambiente por precaução. A Railway declarou acreditar que o caso faz parte de "uma série de ataques recentes contra empresas de plataforma com o objetivo de comprometer provedores de inferência de IA" — o que aponta para a onda de comprometimento do pacote LiteLLM no PyPI, um incidente distinto da PHP2Shell. A confusão entre os dois foi comum ao longo do dia, e vale registrar com clareza: são dois problemas diferentes, com o mesmo alvo — os segredos dos desenvolvedores. Nos comentários do aviso, um desenvolvedor resumiu o clima do ecossistema: "eles não vão parar. Vai ficar cada vez mais sofisticado, e vão atrás de toda superfície do seu sistema e de todos os seus funcionários. Qualquer projeto antigo que você esqueceu há muito tempo vai ser encontrado e usado contra você."

A IA transformou um bug antigo em ataque viável

Este é o ponto que faz da PHP2Shell um caso de referência, e não apenas mais um CVE crítico.

O código vulnerável estava lá há mais de uma década. O que faltava não era o bug — era alguém capaz de provar que dava para explorá-lo. Montar a cadeia exigia combinar várias falhas e se adaptar ao layout de memória de cada alvo, testando e depurando repetidamente, porque diferenças de versão, configuração e comportamento da aplicação quebram as premissas do exploit. Um ataque que funcionava contra um servidor precisava de ajustes substanciais para funcionar contra outro.

Antes da IA, esse trabalho era difícil de fazer e muito mais difícil de escalar. Com modelos de fronteira, deixou de ser barreira: os modelos ajudam a adaptar o exploit para diferentes versões, configurações e layouts de memória, analisam as falhas de execução e iteram nos ajustes.

A Wiz usou três modelos nessa pesquisa — a plataforma Wiz Atlas e os modelos Gemini 4 Argon e GPT-5.6 Sol — e credita ao Gemini 4 Argon uma contribuição decisiva tanto na descoberta quanto na validação do patch. O resumo da própria empresa é o mais eloquente: "com modelos de fronteira e as ferramentas certas, um único pesquisador completou em uma semana o que antes exigiria meses de uma equipe de classe mundial".

Vale registrar o contraponto, que é honesto. O pesquisador da Calif.io deixou claro que nenhum modelo encontra "todos os bugs" com um pedido simples e que conhecer o histórico de vulnerabilidades do alvo continua sendo essencial — foi justamente esse conhecimento que direcionou a busca. A própria OpenAI faz a ressalva gêmea: as mesmas capacidades que ajudam defensores também ajudam atacantes a desenvolver ferramentas ofensivas rapidamente. A diferença, neste caso, foi de tempo.

O efeito colateral já é visível: segundo a PHP Foundation, 15 novos CVEs foram publicados no PHP desde 1º de julho — reflexo direto de auditorias assistidas por IA. E não é só PHP: a mesma semana trouxe uma correção de 353 falhas no Chrome, com a maioria sendo exatamente da mesma família de bugs de memória.

A comparação que a Wiz propõe é ambiciosa, mas não gratuita: em 2014, o Heartbleed mostrou a fragilidade da infraestrutura compartilhada que protege a internet; em 2021, o Log4Shell mostrou o quanto uma dependência profundamente embutida cria exposição generalizada. A PHP2Shell seria o marco equivalente da era da IA — o momento em que complexidade deixou de ser uma barreira prática.

Como se proteger

A primeira e mais importante orientação é direta: atualize o PHP. A correção está disponível nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O time do PHP também publicou backports mínimos para as versões 7.4, 8.0 e 8.1, destinados a quem compila o PHP a partir do código-fonte ou não tem acesso a um fornecedor que mantenha versões antigas. O PHP 8.1 e anteriores já não recebem atualizações do projeto — se for o seu caso, o caminho é cobrar o fornecedor da sua distribuição ou migrar para uma versão suportada.

A correspondência entre a versão vulnerável e a corrigida, por ramo, é esta:

Reiniciar também é parte da correção. Atualizar o pacote não basta: é obrigatório reiniciar o Apache, o PHP-FPM e qualquer worker PHP de longa duração, porque estado corrompido pode continuar vivo em processos que já estavam rodando. E, como a internet já viu circulando um verificador de versões publicado pela OpenAI como skill do Codex, vale a pena inventariar onde o PHP roda antes de sair atualizando: ele costuma aparecer em lugares esquecidos — painéis antigos, sistemas internos, ferramentas de administração de banco de dados e produtos de terceiros que embutem o runtime.

Se você não consegue atualizar imediatamente. A documentação oficial publicou um conjunto de medidas que reduzem a exposição a alguns caminhos de ataque, mas não tornam a instalação segura. A mensagem precisa ser lida na íntegra: são paliativos, não defesas. A desenvolvedora do núcleo do PHP Gina Peter Banyard declarou publicamente que nenhuma mitigação bloqueia de verdade e que aplicar o patch oficial é a única solução permanente.

Para a falha de estouro de memória, a orientação é remover o teto que o atacante usa como gatilho e reduzir a pressão disponível na entrada. Isso significa definir memory_limit como -1, de preferência de um jeito que a aplicação não consiga sobrescrever — usando as diretivas de configuração do pool do PHP-FPM ou do Apache. Isso, porém, remove o limite de memória do PHP e transfere o problema para o sistema operacional: a proteção deixa de ser o PHP e passa a ser o limite do container ou do cgroup v2, com uma política que mate apenas o worker afetado em vez do servidor inteiro. Uma ressalva técnica importante: não use RLIMIT_AS ou RLIMIT_DATA como substitutos — o próprio aviso do PHP alerta que esses limites podem disparar os mesmos caminhos vulneráveis. Em paralelo, reduza o post_max_size para um valor compatível com seus uploads e o max_input_nesting_level para a profundidade que suas aplicações realmente precisam.

Para a falha de estado global obsoleto, o caminho é desligar as funcionalidades que servem de gatilho e reiniciar todos os workers. Em configuração:

; desativa o progresso de upload de sessão (gatilho conhecido)
session.upload_progress.enabled = 0
 
; apenas PHP 8.5: bloqueia o caminho confirmado do backtrace de erro fatal
fatal_error_backtraces = 0
 
; evita expor saída de erro do PHP a usuários remotos
display_errors = 0

A PHP Foundation acrescenta dois pontos que costumam ser ignorados: remova configurações inválidas ou obsoletas aplicadas por requisição, que emitem diagnósticos antes da inicialização — esconder essas mensagens com configuração de erro não resolve — e corrija os erros fatais e estouros de tempo de execução que um atacante consegue alcançar, incluindo falhas em callbacks, uploads, importações e rotinas de limpeza. Duas medidas adicionais entram como redução de dano: baixar o pm.max_requests do PHP-FPM para reciclar workers com mais frequência (com custo de desempenho) e usar políticas de SELinux ou AppArmor para restringir o que a conta do worker pode executar.

Filtros e firewalls de aplicação. A Cloudflare liberou regras de WAF (Web Application Firewall, filtro que inspeciona o tráfego antes de chegar ao servidor) que bloqueiam métodos de exploração conhecidos, disponíveis inclusive no plano gratuito. A Fastly, a Google Cloud e a Vercel publicaram proteções equivalentes. Trate tudo isso como paliativo temporário, não substituto do patch — e lembre-se de que no cenário mod_php o ataque dispara antes do código da aplicação, o que limita bastante o alcance de defesas na camada de aplicação.

Como saber se você já foi comprometido. Como as falhas rodam abaixo da camada da aplicação, os logs do site tendem a ter pouco contexto. Os sinais a procurar são combinações incomuns: requisições multipart fora do padrão seguidas de erros de limite de memória, respostas HTTP 500 repetidas, cookies de sessão anormalmente grandes ou malformados nas respostas e rotatividade inexplicada de processos workers. Em nível de sistema, vale investigar execuções de shells como sh, bash, cmd ou PowerShell a partir do processo do servidor web, chamadas a interpretadores como Python ou Perl, uso de utilitários de download como curl, wget ou nc, padrões de conexão reversa e comandos rápidos de reconhecimento como whoami, id ou uname. O FBI reforça exatamente esses mesmos indicadores e acrescenta o passo mais importante quando há suspeita: isolamento e preservação de evidências antes de qualquer limpeza. Qualquer um desses sinais, isolado, não prova ataque — mas a combinação justifica investigação imediata.

Depois de corrigir, revise a configuração. A própria correção do PHP introduz um limite rígido de memória: ao ser atingido, o processo é encerrado e os manipuladores de desligamento não rodam. Isso é intencional, mas tem efeito operacional — vale revisar o memory_limit junto com os limites de tamanho de requisição e o consumo real da aplicação, e desfazer qualquer memory_limit = -1 usado como paliativo temporário. Manter o post_max_size abaixo do orçamento de memória e considerar expose_php = 0 para esconder a versão do PHP completam o endurecimento.

Conclusão

A PHP2Shell é o tipo de vulnerabilidade que reorganiza prioridades. Não porque seja inédita em gravidade, mas porque derruba uma premissa confortável: a de que um código antigo e muito auditado já teria sido limpo. O problema estava lá desde 2004, passou por pelo menos três oportunidades claras de correção e só virou arma quando a barreira técnica deixou de ser humana.

Três lições ficam desse caso. A primeira é sobre onde o risco mora: quando a falha está na linguagem e não na aplicação, nenhuma boa prática de desenvolvimento sobre o seu código protege — a superfície é todo sistema que roda PHP, incluindo os esquecidos. A segunda é sobre o novo custo da complexidade: durante anos, "difícil de explorar" funcionou como defesa informal. Com modelos de fronteira adaptando exploits a diferentes versões e layouts de memória em horas, essa defesa perdeu valor prático. A terceira é sobre divulgação coordenada: o vazamento de um dia, o vídeo publicado por engano e as imagens de container liberadas seis horas antes mostram que o segredo, quando vaza, transforma um patch planejado em corrida.

Para quem administra sistemas, a ação não é ambígua: encontre todo PHP da sua infraestrutura, atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e reinicie os workers. Paliativos ajudam a ganhar tempo, nunca a dormir tranquilo. E, como o patch já vazou em forma binária, PoCs circulam e o FBI foi a público pedir correção imediata ou desligamento, o tempo é curto.

Perguntas frequentes

Fontes e leituras adicionais

• BleepingComputer — PHP ships emergency patches for critical PHP2Shell flaws — 21/10/2026
• BleepingComputer — PHP warns admins of two critical flaws, emergency patches coming tomorrow — 20/10/2026
• SecurityWeek — PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors — 21/10/2026
• Wiz — PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet — 21/10/2026
• PHP2Shell (site oficial) — Orientações de correção, tabela de versões e vídeos das demonstrações — 21/10/2026
• Calif.io — php2shell: A tale of two PHP remote vulnerabilities — 21/10/2026
• Calif.io (YouTube) — php2shell contra WordPress e phpMyAdmin em nginx — 21/10/2026
• The Hacker News — PHP2Shell: Two Unpatched Critical PHP RCE Flaws (CVSS 9.2) Trigger Emergency Security Alert — 21/10/2026
• OpenAI — Patch the Planet: global response coordination as agents uncover critical vulnerabilities — 21/10/2026
• FBI Cyber Division (X) — Alerta sobre as duas vulnerabilidades críticas no PHP — 21/10/2026
• PHP — PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released (security release) — 21/10/2026
• PHP Foundation — Today's PHP security release and how we're strengthening PHP security — 21/10/2026
• NCSC (Reino Unido) — Critical security issue affecting PHP — 20/10/2026
• VirusTotal — Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619 — 21/10/2026
• watchTowr — PHP Remote Code Execution ("PHP2Shell" CVE-2026-109618 and CVE-2026-109619) — 20/10/2026
• Railway — Security Disclosure: Wednesday October 21st — 21/10/2026
• Trend Micro — Your AI Gateway Was a Backdoor: Inside the LiteLLM Supply Chain Compromise — 21/10/2026