Em resumo: num servidor gerido, o fornecedor assume uma parte da segurança, tipicamente o sistema operativo, os pacotes PHP e os serviços padrão. A aplicação, os plugins, os acessos e a responsabilidade em matéria de proteção de dados ficam, na maioria dos casos, consigo. Depois do PHP2Shell, deve esclarecer ambas por escrito: o que fez o fornecedor e o que continua a ser da sua responsabilidade?
O que “gerido” significa e o que não significa
O termo não é protegido. Um fornecedor entende por ele talvez apenas a instalação de atualizações do sistema operativo; outro trata também do servidor web, do PHP, da base de dados e das cópias de segurança. Alguns planos incluem monitorização 24 horas por dia, outros apenas um interlocutor em horário comercial.
Precisamente numa situação como o PHP2Shell vê-se quão rigorosa é a descrição do serviço. As duas vulnerabilidades CVE-2026-109618 e CVE-2026-109619 estão no próprio PHP. Se o seu fornecedor mantém o PHP como parte da sua plataforma ou se o PHP conta como “o seu software” consta do contrato. Não parta do princípio de que alguém já está a tratar disso.
Segurança de servidor gerido: repartição típica de tarefas
A tabela seguinte mostra uma distribuição frequente. Não substitui a consulta do seu contrato, mas ajuda a fazer as perguntas certas.
| Área | Geralmente do fornecedor | Geralmente consigo |
|---|---|---|
| Hardware, rede, virtualização | sim | não |
| Atualizações do sistema operativo | sim | não |
| Pacotes PHP da plataforma | muitas vezes | se instalados por si |
| Reinício do PHP-FPM e do servidor web | muitas vezes | em serviços próprios |
| Configuração PHP de todo o servidor | muitas vezes | em pedidos especiais |
| CMS, loja, plugins, código próprio | não | sim |
| Contas de administrador da aplicação | não | sim |
| Cópias de segurança | frequentemente | verificação da recuperação |
| Avaliação e notificação de violações de dados | não | sim |
| Monitorização de ataques | conforme o plano | conforme o plano |
Os campos pouco claros são o verdadeiro risco. Onde teria de escrever “conforme o plano” ou “muitas vezes”, falta uma regra.
Que perguntas deve fazer agora
Envie ao seu fornecedor um pedido curto e objetivo. Peça a resposta em forma escrita, para a poder apresentar mais tarde. Estes pontos devem constar:
- Que versões PHP correm no nosso servidor e estão protegidas contra a CVE-2026-109618 e a CVE-2026-109619?
- Desde quando isso é válido e, depois disso, todos os processos PHP e o servidor web foram reiniciados?
- A correção foi instalada como backport? Em caso afirmativo, que versão do pacote o comprova?
- Houve indícios de tentativas de ataque ou de processos suspeitos no nosso servidor?
- Os registos do servidor web são conservados a partir de 20/10/2026 e como os obtemos?
Encontra um modelo já redigido em Perguntar ao fornecedor de alojamento o nível de patch. O número de versão no menu do cliente não é prova: nos backports mantém-se muitas vezes inalterado, por exemplo em 8.2.34.
Mesmo que o fornecedor tenha aplicado o patch ao PHP, a sua aplicação continua a ter de ser verificada. Um patch não remove software malicioso introduzido antes da atualização e não prova que não aconteceu nada.
O que fica consigo
A sua parte abrange sobretudo a aplicação. Verifique se o CMS, a loja e os plugins estão atualizados, remova as extensões que já não usa e controle a lista de administradores. Esteja atento a ficheiros novos em pastas de upload, a redirecionamentos estranhos e a tarefas agendadas invulgares na aplicação.
A isto junta-se o lado jurídico. Se num incidente dados pessoais chegarem a mãos alheias, em regra o dever de notificação cabe à sua empresa, como responsável pelo tratamento, e não ao fornecedor. Este tem de o informar, como subcontratante, sem demora injustificada. Os princípios explica-os o Dever de notificação segundo o RGPD: 72 horas. Trata-se de informação geral, não de aconselhamento jurídico; o caso concreto deve ser avaliado por encarregados da proteção de dados ou advogados.
Outro ponto é muitas vezes ignorado: o software que você ou a sua agência instalaram no servidor gerido, por exemplo uma versão PHP adicional de uma origem externa, um contentor ou um programa auxiliar, não costuma estar abrangido pela manutenção do fornecedor. Pergunte por isso também se o fornecedor sabe o que corre para além do equipamento padrão. E esclareça quem assume a investigação em caso de suspeita. Muitos fornecedores restauram a plataforma, mas não investigam se, e que, dados foram afetados. É precisamente essa resposta que precisa para avaliar possíveis deveres de notificação.
Melhorar os contratos para o futuro
Aproveite a situação para fixar a repartição de tarefas. Fazem sentido regras sobre atualizações de segurança, incluindo o reinício, sobre a informação em caso de vulnerabilidades críticas, sobre a conservação e a entrega de registos e sobre o apoio em incidentes. Pergunte também se o fornecedor o notifica ativamente ou se tem de perguntar por si próprio.
Um servidor próprio sem assistência é a alternativa, mas transfere todo o trabalho para si. O que isso significa descreve-o Proteger por si próprio o servidor root e o vServer.
Como ajuda concretamente a PHP SOS?
- Lemos a sua descrição do serviço e elaboramos uma matriz de tarefas que torna visíveis as lacunas.
- Formulamos as perguntas técnicas ao seu fornecedor e avaliamos as respostas.
- Verificamos a parte da aplicação que está do seu lado quanto a vestígios e componentes desatualizados.
- O que o fornecedor não cobre, assumimos, se desejar, através de um contrato de manutenção de segurança ou complementamos com monitorização de segurança.
Perguntas frequentes
Num servidor gerido, está tudo automaticamente protegido?
Não. Gerido significa que o fornecedor assume determinadas tarefas definidas em contrato, geralmente o sistema operativo e os serviços padrão. A aplicação, os plugins, os acessos e o software próprio ficam muitas vezes consigo.
Onde consta aquilo de que o meu fornecedor é responsável?
Na descrição do serviço e nas condições contratuais, muitas vezes também num documento sobre a repartição de tarefas. No caso de dados pessoais, acresce o contrato de subcontratação (tratamento de dados por conta de outrem). Se faltar uma regra clara para as atualizações de segurança, pergunte por escrito.
Apesar do servidor gerido, tenho eu próprio de fazer alguma coisa quanto ao PHP2Shell?
Sim. Obtenha uma confirmação de que todas as versões PHP têm patch e de que os processos foram reiniciados. Verifique ainda se a sua aplicação apresenta vestígios e esclareça se existe dever de notificação.
Quem notifica uma violação de dados se o fornecedor foi afetado?
Em regra, quem tem o dever de notificar a autoridade de controlo é o responsável pelo tratamento, ou seja, a sua empresa. O fornecedor, como subcontratante, tem de o informar sem demora injustificada. Peça ao seu encarregado da proteção de dados que avalie o caso concreto.