Atualizar o PHP e validar a intervenção
Atualizado em 28 de outubro de 2026. As correções de segurança anunciadas em 21 de outubro já estão disponíveis; esta revisão substitui a orientação publicada antes do lançamento. A data original de publicação e os URLs são preservados.
As versões corrigidas para as duas vulnerabilidades são PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Deve usar-se uma destas versões ou uma versão posterior corrigida numa linha suportada; se o fornecedor incorporar correções num pacote anterior, confirme o respetivo aviso de segurança. [14][15]
O PHP 8.4.27 é uma versão oficial de segurança. A disponibilidade e a instalação do pacote continuam a exigir confirmação junto de cada alojamento; um anúncio não demonstra que um website concreto tenha sido atualizado. [13]
A Cyberprotech® recomenda identificar os sistemas, articular a intervenção com a equipa técnica e validar a correção aplicada e o funcionamento da aplicação. Se a atualização já tiver sido efetuada, preserve a evidência do interpretador web efetivo e dos testes realizados.
O que se sabe sobre as vulnerabilidades
O CERT-EU identifica as falhas como CVE-2026-109618 e CVE-2026-109619 e alerta para o potencial de execução remota de código sem autenticação. Um ataque bem-sucedido poderá permitir executar código no servidor com as permissões do processo afetado, comprometendo o website e os dados a que esse processo tenha acesso. [2]
PHP2Shell é a designação pública associada a estas vulnerabilidades. O projeto PHP publicou dois avisos distintos com as condições e as correções. A possibilidade de exploração depende do servidor, da configuração e da aplicação; o nome de uma plataforma não demonstra, por si só, a exposição. [14][15]
Devem ser verificados os websites WordPress e outras aplicações que utilizem PHP, incluindo serviços internos, subdomínios e ambientes de teste acessíveis pela Internet. A responsabilidade pela atualização pode pertencer ao fornecedor de alojamento, ao administrador da infraestrutura ou à empresa de manutenção. Atualizar o WordPress, os temas ou os plugins não comprova a atualização do PHP no servidor.
A configuração temporária não substitui a atualização
Desativar o progresso dos carregamentos em sessão pode bloquear caminhos confirmados relacionados com o ciclo de vida das sessões, mas não é uma mitigação completa. O aviso oficial sobre estado global exige configuração administrativa e reinício dos processos; descreve também outros caminhos que essa opção não cobre. [15]
session.upload_progress.enabled = Off
A configuração de arranque deve ser aplicada e verificada com a equipa de infraestrutura. Não dependa de ini_set() ou de uma alteração FPM em .user.ini para proteger o processamento inicial dos pedidos. Esta opção trata do acompanhamento do progresso; não é uma proibição geral de uploads. [1][3][15]
Em 23 de outubro, o PHP publicou orientação adicional sobre o progresso dos carregamentos em sessão e uma combinação invulgar de configuração e código, identificada como CVE-2026-115560. As restrições administrativas existentes devem ser revistas à luz desse aviso, em vez de removidas automaticamente após atualizar. [1]
A Cyberprotech® recomenda documentar as medidas temporárias, testar o seu impacto operacional e confirmar a atualização completa. A sua presença não deve encerrar o alerta nem ser apresentada como prova de que a instalação está protegida.
As proteções temporárias exigem confirmação técnica
O registo oficial da Cloudflare inclui atualizações WAF de emergência de 21 de outubro, também para o conjunto de regras gratuito, destinadas a padrões anómalos de pedidos. Esta informação não comprova, por si só, cobertura integral dos dois CVE em cada instalação. A proteção temporária deve acompanhar a aplicação das correções. [6]
Se o website utilizar este serviço, a equipa técnica deve confirmar que o tráfego passa efetivamente pelo proxy, que as regras relevantes estão ativas e que não existem exceções ou acessos diretos ao servidor que contornem a inspeção. A Cloudflare documenta medidas específicas de proteção da origem, incluindo restrições ao tráfego que a pode alcançar. [7]
Bloqueios improvisados de pedidos multipart/form-data, alterações avulsas ao php.ini ou regras copiadas de redes sociais também não devem ser apresentados como proteção completa. Qualquer medida desse tipo exige validação técnica e avaliação do impacto nos formulários, carregamentos e integrações da aplicação.
Quando não for possível corrigir de imediato, o CERT-EU recomenda considerar o isolamento temporário das aplicações expostas à Internet. A decisão deve ter em conta a exposição, os dados tratados e a continuidade do serviço. [2]
Como aplicação prática dessa orientação, a Cyberprotech® recomenda avaliar restrições de acesso na rede ou no servidor web, antes de os pedidos chegarem ao PHP. Para websites institucionais, uma página estática temporária com contactos essenciais pode preservar a comunicação, desde que a aplicação PHP fique efetivamente inacessível ao público. Um modo de manutenção implementado dentro do próprio WordPress não comprova esse isolamento.
Syhunt: uma medida temporária para avaliar em Apache
O projeto php2shell-protection disponibiliza uma regra Apache que rejeita pedidos POST multipart/form-data antes do PHP e um teste funcional. Pode ser avaliado quando esses pedidos não são necessários. Também bloqueia formulários e carregamentos legítimos. [12]
Um resultado 403 no teste não comprova a correção dos CVE. A regra depende da configuração efetiva do Apache e não cobre todos os métodos HTTP ou outros interpretadores. A Cyberprotech® recomenda testar num ambiente controlado, verificar os registos, definir reversão e remover o ficheiro de teste após utilização. A atualização oficial continua a ser necessária. [12]
Atualizar e validar sem demora
1 Identificar os sistemas e o responsável pela intervenção
Registar os domínios, aplicações, servidores e contentores que utilizam PHP. Confirmar a versão efetivamente usada em cada serviço e quem tem acesso para a atualizar. Incluir ambientes secundários e cópias antigas ainda publicadas.
2 Verificar se a versão ainda recebe correções
Se o PHP estiver fora de suporte, preparar a migração para uma versão suportada e corrigida, validando a compatibilidade da aplicação. Quando o fornecedor disponibilizar manutenção adicional ou correções próprias, pedir confirmação documental da cobertura destas vulnerabilidades. [11]
3 Contactar o alojamento e a empresa de manutenção
Solicitar confirmação sobre a exposição às CVE-2026-109618 e CVE-2026-109619, o plano de atualização e as medidas temporárias disponíveis. Pedir uma previsão concreta de intervenção e confirmação escrita do resultado.
4 Preparar a alteração e a recuperação
Confirmar cópias de segurança utilizáveis, dependências e testes essenciais. Se existirem sinais de intrusão, preservar registos e evidências. Uma cópia produzida depois de um eventual compromisso pode já conter alterações maliciosas.
5 Reduzir a exposição até à correção
Validar as proteções disponibilizadas pelos fornecedores e avaliar restrições temporárias de acesso quando necessário. Manter a monitorização de alertas, erros inesperados, alterações a ficheiros e criação de contas administrativas.
O que confirmar depois da atualização
A Cyberprotech® recomenda que a intervenção só seja dada como concluída depois de verificadas as seguintes condições:
Correção identificada: a versão ou revisão do pacote instalado deve estar documentada pelo PHP ou pelo fornecedor como corrigindo ambos os CVE. Se o fornecedor mantiver um número de versão anterior com correções incorporadas, exigir o respetivo aviso de segurança.
PHP usado pelo website: confirmar o interpretador que processa os pedidos web. O resultado de php --version na linha de comandos identifica esse executável e não demonstra, isoladamente, qual a versão usada pelo PHP-FPM ou pelo servidor web. A data de compilação também não prova a inclusão das correções. [8]
Processos efetivamente atualizados: reiniciar ou substituir os serviços, processos e contentores necessários, segundo as instruções do fornecedor. Verificar todos os nós e as imagens utilizadas em novos arranques.
Funcionamento validado: testar autenticação, formulários, carregamentos, pagamentos e integrações que existam na aplicação. Registar a versão, a data, o responsável e o resultado da intervenção.
Atividade suspeita investigada: a atualização não demonstra que não houve acesso anterior nem remove automaticamente código malicioso ou contas criadas por um atacante. Se existirem indícios, iniciar uma investigação e recuperação próprias.
O alerta PHP é distinto do incidente UpdraftCentral
A versão original de 21 de outubro referia também o incidente TeamUpdraft/UpdraftCentral. Trata-se de um assunto separado, com medidas próprias de revogação e verificação dos websites; atualizar o PHP não substitui essas ações. Consulte o aviso do fornecedor para confirmar o estado desse incidente. [9]
A prioridade é agir com informação verificada
As organizações devem saber que sistemas utilizam PHP, quem assegura a intervenção e como será demonstrada a correção. A existência de uma versão corrigida não prova que todos os alojamentos a tenham instalado. Obtenha confirmação para cada ambiente.
A Cyberprotech® pode apoiar a identificação dos sistemas expostos, a articulação com os prestadores e a validação das medidas aplicadas. Para avaliar a situação da sua organização, contacte-nos através de https://cyberprotech.pt/.
Este artigo reflete a data de revisão indicada. Confirme as versões corrigidas, as condições relevantes e as orientações atuais do fornecedor ao preparar cada intervenção.