In short: White-label IT security means for your agency: you keep the client relationship, we do the security work in the background. With PHP2Shell this means an inventory of all client sites, prioritisation by risk, a patch and restart per server, and a proof per client that you can pass on.
Why agencies are under particular pressure with PHP2Shell
An agency with many clients rarely looks after a uniform landscape. Some of the sites are on its own servers with Plesk, some at the clients' hosts, a few legacy projects on PHP versions that long ago stopped receiving official updates. Added to this are different systems: WordPress, TYPO3, Shopware, Craft CMS, in-house Laravel developments.
With a vulnerability in PHP itself, all projects are hit at the same time. Clients expect an answer as to whether their site is secure, and the project team is busy with ongoing orders. Many maintenance contracts cover the CMS but not the server beneath it.
Then there are systems that no longer appear on any project list: staging environments on subdomains, campaign sites from completed projects, test installations by developers on their own vServers. They often run on older PHP versions, are not monitored and still bear the name of your agency or your client. For automated scans they are just as visible as the main site.
Which questions your clients are asking now
- Is my website affected, and has it been patched in the meantime?
- Was anything planted before the patch?
- Does the CMS update count as protection? No, a CMS update does not close the PHP vulnerability.
- Do I have to take my website offline? The BSI (German Federal Office for Information Security) recommends it for servers that cannot be updated immediately.
To each of these questions, your agency needs a verifiable answer per client, not a circular email with general statements.
How white-label IT security for agencies works
We work as part of your team but without our own client contact. The division is clear:
| Task | Your agency | PHP SOS |
|---|---|---|
| Client communication and billing | yes | no |
| Inventory of all client sites with PHP status | provides access | creates and maintains it |
| Patch, restart, check per server | approves maintenance window | carries out or coordinates with hosts |
| Check for compromise | receives findings | searches for webshells and anomalies |
| Proof per client | passes it on | creates it neutrally or in your format |
For sites at third-party hosts, we obtain the confirmation of the package version. The displayed version number alone is not enough, because backports can leave it unchanged.
Prioritise servers with Apache and mod_php first, where the PHP team rates the risk highest, then shops and sites with logins, then projects on PHP 8.1 and older. Static legacy projects that nobody needs any more are better switched off than patched.
Several client sites on one server: checking isolation
On agency servers, many client sites often share one machine. If one of them is compromised, the separation decides whether the attacker can also reach the others. What matters are separate system users and PHP-FPM pools per website, clean file permissions and limits such as open_basedir. On Plesk servers these settings can be checked per subscription.
After the patch: restart all pools and workers. Only then are no old PHP processes still running in memory. Logs from 20 October 2026 onward should be retained for every client site.
Client information: what is proven and what is not
The greatest temptation in this situation is a reassuring mass email. Safer is a statement per client that contains only what is proven: which server, which PHP package version, when restarted, whether a check for compromise has taken place and with what result. What is still open is stated as well.
Better to avoid phrasings such as “Your site is secure”. A patch closes the vulnerability but does not prove that nothing happened beforehand. Anyone who separates the two honestly will not be left needing to explain themselves later if a finding does turn up.
Rewriting maintenance contracts after PHP2Shell
Many agency contracts cover updates of the CMS and extensions but say nothing about the server. Use the situation to record for each client who updates PHP, who is responsible for restarts, who decides in an incident and which services are commissioned separately. A data processing agreement with all service providers involved belongs here too. You clarify the contractual design with your legal counsel.
How does PHP SOS help?
- We take over the stocktake of all client sites with PHP version, operating mode, host and responsibility.
- Through our PHP patch service we patch your own servers, restart all workers and document this per client.
- We check prioritised sites for compromise and clean up if there is a finding, until the incident is closed and documented.
- We supply text modules for your client communication, which you adapt and send yourself.
- Afterwards, on request, we take over ongoing security support in the background with a security maintenance contract.
Frequently asked questions
Do you appear towards our clients?
Only if you want us to. In the white-label model we work exclusively in the background, and all communication runs through your agency. We deliver our documentation neutrally or in your format.
Do we need a data processing agreement for this?
If we access systems containing your clients' personal data, a data processing agreement is generally required, often as a sub-processing arrangement. How this fits into your existing contracts is something you clarify with your legal counsel. We provide the necessary information on our activities.
What about client sites whose servers we do not manage at all?
Where client sites are with third-party hosts, we obtain confirmations of patch level and restart in your name or using your templates. Where only FTP or CMS access exists, we check what is possible from there and openly flag what only the host can prove.
Can we also outsource this permanently after PHP2Shell?
Yes. Many tasks recur with every vulnerability: maintaining the inventory, applying patches, documenting restarts, reporting anomalies. This work can be organised as ongoing support in the background.