PHP: vulnerabilidades críticas permitem execução remota de código — atualize já

PHP: vulnerabilidades críticas permitem execução remota de código — atualize já

Outubro 21, 2026 0 Por ipdroid

A equipa de segurança do PHP publicou, a 21 de outubro de 2026, um alerta para duas vulnerabilidades críticas que podem permitir a execução remota de código sem autenticação. A atualização para uma versão corrigida é fortemente recomendada para todos os ambientes que utilizam PHP.

A segurança de um website depende não apenas da aplicação instalada, mas também das tecnologias que a suportam. O PHP, utilizado por plataformas como WordPress, WooCommerce e muitas outras aplicações web, recebeu uma atualização de segurança urgente para corrigir duas vulnerabilidades críticas.

De acordo com o comunicado oficial do projeto PHP, estas falhas podem permitir que um atacante execute código remotamente através de pedidos HTTP especialmente concebidos, sem necessitar de autenticação prévia.

Quais são as versões afetadas e corrigidas?

O projeto PHP disponibilizou as seguintes versões com as correções de segurança:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Os administradores de sistemas devem atualizar para a versão corrigida correspondente à sua série PHP, desde que disponibilizada pelo respetivo fornecedor de software.

As instalações com PHP 8.1 ou versões anteriores merecem especial atenção, uma vez que estas versões já não recebem atualizações regulares do projeto PHP. Alguns fornecedores de distribuições Linux e serviços de suporte de longo prazo (LTS) poderão disponibilizar correções retroativas (backports). Quando não existir uma correção suportada, deverá ser planeada a migração para uma versão mantida.

Que vulnerabilidades foram identificadas?

O alerta identifica duas vulnerabilidades distintas, ambas classificadas como críticas pelo impacto potencial.

1. CVE-2026-109618 — Corrupção de memória em situações de falta de recursos

Esta vulnerabilidade está relacionada com o tratamento de situações de falta de memória (Out of Memory, ou OOM).

Em determinadas circunstâncias, o PHP pode interromper o processamento de um pedido quando os dados internos ainda não estão completamente inicializados. Durante a limpeza dos recursos associados ao pedido, o sistema pode interpretar incorretamente esses dados, abrindo caminho a uma possível execução remota de código.

2. CVE-2026-109619 — Utilização de estado interno desatualizado

A segunda vulnerabilidade está relacionada com o estado interno de um pedido que pode permanecer acessível depois de a memória associada ter sido libertada.

Se um processo de trabalho reutilizar esse estado num pedido posterior, antes de a inicialização normal o redefinir, poderá ocorrer uma utilização indevida da memória, com potencial para execução remota de código.

O impacto depende, entre outros fatores, da configuração do servidor e do modo como o PHP processa os pedidos. O projeto PHP destaca o risco particular associado ao módulo mod_php, no qual foi demonstrado um cenário de exploração antes da execução do código da própria aplicação.

Que servidores e aplicações podem estar em risco?

O alerta abrange instalações PHP que processam pedidos web, independentemente da aplicação alojada.

Entre os ambientes identificados encontram-se:

  • PHP-FPM;
  • Apache com mod_php;
  • php-cgi;
  • FrankenPHP;
  • LiteSpeed.

Consequentemente, a utilização de WordPress, WooCommerce, Joomla, PrestaShop ou de uma aplicação desenvolvida à medida não elimina o risco. A vulnerabilidade encontra-se no próprio motor PHP e não exige necessariamente uma falha no código da aplicação.

Importa também distinguir a versão do PHP instalada no sistema da versão efetivamente utilizada pelo website. Em ambientes de alojamento com várias versões disponíveis, cada domínio pode estar configurado para utilizar uma versão diferente.

O que deve fazer para proteger o seu website?

A principal recomendação do projeto PHP é atualizar imediatamente para uma versão corrigida.

1. Identifique a versão PHP utilizada

Verifique a versão efetivamente configurada para o website, através do painel de alojamento ou dos mecanismos de gestão disponíveis no servidor. Não assuma que a versão apresentada na linha de comandos é necessariamente a mesma utilizada pelo website.

2. Atualize para uma versão corrigida

Instale a versão corrigida disponibilizada pelo fornecedor do sistema ou do serviço de alojamento. Em sistemas Linux, confirme se os pacotes atualizados já estão disponíveis e se a correção foi incorporada na versão fornecida.

3. Reinicie os processos quando necessário

Dependendo da arquitetura, poderá ser necessário reiniciar ou recarregar os serviços PHP-FPM, Apache ou LiteSpeed para garantir que os processos passam a utilizar o código corrigido.

4. Confirme todas as versões em utilização

Se o servidor disponibilizar várias versões PHP, confirme que todos os websites e processos relevantes utilizam versões corrigidas. Atualizar apenas uma versão instalada não protege automaticamente os websites que continuam a utilizar outra versão vulnerável.

5. Planeie a atualização de versões antigas

Se ainda utiliza PHP 8.1 ou anterior, verifique junto do fornecedor se existe uma correção retroativa suportada. Na ausência de uma correção adequada, planeie a migração para uma versão PHP suportada, validando previamente a compatibilidade da aplicação.

E se não for possível atualizar imediatamente?

O projeto PHP descreve algumas medidas temporárias que podem reduzir a exposição a determinados cenários de exploração. Entre elas encontram-se ajustes ao tratamento de pedidos, à gestão de sessões e aos limites de recursos.

No entanto, estas medidas não substituem a instalação de uma versão corrigida e não garantem que o sistema fique protegido.

Algumas alterações de configuração podem afetar o funcionamento de websites, uploads de ficheiros e outras funcionalidades. Por esse motivo, devem ser avaliadas por um administrador com conhecimento da arquitetura do servidor e aplicadas apenas quando adequadas ao ambiente em causa.

Desativar a apresentação de erros ou ocultar mensagens de diagnóstico, por si só, não resolve estas vulnerabilidades.

Qual é a responsabilidade do serviço de alojamento e do proprietário do website?

A proteção de um ambiente web envolve diferentes componentes.

O fornecedor de alojamento é responsável pelas operações de infraestrutura e pelas componentes do serviço que se encontram sob a sua administração, de acordo com as condições contratadas. Já o proprietário ou administrador da aplicação deve assegurar a compatibilidade do software instalado, acompanhar as atualizações necessárias e manter os componentes da aplicação devidamente atualizados.

Em ambientes partilhados, geridos ou dedicados, o procedimento concreto pode variar consoante a versão PHP selecionada, o painel de controlo e o nível de administração incluído no serviço.

Se tiver dúvidas sobre a versão PHP utilizada ou sobre o procedimento de atualização, contacte o seu fornecedor de alojamento antes de efetuar alterações que possam afetar o funcionamento do website.

A recomendação da Ipdroid

A gravidade deste alerta justifica uma verificação prioritária dos ambientes PHP em utilização.

Recomendamos que os administradores de websites e servidores identifiquem as versões instaladas, confirmem a disponibilidade das correções junto dos respetivos fornecedores e procedam à atualização com a maior brevidade possível.

Não adie uma atualização crítica de segurança por considerar que o website não apresenta sintomas de ataque. A ausência de erros visíveis não significa que um ambiente esteja protegido.

A manutenção regular do software de base é uma componente essencial da segurança, da disponibilidade e da continuidade dos serviços online.

Precisa de ajuda com o seu alojamento? Contacte a equipa de suporte da Ipdroid através da sua área de cliente para esclarecer dúvidas relacionadas com o ambiente de alojamento e com as componentes do serviço sob a nossa administração.

Fontes oficiais