Em resumo: perante uma vulnerabilidade PHP como o PHP2Shell, no alojamento web a atualização do PHP é da responsabilidade do fornecedor, não sua. A sua tarefa é obter uma confirmação por escrito, escolher no menu do cliente uma versão PHP suportada e verificar o seu site em busca de vestígios de um ataque. Um patch do fornecedor não remove software malicioso que tenha chegado antes ao seu site.
A situação em palavras simples
O PHP é a linguagem de programação em que correm a maioria dos sites, lojas e CMS como o WordPress. PHP2Shell designa dois erros críticos no próprio PHP (CVE-2026-109618 e CVE-2026-109619). Através deles, atacantes podem executar código próprio no servidor sem palavra-passe. O BSI (Gabinete Federal Alemão para a Segurança da Informação) declarou o nível de alerta 3 (laranja) e recomenda uma atualização imediata.
No alojamento partilhado, muitos clientes partilham um servidor. A tecnologia de base, ou seja, sistema operativo, servidor web e PHP, é operada pelo fornecedor. Você gere apenas o seu site, a base de dados e os acessos. Por isso não pode instalar a atualização do PHP por si próprio e também não tem de o fazer.
Alojamento web e vulnerabilidade PHP: quem é responsável?
A repartição resulta do seu contrato. Na maioria dos planos, aplica-se aproximadamente a seguinte distribuição:
| Tarefa | Fornecedor | Você como cliente |
|---|---|---|
| Atualizar os pacotes PHP | sim | não |
| Reiniciar os processos PHP | sim | não |
| Definir valores provisórios em todo o servidor | sim | não |
| Escolher a versão PHP do seu site | disponibiliza | escolhe |
| Atualizar CMS, plugins, temas | não | sim |
| Credenciais de acesso e contas de administrador | não | sim |
| Verificar o site quanto a código malicioso | em parte | sim |
| Avaliação em matéria de proteção de dados | não | sim |
A última linha é importante: se no seu site ocorrer um incidente com dados pessoais, em regra a responsabilidade é sua, como operador, e não do fornecedor. Mais sobre isto em Dever de notificação segundo o RGPD.
O que deve fazer agora por si próprio
1. Obter a confirmação. Pergunte por escrito ao seu fornecedor se as versões PHP do seu pacote estão protegidas contra as duas CVE, desde quando, e se todos os processos PHP foram reiniciados. Encontra um modelo pronto em Perguntar ao fornecedor de alojamento o nível de patch. Não estranhe se no menu do cliente continuar a constar um número de versão mais antigo, como 8.2.34: alguns fornecedores entregam as correções como backport, sem que o número mude.
2. Verificar a versão PHP. Veja no menu do cliente que versão PHP o seu site usa. O PHP 8.1 e anteriores já não recebem atualizações oficiais do projeto PHP. O PHP 8.2 chega ao fim do suporte a 31/12/2026. Se o seu CMS suporta uma versão mais recente, verifique-o nos requisitos de sistema do fabricante, por exemplo em wordpress.org.
3. Controlar o site. Esteja atento a contas de administrador desconhecidas, redirecionamentos inesperados, ficheiros estranhos no acesso FTP e avisos no Google Search Console. Uma lista de sinais típicos está em Será que já fui comprometido?.
4. Fazer uma cópia de segurança. Descarregue uma cópia de segurança atual dos ficheiros e da base de dados e guarde-a em separado. Peça além disso ao fornecedor que conserve os registos de acesso do seu pacote a partir de 20/10/2026.
Depois da confirmação do fornecedor, altere por precaução as palavras-passe do menu do cliente, do FTP/SFTP, da base de dados e dos administradores do CMS e ative, sempre que possível, a autenticação de dois fatores.
O que não pode resolver sozinho no alojamento partilhado
As medidas provisórias recomendadas pelo php.net, por exemplo session.upload_progress.enabled=0, só funcionam se forem definidas na configuração do servidor. Segundo o php.net, uma entrada em .user.ini ou através de ini_set() no código não basta. Também os limites de memória ao nível do cgroup e o reinício dos processos PHP estão do lado do fornecedor.
Se o seu fornecedor não responder ou responder de forma evasiva, tem três possibilidades: insistir e fixar um prazo, colocar o site temporariamente em modo de manutenção ou mudar para um fornecedor com uma posição clara. O BSI recomenda retirar temporariamente os servidores web da rede quando uma atualização não for possível de imediato.
Verifique também se o seu plano ainda é atual. Pacotes que correm sem alterações há muitos anos estão por vezes em gerações de servidores mais antigas, com versões PHP mais antigas, que o fornecedor só mantém de forma limitada. Mudar para um plano atual do mesmo fornecedor costuma exigir pouco esforço e traz versões PHP mais recentes. Pergunte por isso se a resposta sobre o nível de patch for insatisfatória.
Se o site já apresentar anomalias
Um patch do fornecedor fecha a vulnerabilidade para o futuro. Não remove, porém, uma porta dos fundos que atacantes tenham instalado antes, e não prova que antes não aconteceu nada. Se encontrar anomalias, não apague ficheiros ao acaso. Preserve primeiro o estado, para que a causa continue a poder ser reconstituída mais tarde.
Como ajuda concretamente a PHP SOS?
- Formulamos consigo o pedido ao fornecedor e avaliamos tecnicamente a sua resposta.
- Verificamos o seu site quanto a webshells, contas estranhas e ficheiros manipulados e, em caso de achado, limpamo-lo através da nossa remoção de malware.
- Em caso de suspeita aguda, assumimos a assistência de emergência para sites comprometidos, com preservação de provas.
- Ajudamos na escolha de uma versão PHP adequada e testamos depois o site.
Perguntas frequentes
Como cliente de alojamento, tenho de atualizar o PHP eu próprio?
Em regra, não, porque no alojamento partilhado o PHP faz parte da plataforma do fornecedor. No entanto, muitas vezes pode escolher a versão PHP no menu do cliente. Se aí constar uma versão sem atualizações oficiais, deve mudar ou perguntar ao fornecedor como a protege.
O meu site está offline. Fui alvo de um ataque?
Não necessariamente. Alguns fornecedores retiraram sites da rede por precaução, para fechar a vulnerabilidade. Pergunte ao fornecedor o motivo e peça que lhe confirme se existem indícios de um ataque ao seu pacote.
Posso definir eu próprio as medidas provisórias no .user.ini?
Para session.upload_progress.enabled, o php.net afirma expressamente que .user.ini e ini_set() não bastam. Esta definição tem de ser feita pelo fornecedor na configuração do servidor.
O que devo ter por escrito do fornecedor?
Uma confirmação de que as versões PHP do seu pacote estão protegidas contra a CVE-2026-109618 e a CVE-2026-109619, desde quando isso é válido e que os processos PHP foram reiniciados. Guarde esta resposta juntamente com a sua documentação.