Em resumo: a cadeia de fornecimento de um site vai do projeto PHP, passando pela distribuição e pelo fornecedor de alojamento, até ao CMS, plugins, agência e serviços integrados. Para a segurança informática, conta cada elo, pois um patch só chega ao seu site quando todos o passaram adiante. Quem regista a cadeia por escrito, define para cada elo um responsável e um comprovativo e limita os acessos torna-a fiável.
Um patch e a sua longa viagem
A 21/10/2026, às 14:00 UTC, o projeto PHP publicou as correções para o PHP2Shell. Com isso, a vulnerabilidade não ficou fechada em nenhum site. Primeiro, distribuições como o Debian, o Ubuntu ou a família RHEL tiveram de incorporar as correções nos seus pacotes; segundo relatórios, os backports foram em parte entregues no mesmo dia. Depois, os fornecedores de alojamento e os administradores tiveram de instalar esses pacotes e reiniciar todos os processos PHP. Só então o respetivo site ficou protegido.
Cada elo desta cadeia pode atrasar. E de cada um depende uma organização diferente, com prioridades próprias. Quem não sabe como é a sua cadeia não pode dizer onde está o patch neste momento.
Algumas cadeias têm elos adicionais que quase ninguém conhece. Muitos servidores Debian e Ubuntu obtêm o PHP não da distribuição, mas do repositório de Ondřej Surý em sury.org, uma fonte de terceiros muito difundida. Segundo relatórios, disponibilizou compilações para todos os ramos de 5.6 a 8.5. Isso é útil, mas não é o arquivo de segurança do Debian: quem usa esta fonte depende de outro elo, com ritmo próprio e responsabilidade própria. Se um servidor está assim configurado, mostra-o a lista de fontes de pacotes, e é precisamente essa informação que pertence à documentação da cadeia.
Os elos da cadeia de fornecimento em síntese
A tabela seguinte mostra os elos típicos de um site PHP e o que pode exigir de cada um.
| Elo | Risco típico | O que deve definir |
|---|---|---|
| Projeto PHP | vulnerabilidade no interpretador, fim do suporte | versão suportada em uso, plano para o fim do suporte |
| Distribuição ou fonte de terceiros | backport em falta ou tardio | fonte de pacotes conhecida, alertas de segurança subscritos |
| Fornecedor de alojamento ou serviço de plataforma | atualização sem reinício, sem informação | obrigação de atualizar, reiniciar, comprovar e notificar |
| Fabricante do CMS | vulnerabilidade no núcleo | canal de atualização, pessoa responsável |
| Fornecedor de plugins e temas | extensões abandonadas ou inseguras | apenas plugins mantidos, de fontes oficiais |
| Agência ou programador | acessos amplos, responsabilidade pouco clara | acessos pessoais, tarefas por escrito |
| Scripts e serviços externos | código alheio no navegador, fuga de dados | lista, versões fixas, finalidade verificada |
Dois exemplos da semana do PHP2Shell mostram com que facilidade um elo passa despercebido. A Vercel salienta que não basta atualizar o ambiente de desenvolvimento local, o código da aplicação ou os plugins; o decisivo é o ambiente de execução PHP que efetivamente serve as páginas. A Coolify aconselha a atualizar individualmente o ambiente de execução PHP de cada aplicação, mesmo atrás da Cloudflare. E, segundo relatórios, o WordPress.org não planeia uma atualização própria contra o PHP2Shell, porque a vulnerabilidade está no interpretador. Quem espera pelo CMS espera em vão.
Tornar a cadeia visível: cinco passos
Eis como pôr ordem nas dependências dos seus sites:
- Escrever a cadeia de cada site: do ambiente de execução PHP aos scripts externos, com o nome do fornecedor ou da pessoa.
- Definir a responsabilidade de cada elo: quem instala as atualizações, quem verifica, quem informa quem?
- Acordar comprovativos: o que se considera concluído? No ambiente de execução PHP, por exemplo, o estado do pacote e o reinício, como descrito em Como perguntar ao seu fornecedor de alojamento pelo estado dos patches.
- Limitar os acessos: cada agência e cada prestador de serviços recebe apenas os direitos de que precisa, com contas pessoais.
- Planear alternativas: o que fazer se um elo falhar, por exemplo se um fornecedor de plugins desistir ou um prestador de serviços não for contactável?
Pergunte a cada prestador de serviços como o informa sobre vulnerabilidades críticas. Quem só responde quando lhe perguntam é, numa situação como o PHP2Shell, um risco para o seu calendário. Registe a resposta por escrito.
Plugins e extensões: o ponto menos transparente
Em muitos sites, a maior parte da cadeia de fornecimento é invisível: plugins e temas acrescentados ao longo dos anos. Cada um vem de um fornecedor diferente, com o seu próprio ritmo nas atualizações de segurança. Alguns fornecedores abandonam o produto sem o anunciar. Outras extensões são obtidas de fontes não oficiais e nunca recebem atualizações.
Aqui ajuda uma regra simples: cada plugin precisa de uma finalidade, de um fornecedor que o mantenha e de uma fonte de obtenção oficial. Se faltar um destes, vai para a lista de substituição. O mesmo vale para serviços integrados como fornecedores de pagamento, sistemas de reservas, janelas de chat ou ferramentas de análise. Trazem código próprio para a sua página ou recebem dados dos seus visitantes. Registe que serviços estão integrados, quem os encomendou e se ainda são necessários. Um script esquecido de um fornecedor com quem há muito já não existe contrato é um elo sem responsável.
Como manter plugins e pacotes atualizados de forma duradoura, descreve-o Manter as dependências atualizadas: Composer, npm e plugins.
Cadeia de fornecimento, contratos e NIS2
Para as empresas abrangidas pela NIS2, a segurança da cadeia de fornecimento faz expressamente parte da gestão de risco, portanto também as relações com prestadores de serviços e fornecedores. Os pormenores estão em NIS2 e segurança de servidores web. Mas, mesmo sem obrigação legal, vale: as tarefas externalizadas continuam a ser o seu risco. Por isso, os resultados dos cinco passos pertencem aos contratos com a agência, o fornecedor de alojamento e os prestadores de serviços; que pontos devem ali ser regulados, descreve-o Contratos com prestadores de serviços de TI: regular claramente as obrigações de segurança. Esta página é informação geral e não constitui aconselhamento jurídico.
Como ajuda concretamente a PHP SOS?
- Desenhamos consigo a cadeia de fornecimento de cada site, do ambiente de execução PHP aos scripts externos.
- Verificamos plugins, temas e pacotes quanto ao estado de manutenção e à origem e recomendamos a substituição onde for necessário.
- Acordamos com o fornecedor de alojamento e a agência quem responde por que elos e que comprovativos são entregues.
- Onde um elo está por ocupar, assumimo-lo de forma permanente através de um contrato de manutenção de segurança.
Conclusão: a segurança de um site é tão forte quanto o elo mais lento da sua cadeia de fornecimento. Quem conhece a cadeia e liga cada elo a um responsável e a um comprovativo sabe, numa emergência, onde está o patch.
Perguntas frequentes
O que significa cadeia de fornecimento num site?
Todos os intervenientes de cujo trabalho depende a segurança do seu site: o projeto PHP, a distribuição Linux, o fornecedor de alojamento ou serviço de plataforma, o fabricante do CMS, os fornecedores de plugins e temas, a agência e os serviços integrados, como fornecedores de pagamento ou scripts externos.
Sou responsável se um prestador de serviços não aplicar patches?
A responsabilidade pelo seu próprio site e pelos dados nele contidos permanece, em regra, consigo, mesmo quando as tarefas são externalizadas. Por isso, as responsabilidades devem estar claras em contrato e ser verificadas. Para a avaliação jurídica são competentes o advogado e o encarregado da proteção de dados.
Basta que o fornecedor de alojamento atualize o PHP?
Para o ambiente de execução PHP no fornecedor, sim, desde que ele também reinicie todos os processos e o comprove. Se partes da sua aplicação correm noutro lugar, por exemplo em contentores, em serviços de plataforma ou num segundo servidor, cada ambiente de execução tem de ser atualizado individualmente.
Como reconheço plugins arriscados?
Sinais de alerta são longos períodos sem atualizações, um fornecedor sem contacto de segurança visível, obtenção a partir de fontes não oficiais e funções que já ninguém usa. Tais plugins devem ser substituídos ou removidos.