In short: If your website has been hacked, this checklist helps you forget nothing: first contain and preserve evidence, then find the cause and clean up, afterwards renew all credentials, check duties and close the incident with documentation. The order matters, because anyone who deletes first loses traces, and anyone who only cleans up without closing the vulnerability will be attacked again.
What this checklist covers when the website has been hacked
The checklist is aimed at management, owners and IT leads after a confirmed or probable attack on a website, a shop or a PHP web server. It is also suitable after PHP2Shell, if a server was reachable before the update and there are signs of a compromise.
Not every step suits every environment. Still, work through the list completely and note for each step whether it is done, not applicable or open. This record is valuable later for insurance, data protection and internal follow-up.
For each step, enter the date, time, responsible person and result. If several people are involved, appoint one person who keeps the list and records decisions.
Phase 1: contain and secure immediately
- Limit the damage: Put the website into maintenance mode or take it offline if visitors are at risk or data could be leaking. For PHP2Shell, the BSI recommends temporarily taking unpatched web servers off the network if an update is not immediately possible.
- Delete nothing: Remove no files, do not rebuild the server and do not empty logs before traces are secured.
- Secure logs: Copy access, error, PHP-FPM and system logs to another system and record checksums. On PHP2Shell, the trade press advises keeping logs from 20 October 2026 onward.
- Secure an image: Create a copy of files and database, and for virtual servers a snapshot, as an evidence state and do not alter it.
- Inform those responsible: Involve management, the data protection officer, the hosting provider and, if present, the cyber insurer early. Many insurers have notification obligations.
Phase 2: find the cause and clean up
- Identify the entry point: Analyse logs, file changes and versions. Check PHP itself, CMS, themes, extensions, credentials and server services. Without a known cause, the risk of a renewed attack remains.
- Close the vulnerability: Bring PHP to a fixed version (8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the provider's confirmed backport), update CMS and extensions, restart all PHP workers.
- Narrow down the period: Determine the earliest time of suspicious activity. It decides which backups can be clean and which data may be affected.
- Remove backdoors: Check and remove webshells, foreign PHP files in upload and cache folders, modified core files, cron jobs, SSH keys and system services. Replace core files from a clean source.
- Clean the database: Remove unknown admin accounts, planted scripts in content and settings, and spam content.
- Consider a rebuild: With a deep compromise of the server, a rebuild on a fresh, patched system with checked data is often the more reliable route than cleaning up in the running system.
Phase 3: renew credentials and harden
- Change passwords: For CMS, hosting account, panel, database, FTP, SFTP, SSH and email, and from a clean device.
- Replace keys and tokens: Regenerate API keys, payment and shipping service interfaces, the CMS's application keys, SSH keys and certificates that were stored on the server.
- End sessions: Log out all active logins in the CMS and at services and check registered two-factor devices.
- Enable two-factor login: For all admin access, including hosting, domain and DNS.
- Harden the server: Check and document PHP settings, file permissions, execution blocks in upload folders, firewall and security headers.
Phase 4: duties, communication and close-out
- Check reporting duties: If personal data may be affected, a notification within 72 hours under Art. 33 GDPR may be necessary. The assessment is for the data protection officer or a lawyer. Check sector duties, for example under NIS2, separately.
- Consider a complaint: The police's Central Contact Points for Cybercrime accept complaints from companies. The secured logs are an important basis for this.
- Inform customers and Google: Inform those affected factually and in a coordinated way. If Google shows a warning, request the review after cleanup, as described under Removing the Google warning.
- Document the close-out and monitor: Record cause, period, measures and open points in a report, derive lessons for the emergency plan and monitor the systems more closely in the following weeks.
Common mistakes in the follow-up
Many incidents drag on because, in the first excitement, corners are cut in the wrong place or action is taken too fast. You should avoid these mistakes:
- Removing only what is visible: A deleted spam page or a removed redirect is no proof of a clean website. Backdoors often go unnoticed.
- Changing passwords from the affected system: If malware is still running on the computer or server, new credentials can leak out again immediately.
- Restoring a backup blindly: Without a closed vulnerability and without checking the backup, the attacker is quickly back at the door.
- Taking the patch as the all-clear: An update to a fixed PHP version does not prove that nothing happened before, and it does not remove planted malware.
- Checking duties too late: Deadlines begin when the incident becomes known, not when the cleanup ends.
- No documentation: Without a record, questions from insurers, authorities or customers can hardly be answered later.
This checklist does not replace legal advice. For questions on reporting duties, liability or insurance, contact your data protection officer, a lawyer or your insurer.
How does PHP SOS help?
- We take over structured incident response and work through the checklist together with you, point by point with a record.
- We secure logs and system states so that they remain usable for insurers, authorities and possible IT forensics.
- We close the vulnerability, clean up or rebuild, and renew credentials in the right order.
- We deliver a final report with cause, measures and recommendations and, on request, continue to monitor the systems afterwards.
Frequently asked questions
What is the first thing I should do if my website has been hacked?
Stay calm, delete nothing and limit the damage. If necessary, take the website offline or into maintenance mode and secure logs and files before you clean up. Finding the cause and cleaning up follow.
Is it enough to restore the website from a backup?
Usually not. The backup may already contain malicious code, and the vulnerability through which the attacker came is still open after restoring. First close the cause, then restore a checked, clean state onto an updated system.
Do I have to report a hack to the data protection authority?
If personal data may be affected, Art. 33 GDPR in principle provides for a notification within 72 hours of becoming aware, unless a risk to the data subjects is unlikely. The assessment is for your data protection officer or a lawyer.
When is an incident really closed?
When the cause is closed, all known backdoors are removed, credentials are renewed, duties are fulfilled and the measures are documented. A period of increased monitoring afterwards is part of it, to detect overlooked traces.