Seu servidor PHP está protegido contra as duas falhas críticas?

Se seu site ou sistema roda PHP, vale conferir a versão agora. Em 20 de outubro, a equipe de segurança do PHP avisou que preparava correções para duas vulnerabilidades críticas. No dia seguinte, publicou as versões corrigidas e recomendou a atualização imediata.

As falhas receberam nota 9,2 no CVSS 4.0 e podem permitir execução remota de código sem autenticação. Em termos simples, um invasor poderia enviar uma requisição preparada e fazer o servidor executar instruções, antes mesmo de a aplicação processar normalmente aquela solicitação. Isso não significa que todos os sites foram invadidos, mas torna importante confirmar a versão em uso e aplicar o pacote corrigido.

A correção já existe: o passo mais importante é atualizar o PHP que atende as requisições do seu site, não apenas o PHP do terminal.

O aviso se aplica a instalações PHP que recebem requisições web. Isso inclui PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. A equipe do PHP destaca que mod_php apresenta o risco mais alto entre as configurações avaliadas, com uma demonstração em que uma requisição não autenticada alcança a falha antes da execução do código da aplicação.

As vulnerabilidades são identificadas como CVE-2026-109618 e CVE-2026-109619. Uma está ligada a um caminho de tratamento de memória em condição de erro; a outra envolve estado interno mantido entre etapas do processamento. Não é necessário reproduzir esses cenários para se proteger. Para quem administra o servidor, a decisão prática é identificar a versão e instalar o patch indicado para sua linha.

Se você usa hospedagem compartilhada ou um serviço gerenciado, o fornecedor pode controlar a instalação. Mesmo assim, o responsável pelo site pode abrir um chamado e pedir confirmação do pacote aplicado. Ter atualizado o WordPress ou outra biblioteca PHP não atualiza automaticamente o runtime do servidor.

Comece pelo ambiente em que a aplicação roda. Se você tem acesso SSH, execute o comando abaixo. Ele informa a versão do PHP disponível naquele terminal:

php -v

O resultado é um primeiro sinal, mas não é prova suficiente em servidores com várias versões. O comando pode apontar para o PHP da linha de comando, enquanto o site usa outra versão no PHP-FPM, no Apache, no painel da hospedagem ou dentro de um contêiner.

docker compose exec php php -v

Nesse exemplo, php é o nome do serviço no arquivo compose. Troque pelo nome usado no seu projeto. Se a aplicação está em uma hospedagem com painel, confira a versão selecionada para o domínio ou pergunte ao suporte qual versão do PHP-FPM atende aquele site. Evite publicar um arquivo phpinfo() aberto na internet: ele pode revelar caminhos, extensões e configurações internas.

O projeto publicou atualizações para quatro linhas mantidas. O número final é o que confirma que o patch entrou naquela linha:

• PHP 8.5: atualize para 8.5.12 ou uma versão posterior da mesma linha.
• PHP 8.4: atualize para 8.4.27 ou uma versão posterior da mesma linha.
• PHP 8.3: atualize para 8.3.36 ou uma versão posterior da mesma linha.
• PHP 8.2: atualize para 8.2.35 ou uma versão posterior da mesma linha.

Distribuições Linux e fornecedores de suporte de longo prazo podem aplicar a correção sem copiar exatamente o número upstream. Por isso, não compare apenas o sufixo: consulte o aviso de segurança do seu fornecedor e confirme que o pacote instalado inclui os dois CVEs. PHP 8.1 e versões anteriores não recebem correções diretamente do projeto PHP; algumas distribuições podem fornecer backports. Se esse for seu caso, confirme o status com o fornecedor e planeje a migração para uma versão mantida.

Antes de alterar um servidor de produção, registre a versão atual, salve uma cópia de segurança dos arquivos e do banco e anote como voltar ao último pacote funcional. Se houver ambiente de teste, aplique a atualização primeiro nele. A meta não é adiar o patch por vários dias, mas identificar incompatibilidades básicas sem fazer a mudança às cegas.

Em um projeto com Docker Compose, por exemplo, confira se a imagem do serviço PHP está fixada em uma versão antiga. Atualize a tag para uma versão corrigida compatível com sua aplicação e depois baixe e recrie o serviço:

docker compose pull php
docker compose up -d php

O nome php precisa corresponder ao serviço definido no seu compose.yaml. Se o projeto usa uma imagem customizada, revise o Dockerfile, atualize a imagem base, reconstrua a imagem e publique a nova versão. Não use uma tag genérica sem entender como ela é atualizada: fixar uma versão ajuda a reproduzir o deploy, mas exige que alguém aplique os patches seguintes.

Em servidor instalado diretamente, use os repositórios mantidos pelo sistema operacional ou pelo provedor. Evite misturar pacotes de repositórios diferentes ou substituir binários manualmente. Se a aplicação depende de extensões como mbstring, intl, pdo_mysql ou redis, confira se elas continuam instaladas na nova versão e reinicie o PHP-FPM ou o serviço web conforme a orientação do fornecedor.

Depois da atualização, repita a verificação no servidor e no contêiner. Confirme também a versão configurada para o domínio no painel ou no serviço de deploy. Em seguida, abra as rotas principais do site, faça login se houver uma área autenticada e acompanhe os logs do PHP-FPM, do servidor web e da aplicação.

Se uma página retornar erro 500, compare o log com a lista de extensões e a versão que foi atualizada. Uma incompatibilidade do código com uma versão nova é possível, mas não é motivo para deixar o servidor exposto indefinidamente. Faça o diagnóstico em ambiente de teste, ajuste dependências e combine com o fornecedor uma janela curta de correção.

Em uma aplicação containerizada, verifique também se o deploy realmente substituiu os contêineres antigos. Uma imagem nova pode ter sido criada enquanto uma instância anterior continua recebendo tráfego. Em plataformas gerenciadas, procure o identificador da imagem ou do pacote no registro de deploy.

Atualizar dependências da aplicação e atualizar o runtime PHP são tarefas diferentes. Confira as duas camadas.

Envie ao suporte da hospedagem o nome do domínio, o horário em que fez a consulta e a pergunta objetiva: qual versão corrigida do PHP está atendendo este domínio e quando o patch foi aplicado? Se houver mais de um ambiente, pergunte também pela aplicação de produção, staging e tarefas agendadas. Um cron job pode usar um binário PHP diferente daquele configurado no site.

Enquanto espera, evite alterar configurações avançadas por conta própria. O comunicado oficial informa que não há uma mitigação completa para substituir a atualização. Regras de firewall podem reduzir alguns caminhos de acesso, mas não devem ser tratadas como correção definitiva. Se o fornecedor não puder confirmar o patch, considere preparar uma migração assistida para um ambiente mantido.