In short: If several client sites of your agency are affected, that is rarely a coincidence, but usually a shared server, shared access or the same PHP version. If you are affected, get in touch immediately. We give you an overview, contain the incident remotely, clean up the systems and deliver reports for your clients.
Do not delete anything and do not rebuild anything right now. Even if the pressure from clients is great: without secured logs and files, neither the cause can be clarified nor can it be proven what was not affected. Report an emergency and we take over from the first message.
Are You Affected? Signs That Client Sites Were Hacked
As an agency you see patterns that individual operators never notice. Signs of a shared incident include:
- Several client sites show the same symptoms at the same time: redirects, spam content, browser warnings.
- The same unknown admin account or the same suspicious file turns up at different clients.
- The host reports abuse or unusual load for an account that holds many projects.
- Clients call because their site is being flagged by Google, and on cross-checking you find further sites in the same state.
- A developer or former employee had access to many projects, and a credential has leaked.
- Maintenance work through a central tool, such as deployment, backups or an update service, has changed a site that you have not touched.
- You run many sites on PHP versions whose patch status you cannot prove for each one individually.
Since PHP2Shell, the vulnerability is in the PHP interpreter itself. A CMS update, for example for WordPress, does not close it; what matters is the PHP runtime that actually serves the sites.
What to Do Right Now
- List the affected sites: Domain, server, hosting account, PHP version, CMS, people responsible. Suspected cases belong on the list too.
- Look for commonalities: The same server? The same access? The same plugin? The same deployment route?
- Isolate endangered sites: Put sites that are actively delivering malicious code into maintenance mode. Do not delete.
- Have logs and state secured: Ask the host to keep logs; secure your own deployment logs.
- Check central access: Who has access to hosting panel, SSH, Git, password manager and deployment? Changes only after consultation.
- Inform clients with restraint: At first only what is proven. Name no cause before it is established.
- Contact us: Call us or write to us on WhatsApp.
How Does PHP SOS Help?
- Assess the situation: With you we get an overview of all sites and servers and sort them by urgency: actively delivered malicious code, suspected data leakage, probably just unpatched.
- Secure and close: We secure every affected system before anything is changed, and close the shared entry point: access, PHP version, restart of all processes.
- Check and clean up: We systematically search all sites for the same traces, remove webshells and backdoors and restore cleanly. Details under Having malware and webshells removed.
- Harden and report: We separate sites from one another where it makes sense, and deliver a short report per client that you can pass on, plus an overall report for you.
We work remotely, with no travel, across Germany and Europe. On request in the background for your agency, as described on the page Agencies and white label.
Why Many Sites Often Fall at the Same Time at Agencies
Anyone who runs many projects on one server saves costs, but trades isolation for convenience. If everything runs under the same user and the same PHP process pool, code from one hacked site can read and change the neighbors' files. That is not an exotic case but the standard in many configurations. How to separate pools cleanly is described in Isolating PHP-FPM pools.
On top of that come shared credentials: one SSH key for all projects, one hosting account with all domains, the same passwords for staging and production. The principle of least privilege applies here. More on this in Permissions of the web server user.
The supply chain counts too: plugins, themes and libraries come from third parties, the host is responsible for the platform, the agency for operations. Where these boundaries run and where gaps arise is covered in Supply chain: agency and host.
Inventory, PHP Versions and Communication With Clients
The most common problem in such situations is a lack of overview: which site runs on which server with which PHP version, and who is responsible? Without this list it is impossible to say who is affected by the patch and who is not. How to build such a directory is shown in Inventory of websites and servers. If several PHP versions run in parallel, Several PHP versions on one server also helps.
Toward clients, clarity counts. You do not have to know everything, but you must not gloss over anything: what is proven, what is still being checked, what will you do next? You will find wording help under Informing customers after an incident. If personal data is affected, reporting duties under Art. 33 GDPR may play a role. This is general information; the assessment belongs with the data protection officer and a lawyer. If the incident grows beyond individual sites, we move into structured incident response.
What You Should Send Us
- a list of the affected and the probably affected domains
- details of server and hosting per project, as far as known
- PHP versions and the CMS or shops in use
- the access you can grant us, and the roles in the team
- notes on what was last changed or rolled out
- the name of the contact person for decisions and for client communication
Why PHP SOS
We work Made in Germany and, together with our partner network of cyber professionals, have specialized in IT security for over 25 years. You have one contact for all affected projects, we work remotely and document per system what was found and done. We promise no miracles. What cannot be proven, we call unknown, so that you do not tell your clients more than you know.
Affected? Call Us. We Help.
If several of your client sites look suspicious, the time pressure is double: technically and in your relationship with your clients. Get in touch now: call us or write to us on WhatsApp. We take over from the first message and stay with you until the incident is closed and documented. Report an emergency now
Frequently asked questions
Why are often several client sites affected at once?
Frequently the sites share a server, a hosting account, the same PHP process or the same credentials. If an attacker gets in at one point, he can move sideways. A vulnerable PHP also affects all sites that use it.
Should I inform the clients immediately?
That depends on the situation and the contract. First clarify which sites are really affected so that you do not inform on the basis of assumptions. With personal data, reporting duties are possible; the classification belongs with the data protection officer or a lawyer.
Who is liable if a client's site was hacked?
That depends on your contracts, the scope of care and the course of events. We give no legal advice on this. A clean report on cause and measures helps with that clarification.
Can you work under our name without the end client seeing us?
On request we work in the background for your agency and deliver reports that you can pass on to your clients. We discuss the details in advance.
Is it enough to clean up the client sites one by one?
Usually not. If the cause lies in the shared server, in shared access or in an unpatched PHP version, the problems reappear after individual cleanup. The cause has to be fixed as well.