PHP publicou nesta quarta-feira, 21 de outubro de 2026, as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, que corrigem duas vulnerabilidades críticas no PHP, ambas com pontuação CVSS v4.0 9.2. As falhas podem permitir execução remota de código (RCE) sem autenticação, e a recomendação oficial é atualizar imediatamente.
Quem está em risco
Todas as instalações PHP que atendem requisições web estão em risco, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é maior no mod_php: já existe um exploit demonstrado em que uma requisição sem autenticação dispara o ataque antes de qualquer código da aplicação ser executado. Ou seja, não importa se o seu WordPress, plugins e temas estão atualizados: a falha está no próprio PHP.
As vulnerabilidades
| CVE | Advisory | O que é |
|---|---|---|
| CVE-2026-109618 | GHSA-w8hw-w9fx-j79w | RCE por corrupção na falta de memória (OOM): o tratamento de falta de memória pode interromper o PHP com dados internos da requisição pela metade, e a limpeza da requisição passa a tratar esses dados inválidos como válidos. |
| CVE-2026-109619 | GHSA-6wmf-4rv5-p3rp | RCE por estado global residual: um estado interno da requisição sobrevive depois que a memória dele é liberada, e uma requisição seguinte no mesmo worker pode usá-lo antes de ser reinicializado. |
Por que atualizar agora
Com a correção publicada, as alterações no código-fonte ficam visíveis para qualquer pessoa, e atacantes usam essas diferenças para criar exploits em poucas horas. Como o PHP roda boa parte da web, incluindo WordPress, Laravel, Magento e Drupal, cada hora sem atualizar é uma janela aberta para ataques sem autenticação.
Como atualizar
- Atualize para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.
- As distribuições Linux e os fornecedores de LTS receberam as correções com antecedência. Verifique se os pacotes atualizados já estão disponíveis.
- Em hospedagens gerenciadas, confirme com o provedor quando a atualização será aplicada.
- Quem usa o repositório rpms.remirepo.net não terá atualização hoje. O PHP recomenda migrar para os pacotes da distribuição ou compilar a partir do código-fonte.
- O PHP 8.2 deixa de receber correções de segurança em 31/12/2026. Planeje a migração.
E o PHP 7.x?
O PHP 7.4, 8.0 e 8.1 não recebem mais versões oficiais. Por causa da gravidade, a equipe de segurança publicou correções mínimas apenas em código-fonte para essas versões, voltadas a quem compila o PHP por conta própria. Não há pacote pronto: quem não tem um fornecedor de LTS vai precisar compilar ou, de preferência, migrar para uma versão suportada. Para os muitos sites WordPress ainda presos ao PHP 7.4, este é o empurrão definitivo.
Se não for possível atualizar agora
As medidas abaixo reduzem a exposição, mas não tornam o ambiente seguro. Só a atualização resolve o problema.
- CVE-2026-109618: definir
memory_limit=-1de forma que a aplicação não consiga sobrescrever (por exemplo,php_admin_valueno pool do FPM). Reduzirpost_max_size(8M sem uploads, 32M com uploads). Usar limites de memória do contêiner ou do cgroup, e nãoRLIMIT_AS/RLIMIT_DATA. - CVE-2026-109619: definir
session.upload_progress.enabled=0no php.ini ou no pool do FPM e reiniciar todos os workers. No PHP 8.5, definir tambémfatal_error_backtraces=0. Corrigir erros fatais e timeouts que um atacante consiga provocar.
Adendo: Cloudflare já bloqueia ataques ao php2shell
A Cloudflare informou que as falhas, apelidadas de php2shell, afetam servidores com PHP 5.4 ou superior, e que os detalhes vazaram antes da divulgação oficial: a empresa já observou tráfego de ataque contra clientes, com atacantes alterando o payload para tentar burlar as proteções.
Desde 21 de outubro, às 3h02 UTC, cerca de 9 horas antes da divulgação pública, as regras de WAF da Cloudflare protegem por padrão os sites atrás dela, inclusive no plano Free. As regras analisam a requisição e também a resposta do servidor de origem, e conseguem bloquear a resposta antes que dados expostos cheguem ao atacante.
- Plano Free: a proteção já está ativa, não é preciso fazer nada.
- Planos Pro, Business e Enterprise: confirme que o Cloudflare Managed Ruleset está implantado em modo de bloqueio.
- Para acompanhar: os bloqueios aparecem em Security > Security Analytics > Events.
A própria Cloudflare reforça que o WAF é uma camada extra de defesa e não substitui a atualização do PHP.
