In short: A website's supply chain stretches from the PHP project through the distribution and host to the CMS, plugins, agency and embedded services. Every link counts for IT security, because a patch only reaches your website once all of them have passed it on. Anyone who writes the chain down, defines a responsible party and a piece of evidence for each link and limits access makes it dependable.
A patch and its long journey
On 21 October 2026 at 14:00 UTC, the PHP project released the fixes for PHP2Shell. That did not close the vulnerability for a single website. First, distributions such as Debian, Ubuntu or the RHEL family had to take the fixes into their packages; according to reports, backports were in some cases delivered the same day. Then hosts and admins had to install these packages and restart all PHP processes. Only after that was the respective website protected.
Every link in this chain can cause delay. And each is run by a different organisation with its own priorities. Anyone who does not know what their chain looks like cannot say where the patch currently is.
Some chains have additional links that hardly anyone knows about. Many Debian and Ubuntu servers obtain PHP not from the distribution but from the repository of Ondřej Surý at sury.org, a widespread third-party source. According to reports, it provided builds for all branches from 5.6 to 8.5. That is helpful, but it is not the Debian security archive: anyone using this source depends on a different link, with its own pace and its own responsibility. Whether a server is set up this way is shown by the list of package sources, and exactly this information belongs in the documentation of the chain.
The links of the supply chain at a glance
The following table shows the typical links of a PHP website and what you can demand of each.
| Link | Typical risk | What you should define |
|---|---|---|
| PHP project | vulnerability in the interpreter, end of support | supported version in use, plan for end of support |
| Distribution or third-party source | backport missing or late | known package source, security alerts subscribed |
| Host or platform service | update without restart, no information | duty to update, restart, provide evidence and notify |
| CMS vendor | vulnerability in the core | update channel, responsible person |
| Plugin and theme vendors | abandoned or insecure extensions | only maintained plugins from official sources |
| Agency or developer | far-reaching access, unclear responsibility | personal accounts, written tasks |
| External scripts and services | third-party code in the browser, data leakage | list, fixed versions, purpose reviewed |
Two examples from the PHP2Shell week show how easily a link is overlooked. Vercel points out that updating the local development environment, the application code or the plugins is not enough; what matters is the PHP runtime that actually serves the site. Coolify advises updating the PHP runtime of each application individually, even behind Cloudflare. And according to reports, WordPress.org plans no update of its own against PHP2Shell, because the vulnerability lies in the interpreter. Anyone waiting for the CMS waits in vain.
Making the chain visible: five steps
This is how to bring order to the dependencies of your websites:
- Write down the chain for each website: from the PHP runtime to external scripts, with the name of the vendor or person.
- Define responsibility for each link: Who installs updates, who checks, who informs whom?
- Agree on evidence: What counts as done? For the PHP runtime, for example, package level and restart, as described in How to ask your host about the patch status.
- Limit access: Every agency and every service provider gets only the rights it needs, with personal accounts.
- Plan fallback routes: What to do if a link fails, for example if a plugin vendor gives up or a service provider cannot be reached?
Ask every service provider how it will inform you about critical vulnerabilities. In a situation like PHP2Shell, anyone who answers only when asked is a risk to your schedule. Record the answer in writing.
Plugins and extensions: the least transparent place
For many websites, the largest part of the supply chain is invisible: plugins and themes that have accumulated over the years. Each comes from a different vendor, with its own pace for security updates. Some vendors abandon their product without announcing it. Other extensions are obtained from unofficial sources and never receive updates.
A simple rule helps here: every plugin needs a purpose, a maintained vendor and an official source. If one of these is missing, it goes on the list for replacement. The same applies to embedded services such as payment providers, booking systems, chat windows or analytics tools. They bring their own code to your page or receive data from your visitors. Keep a record of which services are embedded, who commissioned them and whether they are still needed. A forgotten script from a vendor with whom there has long been no contract is a link without an owner.
How to keep plugins and packages up to date permanently is described in Keeping dependencies up to date: Composer, npm and plugins.
Supply chain, contracts and NIS2
For companies that fall under NIS2, supply chain security explicitly belongs to risk management, including relationships with service providers and vendors. Details are under NIS2 and web server security. But even without a legal obligation, the same holds: outsourced tasks remain your risk. The results of the five steps therefore belong in the contracts with the agency, host and service providers; which points should be regulated there is described in IT service provider contracts: setting security duties clearly. This page is general information and not legal advice.
How does PHP SOS help?
- Together with you, we map the supply chain of each website, from the PHP runtime to external scripts.
- We check plugins, themes and packages for maintenance status and origin and recommend replacements where necessary.
- We agree with the host and agency who is responsible for which links and which evidence is delivered.
- Where a link is unmanned, we take it over permanently through a security maintenance contract.
Conclusion: A website's security is only as strong as the slowest link in its supply chain. Anyone who knows the chain and ties each link to a responsible party and a piece of evidence knows in an emergency where the patch is.
Frequently asked questions
What does supply chain mean for a website?
All parties whose work the security of your website depends on: the PHP project, the Linux distribution, host or platform service, CMS vendor, plugin and theme vendors, the agency and embedded services such as payment providers or external scripts.
Am I responsible if a service provider does not patch?
Responsibility for your own website and the data on it generally stays with you, even if tasks are outsourced. Responsibilities should therefore be clear in the contract and be checked. For the legal assessment, a lawyer and the data protection officer are responsible.
Is it enough if the host updates PHP?
For the PHP runtime at the host, yes, provided it also restarts all processes and can prove it. If parts of your application run elsewhere, for example in containers, on platform services or on a second server, each runtime there must be updated individually.
How do I recognise risky plugins?
Warning signs are a long time without updates, a vendor without a recognisable security contact, sourcing from unofficial places and functions that nobody uses any more. Such plugins should be replaced or removed.