In short: If you suspect that your server was hacked through PHP2Shell, get in touch now. Affected? Call us. We help. From the first message we handle containment, preserve the evidence, close the vulnerability, remove malicious code and document the incident until it is closed.
Do not delete anything and do not rebuild anything right now. Deleted files and overwritten logs are the traces that show whether and how someone got in. Take the server offline if necessary, but leave it unchanged. Report an emergency and we will tell you the next step.
Are You Affected? Signs That PHP2Shell Has Already Been Used
PHP2Shell is the name for two critical vulnerabilities in PHP itself that let attackers run malicious code remotely without logging in. So far there is no unambiguous fingerprint. That is why what the server does matters, not what a scanner finds. Signs of a break-in include:
- Web server or PHP-FPM processes that start a shell such as
shorbash. This is a strong warning sign. - New or modified PHP files in upload, cache or temp folders that nobody created.
- Cron jobs, services or SSH keys that you do not recognize.
- Outgoing connections to unknown destinations, a sudden high load or unusual traffic.
- Requests in the logs from 17 October 2026 onward, especially suspicious uploads and session requests before the patch was applied.
- Messages from your host, browser or search engine about spam, malware or redirects.
You will find more under Am I already compromised?. If none of these signs is present, that is no proof of a clean server. It only means that nothing has been noticed so far.
What to Do Right Now
- Change nothing. Do not delete files, restore a backup or reinstall anything before the evidence has been secured.
- Secure the logs. Ask your host or your IT team not to overwrite access, error and system logs. Trade press advises keeping logs from 20 October 2026 onward.
- Decide on availability. If data may be leaking or visitors may be at risk, take the site offline or switch it to maintenance mode.
- Collect access details. Note who has access to the server, panel, CMS and database. Change passwords only after consultation and from a clean device.
- Inform the right people. Management, the data protection officer and, if you have a policy, your insurer.
- Call or write to us. The sooner we know the situation, the more can be documented.
How Does PHP SOS Help?
We work remotely, with no travel, across Germany and Europe.
- Assess the situation: We clarify which systems are running, which PHP operating mode is in use, what has been noticed and which data may be affected.
- Secure and close: We secure files, database and logs and record the state before any change. Then we close the vulnerability with the patch or, if that is not yet possible, with interim measures, and restart all PHP processes.
- Check and clean up: We look for webshells, backdoors, cron jobs and foreign access and remove them, or we rebuild the system from trustworthy sources. The approach is described in Having malware and webshells removed.
- Harden and report: We change the affected secrets, add protective measures and deliver a report that separates what is proven, what is probable and what is unknown.
If the incident grows beyond one server, we move into structured incident response. If you need evidence that will stand up in court, we bring in IT forensics.
Why a Patch Alone Is Not Enough After an Attack
The vulnerabilities are in the PHP interpreter, not in the CMS. On 21 October 2026 the maintainers released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anyone who updated afterward and restarted all workers is protected against new attacks via this route. What an attacker planted beforehand stays in place, though: a webshell, an additional account, a scheduled task. This is exactly why the days between 17 and 21 October are particularly important.
There is a second point: a webshell is often only the first step. Anyone who could run code on the web server could also read configuration files and take over database, mail and API credentials from them. Those secrets must be replaced, otherwise the door stays open even though PHP is patched. How to check files and timestamps sensibly is described in the guide on recognizing webshells.
Reporting Duty and Documentation
If personal data may have been affected, a notification to the supervisory authority within 72 hours may become necessary. The clock starts at the moment you become aware, not when the investigation ends. Whether your case must be reported is decided by your data protection officer or a lawyer; we do not provide legal advice. Our documentation provides the basis for that decision. You will find more on the deadline under GDPR notification duty within 72 hours, and the steps that follow in the checklist after a hack.
What You Should Send Us
- A description of what has been noticed, since when, and who noticed it
- The type of server: own server, managed server or hosting package, plus the host
- The output of
php -vand, if known, the operating mode (PHP-FPM, mod_php, LiteSpeed) - The time of the PHP update, if it has already been applied
- Access to the server, or permission to talk to your host
- A contact person with authority to decide on shutdowns and restarts
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 who accompanies you from the first message to the close of the case. Everything we do is documented so that you can substantiate it to management, insurer and authorities. We promise nothing that nobody can deliver: if logs are missing, we say so openly, and we state what is proven and what remains assumption.
Affected? Call Us. We Help.
Do not wait until suspicion becomes certainty. 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
Is it enough to update PHP if my server may already have been hacked?
No. The update closes the vulnerability, but it does not remove malware that has already been planted and does not prove that nothing happened beforehand. After the patch, the server must be checked for traces of a break-in.
How do I recognize a successful PHP2Shell attack?
There are no published, confirmed indicators of compromise. Detection relies on behavior: web server processes that start a shell, new PHP files in upload or cache folders, unknown cron jobs or SSH keys, and suspicious outgoing connections.
Should I take the server offline if I suspect a break-in?
Often that is the right call, because the BSI (German Federal Office for Information Security) advises taking web servers offline temporarily even when an update is not immediately possible. The important thing is to delete nothing and to keep logs and files so that the incident can be investigated.
Do I have to notify the data protection authority after a PHP2Shell attack?
If personal data may be affected, a notification within 72 hours may be required. You make that decision together with your data protection officer or a lawyer; we supply the technical facts for it.
Have servers really been hacked through PHP2Shell already?
According to media reports, the first observed attack attempts began on 17 October 2026, and Cloudflare and Patchstack reported attempts. The BSI initially reported no confirmed successful attacks on a broad scale. In an individual case, this can only be settled on the server itself.