Duas falhas críticas no PHP permitem execução remota de código. O que fazer agora?

O PHP publicou correções emergenciais para duas vulnerabilidades críticas que permitem execução remota de código sem autenticação em determinados cenários.

As falhas receberam CVSS 9.2 e afetam versões suportadas do PHP. O ponto mais importante é simples:

não é uma falha do Laravel, Symfony ou WordPress. O problema está no próprio PHP.

Isso significa que atualizar o framework não resolve.

As versões corrigidas são:

Se a aplicação está exposta à internet, eu trataria essa atualização como prioridade.

O que aconteceu?

Foram divulgadas duas vulnerabilidades:

As duas podem levar a RCE — Remote Code Execution.

Em outras palavras, em determinadas condições, um atacante pode conseguir executar código no servidor com os privilégios do processo PHP.

Isso coloca em risco:

• APIs;
• aplicações web;
• sistemas financeiros;
• painéis administrativos;
• workers persistentes;
• servidores PHP-FPM;
• ambientes com Apache + mod_php.

A primeira falha envolve falta de memória

A CVE-2026-109618 está relacionada ao tratamento de situações de Out Of Memory.

Quando o PHP fica sem memória, parte da execução é interrompida rapidamente. O problema é que algumas estruturas internas podem ficar em um estado inconsistente.

De forma simplificada:

Esse tipo de falha é especialmente perigoso porque acontece dentro da própria engine.

Ou seja: o Laravel nem precisa ter começado a processar a requisição.

A segunda falha envolve workers persistentes

A CVE-2026-109619 chama atenção principalmente em ambientes com processos PHP reutilizados, como PHP-FPM.

Imagine que uma requisição crie um estado interno e termine de forma anormal:

Depois, o mesmo worker recebe outra requisição:

Esse tipo de situação pode resultar em corrupção de memória e, em cenários exploráveis, execução remota de código.

O detalhe importante é que a exploração pode envolver mais de uma requisição no mesmo processo PHP.

Laravel protege?

Não.

E esse é um dos pontos mais importantes dessa vulnerabilidade.

Mesmo que sua aplicação tenha validação, autenticação, CSRF e middlewares bem configurados, isso não impede uma falha que acontece dentro da própria engine.

A cadeia é mais parecida com:

Se o problema acontece no primeiro nível, o framework não consegue impedir.

PHP-FPM está vulnerável?

Sim.

Ambientes com:

podem ser afetados.

Apache com mod_php aparece como um cenário especialmente sensível em alguns vetores, mas usar Nginx ou Apache com PHP-FPM não elimina o risco.

Ou seja:

não significa:

E versões antigas como PHP 7.4 ou 8.1?

Aqui temos outro problema.

As correções oficiais foram publicadas apenas para as versões atualmente suportadas:

Se você ainda mantém:

não existe uma versão oficial nova publicada pelo PHP Project para corrigir a falha.

Nesse caso, existem duas opções:

• verificar se a distribuição Linux ou fornecedor LTS publicou um backport;
• migrar para uma versão suportada.

Esse é mais um exemplo do risco de manter versões antigas do PHP apenas porque “a aplicação ainda funciona”.

O que verificar agora

Primeiro, veja a versão instalada:

Depois, confira o PHP-FPM:

ou:

No Ubuntu:

Compare com as versões corrigidas:

Se estiver abaixo disso, atualize.

Não esqueça dos workers

Esse ponto costuma passar batido.

Depois de atualizar os pacotes, processos antigos ainda podem continuar carregados na memória.

Então eu reiniciaria:

e, dependendo do ambiente:

Em aplicações Laravel com filas:

ou:

O mesmo vale para qualquer processo PHP de longa duração.

Existe mitigação sem atualizar?

Existem medidas temporárias, mas elas não substituem o patch.

Uma delas é:

Depois:

Isso reduz um dos vetores conhecidos da CVE-2026-109619.

Mas o próprio projeto PHP deixa claro que essas medidas não cobrem todos os caminhos possíveis.

Por isso, eu trataria mitigação como:

e não como:

Por que essa falha merece atenção imediata?

Porque reúne vários fatores preocupantes:

• execução remota de código;
• possibilidade de ataque sem autenticação;
• impacto na própria engine;
• ambientes PHP muito comuns;
• inexistência de mitigação completa por configuração;
• versões antigas sem correção oficial.

Minha recomendação

Se você mantém uma aplicação PHP pública, eu seguiria esta ordem:

1. atualizar servidores expostos à internet;
2. reiniciar PHP-FPM e Apache;
3. reiniciar workers e filas;
4. validar APIs e uploads;
5. revisar servidores antigos;
6. verificar PHP 7.4, 8.0 e 8.1;
7. acompanhar logs e comportamento anormal.

E principalmente:

não espere um ataque confirmado no seu servidor para atualizar.

O problema não é o Laravel

Esse incidente reforça algo importante para quem trabalha com PHP:

segurança não termina no framework.

Uma aplicação pode estar com:

• Laravel atualizado;
• dependências em dia;
• autenticação correta;
• validação funcionando;

e ainda assim ficar vulnerável porque a camada abaixo dela possui uma falha crítica.

Por isso, manter PHP, extensões, servidor web, sistema operacional e dependências atualizados faz parte do trabalho de backend tanto quanto escrever código.

No fim, a correção mais importante aqui não é uma nova regra de validação nem um middleware.

É simples: atualize o PHP.

Fonte oficial: PHP Security Advisory — 21/10/2026
php.net — Critical remote code execution vulnerabilities