Se você tem um site, uma loja virtual ou qualquer sistema rodando na internet, existe uma boa chance de o PHP estar trabalhando nos bastidores. E, nesta semana, esse motor tão popular virou assunto urgente em todo o mundo da segurança digital.
Duas falhas críticas, apelidadas de PHP2Shell, foram reveladas depois de um vazamento antes da data planejada. A equipe do PHP correu para lançar as correções de emergência, e agora a bola está com quem administra os servidores.
Neste guia, eu explico o que aconteceu em linguagem simples, quais versões já estão protegidas, como atualizar com segurança e o que fazer se você não puder mexer no servidor hoje. Pegue um café, porque vale a leitura completa.
O que é o PHP2Shell?
PHP2Shell é o nome informal que pesquisadores de segurança deram a um par de vulnerabilidades graves encontradas no PHP. O nome é uma pista do tamanho do problema: a ideia é que um atacante consiga sair de uma simples requisição web e chegar a um acesso de comando (um shell, ou terminal) dentro do seu servidor.
As duas falhas recebem os identificadores CVE-2026-109618 e CVE-2026-109619. CVE é a sigla em inglês para Vulnerabilidades e Exposições Comuns, um catálogo público que dá um número único a cada falha de segurança conhecida. Assim, todo mundo, de fabricantes a administradores, fala da mesma coisa usando o mesmo código.
O que é o PHP, afinal?
O PHP (Hypertext Preprocessor, ou Pré-processador de Hipertexto) é uma linguagem de programação de código aberto que roda no lado do servidor. Isso significa que ele executa o trabalho pesado antes de a página chegar ao navegador de quem está visitando o site.
Segundo o material divulgado pelo BleepingComputer, o PHP alimenta algo entre 75% e 80% dos sites da web. Ele está por trás de gerenciadores de conteúdo como WordPress, Joomla e Drupal, de plataformas de comércio eletrônico e de uma infinidade de sistemas feitos sob medida.
Por isso, quando uma falha crítica aparece no PHP, o impacto não fica restrito a uma empresa ou a um nicho. É como descobrir um defeito de fábrica em uma peça usada por boa parte dos carros do planeta.
O que significa execução remota de código?
Execução remota de código, conhecida pela sigla RCE (do inglês remote code execution), é o tipo de vulnerabilidade que todo especialista em segurança teme. Ela permite que alguém, de qualquer lugar do mundo, faça o servidor rodar comandos escolhidos por essa pessoa.
Na prática, o atacante pode roubar dados, instalar programas maliciosos, alterar páginas do site ou usar seu servidor como ponta de lança para atacar terceiros. E, no caso do PHP2Shell, as duas falhas são do tipo não autenticado: ninguém precisa de login ou senha para tentar explorá-las.
Como tudo aconteceu: da data de divulgação ao vazamento
A história tem um enredo digno de série de suspense. A equipe do PHP havia planejado divulgar as falhas de forma coordenada, num processo em que os detalhes ficam em segredo por um tempo (o chamado embargo) para que fornecedores e administradores se preparem antes de o público saber.
Só que o segredo escapou.
O aviso do dia 20 de outubro
Na terça-feira, 20 de outubro de 2026, a equipe de desenvolvimento do PHP publicou um comunicado dizendo que lançaria atualizações de segurança na quarta-feira, 21 de outubro, às 14h UTC. Para quem está no horário de Brasília, isso equivale às 11h da manhã.
O alerta também foi enviado para a lista de e-mails de anúncios do projeto, recomendando que os administradores se preparassem para instalar as correções assim que elas saíssem. A equipe deixou claro que se reservava o direito de antecipar a divulgação caso os detalhes se tornassem públicos ou surgissem sinais de exploração ativa.
O vazamento e a confirmação dos pesquisadores
Pouco depois, a empresa de segurança watchTowr informou que as duas falhas haviam vazado. De acordo com o BleepingComputer, uma publicação já apagada no fórum Hacker News, da incubadora Y Combinator, afirmava que duas falhas críticas de execução remota de código no PHP seriam reveladas em 22 de outubro.
Benjamin Harris, CEO da watchTowr, resumiu a situação ao veículo:
“Na última hora, duas vulnerabilidades de execução remota de código em PHP foram vazadas. Essas vulnerabilidades estavam previamente sob embargo e deveriam ser divulgadas na quinta-feira.”
A empresa afirmou ainda que conseguiu reproduzir a CVE-2026-109618 e que não divulgaria detalhes técnicos até a chegada das correções. Os pesquisadores também esclareceram que, naquele momento, não haviam observado exploração das falhas em situações reais.
Uma pequena divergência de números
Vale reparar em um detalhe que gera confusão. A watchTowr e a publicação do Hacker News falaram em pontuação máxima de gravidade, 10.0, enquanto a equipe de segurança do PHP atribuiu 9.2 a cada falha no sistema CVSS v4.0.
O CVSS (Sistema Comum de Pontuação de Vulnerabilidades) é uma régua de 0 a 10 usada para medir a gravidade de uma falha. Uma nota de 9.2 já é considerada crítica. Em outras palavras, a diferença entre 9.2 e 10.0 não muda a conclusão: é urgente atualizar. O que importa é o recado de fundo, e ele é o mesmo para todo mundo.
A resposta rápida: correções lançadas em 21 de outubro
A equipe do PHP lançou as atualizações de emergência na quarta-feira, 21 de outubro de 2026. As falhas foram descobertas por pesquisadores da Calif. University, da OpenAI e da Wiz, e afetam as instalações do PHP que atendem requisições web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed.
Se esses nomes parecem uma sopa de letrinhas, calma. Mais adiante eu explico o que cada um faz.
Entendendo as duas vulnerabilidades
Segundo a equipe de segurança do PHP, as duas falhas nascem do mesmo problema de base: o PHP pode deixar sua memória em um estado corrompido quando uma requisição termina de maneira anormal. Imagine uma cozinha em que o cozinheiro sai correndo no meio do preparo e deixa panelas fora do lugar. O próximo pedido pode dar errado, ou ser sabotado por alguém que sabe onde estão as panelas.
CVE-2026-109618: corrupção de memória em cadeia
Essa falha pode ser usada para obter execução remota de código com a conta do processo de trabalho, ou seja, a conta que o servidor web usa para rodar as aplicações PHP. O ataque explora uma série de fragilidades que, juntas, provocam corrupção de memória.
Corrupção de memória acontece quando um programa escreve ou lê dados em lugares onde não deveria. É uma das famílias de erro mais perigosas da computação, porque permite que um invasor mude o comportamento do programa.
CVE-2026-109619: estado global obsoleto
A segunda falha envolve o que os especialistas chamam de estado global obsoleto, ou seja, informações que o PHP deveria ter limpado ao fim de uma requisição, mas que continuam ali, desatualizadas. Isso abre caminho para um problema conhecido como uso após liberação (no inglês, use-after-free).
Funciona assim: o programa libera um pedaço da memória, dizendo que não precisa mais dele, mas continua usando aquele endereço por engano. Se um atacante conseguir colocar dados maliciosos naquele espaço, ele toma o controle do que acontece em seguida.
Segundo a equipe do PHP, essa falha permite uso após liberação sem autenticação, divulgação de memória (vazamento de informações que deveriam ficar guardadas) e execução remota de código com os privilégios do processo de trabalho.
Qual das duas é mais perigosa?
A equipe de segurança do PHP afirmou que considera o risco maior para o mod_php, com uma vulnerabilidade comprovada em que uma requisição sem autenticação pode desencadear o ataque antes mesmo de qualquer código da aplicação ser executado.
Isso importa porque tira a proteção do seu próprio código. Mesmo que sua aplicação seja bem escrita, o ataque pode acontecer antes de ela entrar em cena. Não adianta apenas revisar o seu sistema: é preciso atualizar o próprio PHP.
Quem corre risco com o PHP2Shell
A resposta curta é: quase qualquer pessoa que tenha um site ou sistema rodando em PHP e exposto à internet. Mas vale detalhar, porque muita gente acha que isso é problema só de empresa grande.
O tamanho da exposição na internet
Uma estimativa do VirusTotal, citada pelo BleepingComputer, indica que mais de 5,1 milhões de servidores PHP estão expostos online. Desses, cerca de 3,8 milhões têm pelo menos uma porta aberta.
Uma porta aberta é como uma porta de entrada de um prédio: é por ela que os serviços conversam com o mundo externo. Quanto mais portas abertas, mais oportunidades para quem está procurando uma brecha.
Quais versões do PHP estão envolvidas
Os pesquisadores da watchTowr disseram acreditar que as falhas afetam as versões 5, 6, 7 e 8 do PHP. Isso é um ponto assustador, porque muita gente ainda roda versões antigas por medo de quebrar o site ao atualizar.
E aqui entra um aviso importante. A equipe do PHP lembra que as versões 8.1 e anteriores já não recebem atualizações do projeto oficial. Em alguns casos, distribuições do sistema operacional e fornecedores de suporte de longo prazo oferecem correções adaptadas para essas versões, então vale consultar o seu fornecedor.
Onde seu site pode estar usando PHP sem você saber
Muita gente não escolhe o PHP de propósito. Ele vem embutido na ferramenta que a pessoa usa. Um blog em WordPress, uma loja em WooCommerce, um portal em Joomla ou Drupal, um sistema de gestão contratado de uma agência: tudo isso costuma depender dele.
Se você contratou hospedagem compartilhada, é provável que a empresa de hospedagem cuide da atualização do servidor. Mesmo assim, não custa nada perguntar. Um e-mail curto para o suporte, perguntando se o ambiente já recebeu as correções da CVE-2026-109618 e da CVE-2026-109619, pode poupar muita dor de cabeça.
Como atualizar o PHP com segurança, passo a passo
A recomendação unânime dos especialistas é simples: instale as versões corrigidas o mais rápido possível. Segundo a equipe do PHP, as versões que trazem a solução para quem usa a família 8.x são estas:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Quem roda o PHP 7 ou uma versão anterior deve migrar para uma versão corrigida. E, para quem compila o PHP a partir do código-fonte ou não tem acesso a um fornecedor de suporte de longo prazo, a equipe de segurança disponibilizou versões mínimas de código para o PHP 7.4, o PHP 8.0 e o PHP 8.1, com as correções aplicadas.
Passo 1: descubra qual versão você usa hoje
Em um servidor onde você tem acesso por terminal, o comando php -v mostra a versão instalada. Em painéis de hospedagem, a informação costuma aparecer na área de configuração do PHP ou nas ferramentas de diagnóstico do site.
Atenção a um detalhe: o PHP que roda no terminal pode ser diferente do PHP que atende o site. Se houver dúvida, crie uma página temporária que mostre as informações do PHP em uso pelo servidor web, consulte o dado e apague a página logo em seguida, porque ela revela detalhes sensíveis.
Passo 2: faça um backup antes de mexer
Toda atualização grande merece uma rede de segurança. Faça uma cópia dos arquivos do site e do banco de dados antes de começar. Se algo der errado, você volta ao ponto anterior em poucos minutos.
Passo 3: atualize pelo gerenciador de pacotes ou pelo painel
Em servidores Linux, a atualização normalmente é feita pelo gerenciador de pacotes da distribuição. Em hospedagens com painel, geralmente basta escolher a versão do PHP em um menu. Qualquer que seja o caminho, o objetivo é chegar a uma das versões corrigidas citadas acima.
Se você usa servidores gerenciados por uma empresa, peça confirmação por escrito de que a atualização foi aplicada. Parece burocrático, mas é a melhor forma de garantir que ninguém ficou achando que outra pessoa já tinha resolvido.
Passo 4: reinicie os serviços e teste o site
Depois de atualizar, reinicie o PHP-FPM, o Apache ou o servidor web que você usa, para que a nova versão passe a valer de fato. Em seguida, navegue pelo site, teste formulários, envie um arquivo de teste e simule uma compra, se for uma loja.
Se algum plugin ou sistema antigo apresentar erro, não volte para a versão vulnerável como solução permanente. Procure uma versão atualizada do plugin ou fale com o desenvolvedor responsável. Deixar a porta aberta por conta de um plugin velho é um preço alto demais.
E se eu não conseguir atualizar agora? Medidas temporárias de mitigação
A vida real tem prazos, sistemas legados e equipes pequenas. Se você não pode atualizar hoje, existem medidas para reduzir a exposição. Mas ouça o aviso que veio de dentro da comunidade do PHP, porque ele é o mais importante deste artigo.
Gina Peter Banyard, desenvolvedora do núcleo do PHP, alertou que nenhuma mitigação bloquearia completamente os ataques possíveis e que aplicar as correções oficiais é a única defesa permanente. Trate tudo o que vem a seguir como um curativo, não como cura.
Medidas para a CVE-2026-109618
A equipe de segurança do PHP compartilhou as seguintes orientações, que reduzem algumas vias de ataque, mas não oferecem proteção total:
- Defina memory_limit como -1, de preferência de uma forma que as aplicações não consigam sobrescrever, como com a diretiva php_admin_value no pool do PHP-FPM ou na configuração do Apache.
- Use um valor baixo para post_max_size: 8 MB para aplicações que não precisam de envio de arquivos e 32 MB para as que precisam.
- Aplique um limite de contêiner ou cgroup como limite de disponibilidade, de preferência com uma política que encerre apenas o processo de trabalho afetado.
O cgroup é um recurso do Linux que limita quanto de memória e de processamento um grupo de processos pode usar. Ele funciona como um disjuntor: se algo sair do controle, só aquele pedaço é desligado, e o resto continua funcionando.
Medidas para a CVE-2026-109619
Para a segunda falha, as recomendações são estas:
- Configure session.upload_progress.enabled como 0 e reinicie todos os processos de trabalho.
- No PHP 8.5, configure fatal_error_backtraces como 0 e reinicie os processos. Isso bloqueia apenas o caminho confirmado de rastreamento de pilha em erros fatais.
- Remova configurações inválidas ou obsoletas aplicadas por requisição que emitem avisos antes da inicialização.
- Corrija erros fatais e estouros de tempo de execução que possam ser provocados por um atacante, incluindo falhas em retornos de chamada, processamento de envio ou importação de arquivos e rotinas de limpeza.
Um ponto sutil: esconder as mensagens de erro, usando configurações como display_errors ou error_reporting, não resolve o problema. Fechar a cortina não conserta o vidro quebrado. É preciso eliminar a causa dos avisos.
Sobre a dica de bloquear envios multipart
Nos primeiros relatos, circulou a sugestão de bloquear requisições HTTP que usam o tipo de conteúdo multipart/form-data. Esse é o formato usado quando alguém envia um formulário com arquivos anexados.
O próprio BleepingComputer alertou que essa medida pode prejudicar bastante o funcionamento do site, impedindo visitantes de enviar formulários e carregar arquivos. Além disso, as medidas sugeridas por pesquisadores nos primeiros momentos não haviam sido verificadas quanto à capacidade real de impedir a exploração. Portanto, use com muito cuidado e só como último recurso temporário.
O papel do firewall de aplicações web e da Cloudflare
Antes de as correções saírem, a Cloudflare lançou uma atualização emergencial no conjunto de regras do seu Firewall de Aplicações Web (WAF) gerenciado. O WAF é um filtro que fica entre a internet e o seu site, analisando as requisições e barrando aquelas que parecem ataques conhecidos.
O diretor de tecnologia da empresa, Dane Knecht, confirmou que as regras iniciais foram projetadas para bloquear métodos de exploração já conhecidos e que estão disponíveis para todos os clientes, inclusive quem usa planos gratuitos. Ele também informou que a empresa já observava ataques iniciais e vinha atualizando as proteções conforme surgiam novas técnicas.
Por que o WAF não é uma solução definitiva
Aqui vale a mesma lógica da seção anterior. O próprio Knecht enfatizou que essas proteções são temporárias e recomendou que os administradores instalem as atualizações oficiais do PHP. Um firewall de aplicações reconhece padrões conhecidos de ataque, mas os invasores criativos sempre procuram variações.
Pense no WAF como um segurança na portaria: ajuda bastante, mas se a fechadura da porta principal está com defeito, o jeito é trocar a fechadura.
Outros alertas internacionais
O Centro Nacional de Segurança Cibernética do Reino Unido, o NCSC, também emitiu um alerta recomendando que as organizações atualizem imediatamente os sistemas que usam PHP ou os coloquem fora do ar até que as correções sejam aplicadas. Quando um órgão governamental sugere tirar sistemas do ar, o nível de seriedade fica bem claro.
Depois de atualizar: como verificar se algo deu errado
Aqui entram orientações gerais de boas práticas, que não vieram de nenhum comunicado oficial sobre o PHP2Shell, mas que fazem muito sentido em qualquer situação parecida. A janela entre o vazamento e a correção foi curta, mas a Cloudflare relatou ataques iniciais já em andamento. Então, vale dar uma olhada no que aconteceu no seu servidor nos últimos dias.
Revise os registros do servidor
Os registros (os arquivos de log) mostram tudo o que o servidor recebeu. Procure por picos incomuns de requisições, especialmente com envio de arquivos, e por erros fatais repetidos no PHP que não costumavam aparecer antes.
Procure arquivos que você não reconhece
Um sinal clássico de invasão é o surgimento de arquivos novos em pastas de envio, de temas ou de plugins, principalmente com nomes estranhos ou criados em datas incomuns. Se achar algo suspeito, não apague na pressa: guarde uma cópia para análise e envolva um profissional de segurança.
Troque senhas e chaves se houver suspeita
Se você desconfia de que o servidor foi atingido, troque senhas de banco de dados, de painéis de administração e chaves de acesso a serviços externos. Faça isso depois de garantir que o PHP já está atualizado, para que o invasor não consiga capturar as credenciais novas.
E para quem tem um site simples, sem equipe de tecnologia?
Muita gente que está lendo este artigo não é administradora de servidores. É dona de uma loja pequena, de um blog, de um site de consultório ou de uma landing page. Se esse é o seu caso, respire. Você não precisa virar especialista em segurança hoje, mas precisa fazer algumas perguntas certas.
Fale com quem cuida do seu site ou da hospedagem
Pergunte à empresa de hospedagem ou à agência responsável: o PHP do meu ambiente já foi atualizado para uma versão corrigida? Qual versão está em uso? Quando isso foi feito? Respostas claras são um bom sinal. Respostas vagas merecem insistência.
Mantenha o seu gerenciador de conteúdo em dia
Se o seu site usa WordPress ou outro gerenciador de conteúdo, mantenha o núcleo do sistema, os temas e os plugins atualizados. Isso não substitui a atualização do PHP, mas diminui outras portas de entrada que costumam aparecer em momentos de alerta como este.
Considere uma camada extra de proteção
Serviços de firewall de aplicações, como o oferecido pela Cloudflare, podem ser uma ajuda enquanto você resolve a atualização. Lembre-se apenas de que eles funcionam como reforço temporário e nunca como substituto da atualização oficial.
Se você gostou deste guia e conhece alguém que mantém um site em PHP, mande este texto para essa pessoa. Às vezes, um link compartilhado na hora certa evita um grande prejuízo.
Perguntas sobre o PHP2Shell
O que é o PHP2Shell?
É o nome informal dado a duas vulnerabilidades críticas de execução remota de código no PHP, identificadas como CVE-2026-109618 e CVE-2026-109619. Elas permitem que um atacante sem login execute código no servidor com os privilégios do processo de trabalho.
Meu site foi hackeado por causa do PHP2Shell?
Não necessariamente. Os pesquisadores da watchTowr disseram que não haviam observado exploração real no momento do vazamento, mas a Cloudflare relatou ataques iniciais direcionados às falhas. Revise os registros do servidor e procure sinais incomuns para ter mais segurança.
Quais versões do PHP já têm a correção?
Para quem usa a família 8.x, as versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Quem usa o PHP 7 ou anterior deve migrar para uma versão corrigida.
O PHP 8.1 ou o PHP 7.4 ainda recebem atualizações?
O projeto PHP informou que a versão 8.1 e as anteriores não recebem mais atualizações oficiais. Algumas distribuições e fornecedores de suporte de longo prazo oferecem correções adaptadas, e a equipe de segurança também disponibilizou versões mínimas de código-fonte para o PHP 7.4, o PHP 8.0 e o PHP 8.1.
Preciso tirar meu site do ar?
A orientação é atualizar imediatamente ou colocar os sistemas fora do ar até que as correções sejam aplicadas. Para a maioria dos sites, atualizar o PHP o quanto antes já resolve. Se a atualização for impossível no curto prazo e o sistema for crítico, converse com um profissional de segurança sobre a melhor decisão.
Um firewall de aplicações web protege contra o PHP2Shell?
Ele ajuda, mas não resolve sozinho. As regras da Cloudflare bloqueiam métodos de exploração conhecidos, e a própria empresa afirma que são medidas temporárias. A única proteção permanente é instalar as atualizações oficiais do PHP.
Desativar o progresso de envio de sessão resolve o problema?
Essa configuração, session.upload_progress.enabled, faz parte das medidas sugeridas para a CVE-2026-109619, mas não elimina o risco por completo. Ela deve ser usada apenas enquanto a atualização oficial não é aplicada.
Um último recado antes de você fechar esta página
Falhas críticas aparecem de tempos em tempos, e o PHP2Shell é mais uma lembrança de que manter o ambiente atualizado não é capricho, é rotina de sobrevivência na internet. O lado bom desta história é que a correção já existe, foi lançada rápido e está ao alcance.
Então, faça a sua parte hoje: confira a versão do PHP, converse com a sua hospedagem e agende a atualização sem empurrar para a semana que vem.
