21 de outubro de 2026 | PHP | Segurança informática
A 21 de outubro de 2026, a equipa de segurança do PHP publicou atualizações para todas as versões do PHP ainda suportadas. Elas corrigem duas vulnerabilidades críticas, que ficaram conhecidas como PHP2Shell. O BSI emitiu um alerta a esse respeito e exige que os sistemas afetados sejam corrigidos sem demora. Quem gere um servidor web com PHP deve agir ainda hoje. Isto aplica-se também a quem gere “apenas” um WordPress, Nextcloud ou Joomla, pois estas aplicações correm em PHP.
Este artigo resume o que aconteceu, que versões do PHP são afetadas, de que versão precisa agora e como verificar em poucos minutos se o seu servidor está protegido.
Conteúdo deste artigo
- O que aconteceu? A cronologia
- As duas vulnerabilidades do PHP numa vista geral
- Quem é afetado?
- Estas versões do PHP são seguras
- Como verificar e atualizar o seu servidor
- PHP 8.1 e anteriores: sem atualização oficial
- Medidas transitórias e a questão “desligar o servidor?”
- Perguntas frequentes
- Apoio da Biricon IT Services
O que aconteceu? A cronologia
A equipa de segurança do PHP anunciou antecipadamente a publicação das correções, para que os fornecedores de alojamento e os administradores tivessem tempo para se preparar. A publicação em si teve lugar a 21 de outubro de 2026. O BSI emitiu o seu alerta (versão 1.1) nesse mesmo dia.
- 20 de outubro de 2026: pré-aviso da equipa de segurança do PHP de que, no dia seguinte, seriam publicadas atualizações de segurança.
- 21 de outubro de 2026, 14:00 UTC (16:00 hora de verão da Europa Central): são publicadas as correções para o PHP 8.5, 8.4, 8.3 e 8.2.
- 21 de outubro de 2026: o BSI alerta para as “vulnerabilidades críticas que ameaçam aplicações web em todo o mundo” e recomenda que se corrija sem demora. Segundo o BSI, grandes fornecedores de alojamento colocaram, em parte, servidores offline a título preventivo.
As duas vulnerabilidades do PHP numa vista geral
Trata-se de duas falhas separadas no núcleo do PHP: CVE-2026-109618 e CVE-2026-109619. Segundo a equipa de segurança do PHP, ambas podem levar a que um atacante consiga executar código no servidor sem iniciar sessão (unauthenticated Remote Code Execution). As vulnerabilidades são classificadas com CVSS v4.0: 9,2 (crítico).
| Característica | Significado |
|---|---|
| Identificadores | CVE-2026-109618 e CVE-2026-109619 |
| Classificação | CVSS v4.0: 9,2 — crítico |
| Impacto | Execução de código no servidor (Remote Code Execution), sem início de sessão |
| Causa 1 | Memória corrompida quando o PHP fica sem memória durante o processamento (Out-of-Memory) |
| Causa 2 | Estado global desatualizado que permanece na memória entre pedidos |
| Particularmente em risco | Apache com mod_php |
Segundo a avaliação do BSI, no momento da publicação não havia ataques confirmados, mas havia indícios não confirmados de tentativas de exploração. Com falhas críticas num software tão difundido, a experiência diz que se deve contar com que os atacantes analisem as correções e preparem ataques automatizados. A janela de tempo para corrigir é, por isso, curta.
Quem é afetado?
É afetado, em princípio, qualquer servidor onde corra PHP, independentemente da forma como o PHP está integrado: PHP-FPM, mod_php no Apache, php-cgi, FrankenPHP ou LiteSpeed. Segundo a equipa de segurança do PHP, o risco é mais elevado com Apache com mod_php.
O BSI menciona expressamente aplicações que se baseiam em PHP e que, por isso, podem ser também afetadas:
- Sistemas de gestão de conteúdos: WordPress, Drupal, TYPO3, Joomla
- Sistemas de lojas: Magento
- Cloud e armazenamento de ficheiros: Nextcloud
- Interfaces de firewall: pfSense, OPNsense
A aplicação em si não precisa de ter falhas para isso. A falha está no PHP, pelo que uma atualização do WordPress, Nextcloud & Co. por si só não ajuda. É necessário atualizar a versão do PHP no servidor. Em firewalls como pfSense e OPNsense, a versão corrigida do PHP chega através da respetiva atualização de firmware do fabricante.
Estas versões do PHP são seguras
As vulnerabilidades estão corrigidas nas versões seguintes. Tudo o que estiver abaixo é considerado vulnerável.
| Ramo do PHP | Mínimo exigido | Nota |
|---|---|---|
| PHP 8.5 | 8.5.12 | ramo atual |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | O suporte termina a 31 de dezembro de 2026 |
| PHP 8.1 e anteriores | sem atualização oficial, ver em baixo | |
Como verificar e atualizar o seu servidor
1. Determinar a versão do PHP instalada
Na linha de comandos do servidor, php -v mostra a versão do PHP de linha de comandos. O servidor web pode usar uma versão do PHP diferente. Verifique, por isso, também a versão do PHP-FPM ou do módulo Apache, por exemplo com php-fpm8.3 -v ou através de uma página que apresente phpinfo() (removendo-a logo a seguir).
2. Aplicar a atualização através da gestão de pacotes
No Debian, Ubuntu, RHEL e derivados, a versão corrigida chega através da gestão de pacotes normal, por exemplo apt update && apt upgrade ou dnf upgrade. Com fontes externas como o Sury-PPA ou o repositório Remi, os novos pacotes surgem normalmente em pouco tempo.
apt changelog php8.3-fpm ou rpm -q --changelog php | grep CVE-2026-1096).
3. Reiniciar o serviço PHP
Uma atualização de pacote, por si só, não basta: os processos PHP em execução mantêm o código antigo na memória. Reinicie o PHP-FPM (systemctl restart php8.3-fpm) ou o Apache (systemctl restart apache2) e verifique depois se os processos foram iniciados após a atualização.
4. Sítios web alojados
Em alojamento partilhado, quem atualiza é, em regra, o fornecedor. No menu do cliente é normalmente possível definir a versão do PHP por sítio web. Escolha aí uma das versões seguras acima indicadas, ou pergunte ao fornecedor pelo estado das correções. Segundo o BSI, alguns fornecedores retiraram servidores da rede a título preventivo. Se o seu sítio ficar brevemente inacessível, essa pode ser a causa.
PHP 8.1 e anteriores: sem atualização oficial
Para o PHP 8.1 e anteriores já não existem atualizações de segurança oficiais. Os operadores destes sistemas têm duas possibilidades:
- Mudar para uma versão suportada (recomendado). Quanto mais antiga a versão, maior o esforço de adaptação da aplicação e das extensões, pelo que uma mudança deve ser testada previamente.
- Fazer o backport das correções. A equipa de segurança do PHP disponibilizou as correções em ramos de desenvolvimento no GitHub. Quem compila o PHP por si mesmo pode transpor essas alterações para versões mais antigas. Trata-se de uma solução transitória e exige conhecimentos especializados.
Também o PHP 8.2 só é suportado até 31 de dezembro de 2026. Planeie por isso desde já a migração para o PHP 8.4 ou 8.5 e não a adie para a passagem de ano.
Medidas transitórias e a questão “desligar o servidor?”
Com o anúncio, a equipa de segurança do PHP descreveu também medidas de proteção provisórias. Estas reduzem o risco, mas não fecham totalmente as falhas. Não substituem a atualização e destinam-se apenas a cobrir o tempo até à atualização.
Se um servidor deve ser retirado da rede até à atualização depende da sua importância e da sua acessibilidade. O BSI refere que grandes fornecedores deram este passo. Como regra prática:
- Servidor acessível publicamente, atualização possível agora: corrigir de imediato, sem necessidade de desligar.
- Servidor acessível publicamente, atualização não possível a curto prazo: restringir o acesso (por exemplo, por firewall, apenas para endereços conhecidos) ou desligar temporariamente o serviço, especialmente com
mod_php. - Servidor apenas acessível internamente: corrigir em breve; a urgência é menor.
Perguntas frequentes
Tenho de atualizar o WordPress, o Joomla ou o Nextcloud?
Não por causa desta vulnerabilidade. Ela reside no PHP, não na aplicação. Atualize a versão do PHP no servidor. Uma atualização da aplicação continua, independentemente disso, a ser aconselhável.
Como sei se alguém já explorou a vulnerabilidade?
É difícil dar uma resposta segura. São sinais de alerta ficheiros PHP desconhecidos no diretório web, processos invulgares sob o utilizador do servidor web, novas contas de utilizador ou tarefas cron e tráfego de saída invulgar. Em caso de suspeita concreta, o sistema deve ser analisado do ponto de vista forense e, em caso de dúvida, reinstalado de raiz.
Basta uma Web Application Firewall?
Uma firewall consegue intercetar padrões de ataque conhecidos, mas não substitui a atualização. Pode ler mais sobre a articulação de várias camadas de proteção no nosso artigo Proteger o Odoo 19: firewall, 2FA & Web RBL. Os princípios aplicam-se a qualquer aplicação web.
O Odoo é afetado?
Não. O Odoo está escrito em Python e não corre em PHP. Só seriam afetadas aplicações PHP que corram no mesmo servidor.
Onde encontro as informações oficiais?
O anúncio da equipa de segurança do PHP encontra-o nos arquivos de notícias em php.net (entrada de 20 de outubro de 2026), e as versões em php.net/downloads. O aviso do BSI tem o número 2026-297981-1032 e foi publicado em bsi.bund.de .
Apoio da Biricon IT Services
Se não tem a certeza de qual a versão do PHP que corre no seu servidor, ou precisa de ajuda com a aplicação de correções, teremos todo o gosto em apoiá-lo: no levantamento de todos os sistemas PHP, na instalação das atualizações, na migração para uma versão do PHP suportada e na verificação de comprometimento. Como prestador de serviços de TI, damos assistência a servidores, firewalls e aplicações web de pequenas e médias empresas.
Situação em: 21 de outubro de 2026. O cenário pode mudar a curto prazo; são determinantes as publicações da equipa de segurança do PHP e do BSI.