Resposta curta: em 21 de outubro de 2026, o projeto PHP publicou duas falhas críticas (CVE-2026-109618 e CVE-2026-109619) que permitem a um atacante sem login executar código no servidor. A correção está nas versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Quem tem site, loja virtual ou sistema em PHP precisa atualizar e reiniciar o servidor.
O PHP roda uma parte enorme da web: sites institucionais, lojas, portais de notícia, sistemas de gestão e o WordPress. Por isso o aviso chegou a times de tecnologia, agências e donos de site no mesmo dia. Este guia explica o que aconteceu, quem corre risco e o que fazer, em linguagem direta.
O que é a falha crítica no PHP
São duas falhas relacionadas, ambas na parte do PHP que cuida da memória e dos erros, algo que quase toda requisição toca.
- CVE-2026-109618 (nota 9,2 de 10): quando uma requisição estoura o limite de memória no momento errado, o PHP deixa dados internos pela metade e depois os trata como válidos. Um atacante habilidoso transforma isso em execução de código.
- CVE-2026-109619: um erro fatal pode deixar, no processo do servidor, um apontamento para memória da requisição anterior. A próxima requisição usa esse dado velho, e o resultado também pode ser execução de código.
Em linguagem simples: um visitante que ninguém autorizou consegue, em certas condições, mandar o servidor rodar comandos dele. O ataque não depende de senha, de plugin vulnerável nem de erro do dono do site.
Quem corre risco
Todo servidor que atende páginas com PHP está no alcance: Apache com mod_php, PHP-FPM, php-cgi, FrankenPHP e LiteSpeed. O projeto considera o risco mais alto no Apache com mod_php, onde um ataque demonstrado acontece antes de qualquer código do site rodar.
| Situação | O que fazer |
|---|---|
| PHP 8.2 a 8.5 | Atualizar para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 e reiniciar |
| PHP 8.1 ou anterior | Sem correção oficial. Usar backport do fornecedor do sistema ou migrar para versão suportada |
| WordPress, WooCommerce, Magento, Laravel | A correção está no PHP do servidor, e atualizar o CMS não substitui isso |
| Hospedagem compartilhada | Cobrar do suporte, por escrito, a data e a versão do PHP |
| Docker | Trocar para a imagem oficial com a tag corrigida e reconstruir as imagens que dependem dela |
Como saber se o seu site usa PHP vulnerável
- Descubra a versão do PHP que atende o site. No painel da hospedagem ou com o time técnico. O PHP da linha de comando pode ser diferente do PHP do site.
- Compare com as versões corrigidas: 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
- Se a versão é menor, ou se é 8.1 ou mais antiga, o ambiente está vulnerável.
- Em hospedagem gerenciada, pergunte ao fornecedor se o patch já foi aplicado.
O que fazer hoje
- Listar todos os sites e sistemas em PHP da empresa, inclusive os esquecidos.
- Atualizar o PHP para a versão corrigida e reiniciar o PHP-FPM ou o Apache, porque os processos antigos continuam com a versão vulnerável na memória.
- Reduzir a exposição onde a atualização precisa esperar, com as medidas abaixo.
- Revisar os logs e os arquivos em busca de sinais de invasão.
- Avisar time, clientes e diretoria com uma mensagem curta e o prazo de cada correção.
Medidas temporárias para quem não consegue atualizar hoje
O projeto PHP é claro: só a atualização resolve por completo. As medidas abaixo reduzem caminhos de ataque conhecidos e servem como ponte até a troca de versão.
- Desligar o progresso de upload da sessão (
session.upload_progress.enabled=0) na configuração do servidor e reiniciar. - No PHP 8.5, desligar
fatal_error_backtraces. - Reduzir o
post_max_sizee limitar no servidor web o tamanho do corpo, o número de campos e de partes multipart. - Bloquear requisições multipart antes de chegarem ao PHP, nos sites que não recebem upload.
- Fixar
memory_limit=-1de um jeito que a aplicação não consiga alterar, como indica o aviso oficial.
Um firewall de aplicação ajuda a reduzir tentativas, principalmente com regras para requisições multipart. Ele reduz risco e deixa a atualização como passo obrigatório.
Como identificar sinais de invasão
- Arquivos
.phpnovos em pastas de upload e arquivos recentes que ninguém reconhece. - Processos, tarefas agendadas ou usuários novos no servidor.
- Requisições multipart incomuns e quedas repetidas de processos do PHP nos logs.
Com qualquer indício, isole o servidor, restaure um backup anterior ao período de exposição e troque senhas e chaves. Ausência de erro no log não prova que o servidor está seguro, porque o PHP pode falhar antes de registrar a mensagem.
Por que a correção demorou
A PHP Foundation descreveu o histórico com transparência. Uma auditoria externa em 2024 achou os primeiros sinais do problema de memória, sem caminho conhecido de ataque. As correções possíveis tinham custos altos de compatibilidade, e a decisão por consenso emperrou por meses. Em agosto de 2026, uma nova auditoria demonstrou execução de código completa com a mesma causa, e a correção passou a ser a prioridade do time.
Os números do aviso saíram antes da hora combinada, o projeto antecipou o lançamento em um dia, e provas de conceito começaram a circular no mesmo dia. Com os detalhes técnicos públicos, o tempo entre o aviso e o ataque é curto.
A Incuca cuida desse tipo de falha
Proteger o ambiente dos clientes contra falhas como esta é parte do trabalho da Incuca. Quando o aviso do PHP saiu, o time levantou os ambientes em PHP da carteira, aplicou a correção e os clientes foram protegidos logo no início.
O mesmo cuidado vale para versão do PHP, do servidor, do CMS e dos plugins: cada camada tem responsável, calendário de atualização e conferência depois da troca.
Segurança em PHP não termina nesta correção
Esta falha mostra um padrão: o risco de um site vem da camada de baixo, que o dono do negócio raramente vê. Versão do PHP, do servidor, do CMS e dos plugins precisam de um responsável e de um calendário. Quem quer um ponto de partida pode ler nossos guias sobre como saber se seu site está seguro, boas práticas em segurança digital e fundamentos de segurança da informação.
Quer saber se os seus sites e sistemas em PHP estão protegidos? Fale com o time comercial da Incuca. A gente levanta os ambientes, confere as versões e aplica a correção.
Perguntas frequentes
São duas falhas, CVE-2026-109618 e CVE-2026-109619, que permitem a um atacante sem login executar código no servidor. Elas envolvem o tratamento de memória e de erros do PHP e afetam servidores web com PHP em todas as versões anteriores às corrigidas.
As versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP 8.1 e as anteriores não recebem atualização do projeto, e algumas distribuições oferecem backport por conta própria.
O WordPress roda sobre o PHP do servidor, então o risco depende da versão do PHP. Atualizar o WordPress e os plugins continua sendo boa prática, e a correção desta falha está na atualização do PHP.
Atualizar para a versão corrigida e reiniciar o servidor é a solução completa indicada pelo projeto PHP. Depois disso vale revisar logs e arquivos para confirmar que não houve invasão antes da atualização.
Aplicar as medidas temporárias do aviso oficial: desligar session.upload_progress, limitar o tamanho e a estrutura de requisições multipart, bloquear multipart onde não há upload e, no PHP 8.5, desligar fatal_error_backtraces. Elas reduzem o risco e não substituem a atualização.
Um firewall de aplicação com regras para requisições multipart reduz tentativas de ataque. O projeto PHP afirma que mitigação não substitui a atualização.
Procure arquivos PHP novos em pastas de upload, processos e tarefas agendadas desconhecidos e requisições multipart incomuns nos logs. Com qualquer indício, isole o servidor, restaure um backup anterior e troque senhas e chaves.
Sim, qualquer aplicação que rode sobre um PHP vulnerável fica no alcance. A correção é atualizar a versão do PHP.
Fontes
- PHP.net. “Security advisory: Critical remote code execution vulnerabilities, update now”. www.php.net
- GitHub php/php-src. “RCE via OOM corruption (CVE-2026-109618)”. github.com
- GitHub php/php-src. “RCE via stale global state (CVE-2026-109619)”. github.com
- PHP Foundation. “Today’s PHP Security Release, and How We’re Strengthening PHP Security”. thephp.foundation
