Em resumo: O que fazer como cliente de alojamento perante a vulnerabilidade PHP2Shell? Na maioria dos casos, não tem de aplicar a atualização do PHP você próprio; no alojamento partilhado, é o fornecedor que o faz. As suas tarefas são outras: obter uma confirmação por escrito do nível de patch, escolher no menu de cliente uma versão do PHP suportada e verificar se o seu site apresenta anomalias. Este artigo responde às 15 perguntas mais frequentes, de forma breve e por ordem.
Vulnerabilidade PHP como cliente de alojamento: estou afetado, o que fazer?
Desde 21 de outubro de 2026 recebemos muitas perguntas de empresas cujo site está num fornecedor de alojamento. A maioria gira em torno dos mesmos pontos. Quem quiser ler as responsabilidades com mais pormenor encontra-as em Alojamento partilhado: o que o fornecedor faz e o que tem de fazer.
1. O meu site está sequer afetado?
Se o seu site corre com WordPress, Shopware, TYPO3, Joomla, Contao ou outro sistema PHP, o servidor que está por baixo pode estar afetado. Páginas HTML puras sem PHP não estão. Em caso de dúvida, ajuda uma olhadela ao menu de cliente: se aí houver uma definição para a versão do PHP, usa PHP.
2. Qual é a diferença entre alojamento partilhado e servidor próprio?
No alojamento partilhado, partilha um servidor operado pelo fornecedor com outros clientes; o fornecedor trata do PHP. Num servidor root ou vServer próprio, a responsabilidade é sua. Num servidor gerido, o contrato regula quem aplica as atualizações.
3. O meu fornecedor enviou um e-mail circular. Ainda tenho de fazer alguma coisa?
Leia com atenção o que lá está. Um e-mail circular confirma muitas vezes apenas que o fornecedor “está a trabalhar no assunto”. Precisa de uma declaração sobre o seu pacote: ramo do PHP, nível de patch, data e reinício.
Responsabilidade e atualização
4. O fornecedor aplica a atualização automaticamente?
Em regra, sim, para as versões do PHP que oferece nos seus servidores. Se isso já aconteceu e se também as versões mais antigas estão cobertas varia de fornecedor para fornecedor. Pergunte.
5. O meu menu de cliente mostra um número de versão antigo. Estou desprotegido?
Não necessariamente. Muitos fornecedores incorporam correções como backport, e o número mantém-se igual. O Plesk, por exemplo, pode continuar a mostrar 8.2.34 apesar de o erro estar corrigido. Vale a confirmação do fornecedor.
6. Ainda uso o PHP 7.4 ou 8.1. E agora?
Estes ramos já não recebem atualizações oficiais do projeto PHP. Alguns fornecedores entregam correções próprias, outros não. Esclareça-o por escrito e planeie a mudança para um ramo suportado. Verifique antes, nos requisitos de sistema do seu CMS, que versões do PHP este suporta.
7. Posso mudar eu próprio a versão do PHP?
Na maioria dos fornecedores, sim, no menu de cliente. Como se faz e a que deve atender antes é descrito no artigo Alterar a versão do PHP na área de cliente do alojamento. Faça antes uma cópia de segurança.
8. Ajuda atualizar o WordPress ou os plugins?
Contra o PHP2Shell, não, porque a vulnerabilidade está no PHP. As atualizações do CMS fazem, ainda assim, sentido porque fecham outras vulnerabilidades.
Verificar e comprovar
9. Como obtenho um comprovativo do fornecedor?
Com um pedido por escrito que exija dados concretos: estado dos pacotes por ramo do PHP, data de instalação, reinício de todos os processos PHP. Um modelo para copiar é oferecido pelo guia Pedir confirmação da atualização PHP ao fornecedor de alojamento.
10. Posso aplicar medidas provisórias através do .user.ini?
Não. O php.net desaconselha expressamente aplicar as definições provisórias através de ini_set() ou .user.ini. Pertencem à configuração do servidor, e esta, no alojamento partilhado, é gerida pelo fornecedor.
11. O meu site esteve brevemente offline. Fui pirateado?
Não necessariamente. Alguns fornecedores desligaram sites por precaução ou reiniciaram servidores. Pergunte o motivo antes de tirar conclusões.
12. Como reconheço que o meu site foi atacado?
Possíveis indícios são contas de administrador desconhecidas, novos ficheiros PHP na pasta de uploads, redirecionamentos para sites de terceiros, páginas estranhas no índice do Google ou avisos na Search Console. Peça ao fornecedor que conserve os registos de acesso desde 20 de outubro.
Quando algo não está certo
13. O fornecedor não responde ou responde de forma evasiva. O que fazer?
Pergunte por escrito e fixe um prazo razoável. Se a resposta não vier, deve tratar o servidor como não verificado e ponderar mudar temporariamente o site para uma página de emergência estática.
14. Devo mudar de fornecedor de alojamento?
Uma mudança a meio da situação cria riscos próprios. Faz sentido se o fornecedor não prestar esclarecimentos de forma duradoura ou continuar a operar versões antigas do PHP sem correção. O que observar nesse caso é descrito em Mudar de fornecedor de alojamento após um incidente.
15. Tenho de comunicar alguma coisa?
Se houver indícios de um ataque e dados pessoais puderem estar em causa, pode existir uma obrigação de notificação ao abrigo do RGPD, em regra no prazo de 72 horas. Esclareça-o com o seu encarregado da proteção de dados ou um advogado. Isto não é aconselhamento jurídico.
A sua lista de verificação rápida
- Perguntar por escrito ao fornecedor pelo nível de patch e pelo reinício.
- Verificar a versão do PHP no menu de cliente, substituir ramos obsoletos.
- Rever as contas de administrador e a pasta de uploads.
- Verificar se há avisos na Search Console.
- Em caso de anomalias, pedir ajuda antes de apagar ficheiros.
Como ajuda concretamente a PHP SOS?
- Esclarecimento com o fornecedor: Formulamos o pedido ou conduzimos a conversa e avaliamos a resposta.
- Verificação do site: Procuramos vestígios em ficheiros, base de dados e contas, na medida em que o pacote de alojamento o permitir.
- Limpeza: Se encontrarmos código malicioso, removemo-lo e mudamos todos os acessos.
- Documentação: Recebe o estado por escrito.
Perante uma suspeita concreta, ajuda a ajuda de emergência para sites pirateados.
Conclusão
Como cliente de alojamento, no PHP2Shell não carrega o peso da atualização, mas tem a responsabilidade pelo seu site. A maioria das perguntas resolve-se com uma resposta clara e por escrito do seu fornecedor. O que fica depois é olhar para o próprio site: contas, ficheiros, avisos da Google. Quem fez as duas coisas cumpriu a sua parte e pode, em caso de dúvida, comprovar que agiu com diligência.
Perguntas frequentes
Quem é responsável pela atualização do PHP no alojamento web?
No alojamento partilhado, em regra o fornecedor, porque é ele que opera o servidor e a instalação do PHP. Você é responsável pelo seu site, pelos seus acessos e pela escolha da versão do PHP no menu de cliente. Nos servidores geridos, o contrato regula a divisão.
Porque é que o meu fornecedor de alojamento mostra uma versão antiga do PHP?
Muitos fornecedores e distribuições incorporam a correção como backport na versão existente. O número mantém-se igual, apesar de a vulnerabilidade estar fechada. Por isso, confie numa confirmação por escrito do fornecedor e não no que é apresentado.
O que posso verificar eu próprio como cliente de alojamento?
Pode controlar a versão do PHP definida no menu de cliente, rever as contas de administrador do seu CMS, procurar ficheiros desconhecidos na pasta de uploads e verificar se há avisos na Search Console. O nível de patch do próprio servidor só o fornecedor o pode comprovar.
Ajuda uma definição de firewall no pacote de alojamento?
As regras de firewall do fornecedor ou de um serviço intermédio podem reduzir o risco. Não substituem, porém, a atualização do PHP no servidor. Por isso, pergunte sempre primeiro pela atualização.