Preparar a intervenção
Informação verificada em 21 de outubro de 2026 às 12h05 de Portugal continental (UTC+1). O anúncio oficial ainda apresentava o lançamento das correções como previsto para as 15h00.
As organizações que utilizam PHP nos seus websites, lojas online ou aplicações devem contactar os responsáveis técnicos e preparar uma atualização urgente. A equipa de segurança do PHP anunciou uma versão de segurança para 21 de outubro de 2026, às 14h00 UTC, correspondentes às 15h00 em Portugal continental, para corrigir duas vulnerabilidades críticas com classificação CVSS v4.0 de 9,2 em 10. [1]
À hora de verificação deste artigo, o anúncio oficial mantinha o lançamento como previsto e indicava que os detalhes técnicos, as versões afetadas e as versões corrigidas seriam publicados com a atualização. A disponibilização dos pacotes em cada serviço de alojamento poderá ocorrer em momentos diferentes. [1]
A Cyberprotech® recomenda iniciar já a identificação dos sistemas, confirmar quem pode atualizar o PHP e avaliar a redução temporária da exposição à Internet. Aguardar a publicação das correções deve fazer parte de uma resposta preparada, com responsáveis e verificações definidos.
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 usada na divulgação pública destas vulnerabilidades. O âmbito exato ainda dependia dos detalhes oficiais: o CERT-EU refere que poderão estar abrangidas versões desde PHP 5, mas essa indicação não demonstra que todos os websites PHP sejam exploráveis nas mesmas condições. [1][2]
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 que circula não permite considerar o servidor protegido
Estão a circular sugestões para desativar o acompanhamento do progresso dos carregamentos de ficheiros através desta configuração no php.ini:
session.upload_progress.enabled = Off
Também surge a definição da mesma opção num pool PHP-FPM:
php_admin_flag[session.upload_progress.enabled] = off
A opção existe e a documentação do PHP admite desativá-la quando a funcionalidade não é utilizada, como medida geral de segurança. Contudo, isso não constitui uma validação da sua eficácia contra estes dois CVE. A configuração desativa o registo do progresso dos carregamentos; não equivale a bloquear todos os carregamentos de ficheiros nem a corrigir o código vulnerável. A forma PHP-FPM aplica a mesma opção num contexto de configuração diferente. [3]
O anúncio oficial do PHP recomenda preparar a atualização logo que a versão de segurança esteja disponível. Não existe, nas fontes oficiais consultadas, fundamento para declarar um sistema protegido apenas porque esta opção foi desativada. [1]
A recomendação da Cyberprotech® é clara: esta alteração não deve servir para encerrar o alerta, adiar a atualização ou garantir aos clientes que o risco foi eliminado. Se já tiver sido aplicada, continua a ser necessário confirmar a correção do PHP.
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]
O que fazer antes da disponibilização das correções
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 enquanto se aguarda
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
Circula igualmente um aviso sobre acesso não autorizado à TeamUpdraft e a exposição de chaves UpdraftCentral. É um incidente separado, com medidas próprias de revogação de ligações e verificação dos websites. Atualizar o PHP não substitui essas ações; atualizar o UpdraftPlus também não corrige o PHP do servidor. [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á comprovada a correção. O horário de lançamento anunciado não garante que todos os alojamentos estejam atualizados nesse momento. A confirmação tem de ser obtida 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 informação disponível à hora indicada. As versões corrigidas, as condições de exploração e as orientações dos fornecedores devem ser confirmadas nas fontes oficiais no momento da intervenção.