# A cadeia de fornecimento na web: agência, alojamento, fornecedores de plugins

> O seu site depende do projeto PHP, da distribuição, do alojamento, da agência e dos fornecedores de plugins. Torne esta cadeia visível e fiável.

Fonte: https://phpsos.de/pt/blog/lieferkette-agentur-hoster/  
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:** 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:

1. **Escrever a cadeia de cada site:** do ambiente de execução PHP aos scripts externos, com o nome do fornecedor ou da pessoa.
2. **Definir a responsabilidade de cada elo:** quem instala as atualizações, quem verifica, quem informa quem?
3. **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](https://phpsos.de/pt/ratgeber/hoster-patch-status-erfragen/).
4. **Limitar os acessos:** cada agência e cada prestador de serviços recebe apenas os direitos de que precisa, com contas pessoais.
5. **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?

> **Dica:**
> 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](https://phpsos.de/pt/blog/abhaengigkeiten-aktuell-halten/).

## 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](https://phpsos.de/pt/compliance/nis2/). 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](https://phpsos.de/pt/blog/dienstleistervertrag-sicherheit/). 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](https://phpsos.de/pt/leistungen/security-wartungsvertrag/).

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

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [Vercel: PHP2Shell Security Bulletin](https://vercel.com/kb/bulletin/php2shell-security-bulletin)
- [Coolify: PHP Security Advisory](https://coolify.io/docs/knowledge-base/php-security-advisory-2026)
- [BSI](https://www.bsi.bund.de/)