# Alojamento partilhado: o que faz o fornecedor e o que tem de fazer

> Alojamento web e vulnerabilidade PHP2Shell: o que o fornecedor assume, o que deve verificar e como pedir por escrito a confirmação do nível de patch.

Fonte: https://phpsos.de/pt/server/shared-hosting/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/).

## 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](https://phpsos.de/pt/ratgeber/hoster-patch-status-erfragen/). 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?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/).

**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.

> **Dica:**
> 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](https://phpsos.de/pt/leistungen/malware-entfernung/).
- Em caso de suspeita aguda, assumimos a [assistência de emergência para sites comprometidos](https://phpsos.de/pt/leistungen/website-gehackt-notfallhilfe/), 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.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [php.net: versões suportadas](https://www.php.net/supported-versions.php)
- [BSI (Gabinete Federal Alemão para a Segurança da Informação)](https://www.bsi.bund.de/)
- [Ajuda do Google Search Console](https://support.google.com/webmasters/)