Em resumo: segurança informática white-label significa, para a sua agência: mantém a relação com o cliente, nós tratamos do trabalho de segurança nos bastidores. No PHP2Shell, isso significa o inventário de todos os sites de clientes, a priorização por risco, o patch e o reinício por servidor e um comprovativo por cliente que pode transmitir.
Por que razão as agências estão sob especial pressão com o PHP2Shell
Uma agência com muitos clientes raramente gere um panorama uniforme. Parte dos sites está em servidores próprios com Plesk, parte nos fornecedores de alojamento dos clientes, alguns projetos antigos em versões do PHP que já não recebem atualizações oficiais. Acrescem sistemas diferentes: WordPress, TYPO3, Shopware, Craft CMS, desenvolvimentos próprios em Laravel.
Perante uma vulnerabilidade no próprio PHP, todos os projetos são atingidos em simultâneo. Os clientes esperam uma resposta sobre se o seu site está seguro, e a equipa de projeto está sobrecarregada com encomendas em curso. Muitos contratos de manutenção regulam o CMS, mas não o servidor por baixo.
Juntam-se sistemas que já não aparecem em nenhuma lista de projetos: ambientes de staging em subdomínios, sites de campanhas de projetos concluídos, instalações de teste de programadores em vServers próprios. Correm muitas vezes em versões mais antigas do PHP, não são vigiados e, ainda assim, levam o nome da sua agência ou do seu cliente. Para as varreduras automatizadas, são tão visíveis como o site principal.
Que perguntas os seus clientes fazem agora
- O meu site está afetado e entretanto já tem o patch aplicado?
- Foi introduzido algo antes do patch?
- A atualização do CMS conta como proteção? Não, uma atualização do CMS não fecha a vulnerabilidade do PHP.
- Tenho de desligar o meu site da rede? O BSI recomenda-o para servidores que não podem ser atualizados de imediato.
A cada uma destas perguntas, a sua agência precisa de uma resposta comprovável por cliente, e não de uma circular com afirmações gerais.
Como decorre a segurança informática white-label para agências
Trabalhamos como parte da sua equipa, mas sem contacto próprio com os clientes. A repartição é clara:
| Tarefa | A sua agência | PHP SOS |
|---|---|---|
| Comunicação com o cliente e faturação | sim | não |
| Inventário de todos os sites de clientes com o estado do PHP | fornece acessos | cria e mantém |
| Patch, reinício e verificação por servidor | autoriza a janela de manutenção | executa ou coordena com fornecedores de alojamento |
| Verificação de comprometimento | recebe o resultado | procura webshells e anomalias |
| Comprovativo por cliente | transmite | elabora em formato neutro ou no seu formato |
No caso de sites em fornecedores de alojamento alheios, obtemos a confirmação do estado do pacote. O número de versão apresentado, por si só, não basta, porque os backports podem deixá-lo inalterado.
Priorize primeiro os servidores com Apache e mod_php, onde a equipa do PHP classifica o risco como o mais elevado, depois lojas e sites com início de sessão e, a seguir, projetos em PHP 8.1 e anterior. Projetos estáticos antigos de que ninguém precisa mais é melhor desligá-los do que aplicar-lhes patches.
Vários sites de clientes num servidor: verificar o isolamento
Nos servidores de agências, muitos sites de clientes partilham muitas vezes uma máquina. Se um deles for comprometido, a separação decide se o atacante chega também aos outros. São importantes utilizadores de sistema próprios e pools PHP-FPM por site, permissões de ficheiros corretas e limites como o open_basedir. Nos servidores Plesk, estas definições podem ser verificadas por subscrição.
Depois do patch, vale: reiniciar todos os pools e workers. Só então deixam de correr processos PHP antigos na memória. Os registos desde 20/10/2026 devem ser conservados para cada site de cliente.
Informação aos clientes: o que está comprovado e o que não está
A maior tentação nesta situação é uma circular tranquilizadora. Mais seguro é uma declaração por cliente que contenha apenas o que está comprovado: que servidor, que estado do pacote PHP, quando foi reiniciado, se foi feita uma verificação de comprometimento e com que resultado. O que ainda está em aberto também consta dela.
Formulações como “O seu site está seguro” é melhor evitá-las. Um patch fecha a vulnerabilidade, mas não prova que nada aconteceu antes. Quem separa isto com honestidade não fica depois obrigado a dar explicações, caso afinal surja um achado.
Reformular os contratos de manutenção depois do PHP2Shell
Muitos contratos de agências regulam atualizações do CMS e das extensões, mas calam-se sobre o servidor. Aproveite a situação para registar, para cada cliente, quem atualiza o PHP, quem é responsável pelos reinícios, quem decide num incidente e que serviços são contratados à parte. Faz também parte um acordo de subcontratação do tratamento de dados com todos os prestadores envolvidos. A configuração contratual esclareça-a com o seu aconselhamento jurídico.
Como ajuda concretamente a PHP SOS?
- Assumimos o levantamento de todos os sites de clientes com versão do PHP, modo de operação, fornecedor de alojamento e responsabilidade.
- Através do nosso serviço de patches PHP, aplicamos patches aos seus servidores, reiniciamos todos os workers e comprovamo-lo por cliente.
- Verificamos os sites priorizados quanto a comprometimento e, havendo achados, limpamos até o incidente estar concluído e documentado.
- Fornecemos blocos de texto para a sua informação aos clientes, que pode adaptar e enviar por si.
- Depois, se desejar, assumimos com um contrato de manutenção de segurança o acompanhamento contínuo da segurança nos bastidores.
Perguntas frequentes
Apresentam-se perante os nossos clientes?
Só se o desejar. No modelo white-label trabalhamos exclusivamente nos bastidores, e toda a comunicação passa pela sua agência. A nossa documentação entregamo-la em formato neutro ou no seu formato.
Precisamos para isso de um contrato de subcontratação do tratamento de dados?
Se acedermos a sistemas com dados pessoais dos seus clientes, é em regra necessário um acordo de subcontratação do tratamento de dados, muitas vezes como subcontratação ulterior. Como se encaixa nos seus contratos existentes, esclareça-o com o seu aconselhamento jurídico. Fornecemos as indicações necessárias sobre as nossas atividades.
E os sites de clientes cujo servidor nem sequer gerimos?
Se os sites de clientes estiverem em fornecedores de alojamento alheios, obtemos, em seu nome ou com os seus modelos, confirmações sobre o nível de patch e o reinício. Onde só existe acesso por FTP ou ao CMS, verificamos o que é possível a partir daí e indicamos abertamente o que só o fornecedor de alojamento pode comprovar.
Podemos subcontratar isto de forma permanente também depois do PHP2Shell?
Sim. Muitas tarefas repetem-se a cada vulnerabilidade: manter o inventário, instalar patches, comprovar reinícios, comunicar anomalias. Este trabalho pode ser organizado como acompanhamento contínuo nos bastidores.