In short: Whether you rebuild or clean up a server after a hack depends on how reliably you know the scope of the break-in. If the attacker may have had root privileges, the time of the break-in is unclear or logs are missing, a rebuild from trustworthy sources is the more reliable choice. A cleanup is an option only for a tightly limited, well-evidenced compromise. In both cases the same applies: first preserve evidence and close the vulnerability, then tidy up.
Why this question is asked so often after PHP2Shell
According to php.net, PHP2Shell allows remote execution of malicious code without a login. Anyone who ran an unpatched server therefore has to ask whether something happened in the period since 17 October 2026, the first observed attack attempt according to media reports. The patch does not answer this question, and there are no published, confirmed indicators of compromise.
If a suspicious file, an unknown process or a foreign cron job is then found, the decision is at hand. The impulse is often to delete quickly or reinstall at once. Either can be right, but not as the first step.
The order before the decision
Before you choose between cleaning up and rebuilding, three things need to be done. They apply to both paths.
- Contain: Take the server off the network or restrict access to the bare essentials, without switching it off if memory is still to be preserved.
- Preserve evidence: Back up logs, files, database and, if possible, an image of the system, with date and checksum. Why this is necessary before any reinstallation is explained in Preserving evidence before you rebuild.
- Involve the insurer and data protection: Many cyber policies expect essential steps to be coordinated. Notes are under Cyber insurance: what counts in a claim. Whether a notification duty under the GDPR exists is assessed by the data protection officer or a lawyer.
Only after that is the actual weighing worthwhile.
Rebuilding a server after a hack or cleaning it up: the criteria
| Criterion | Clean up | Rebuild |
|---|---|---|
| Scope of the break-in | Tightly limited, evidenced, e.g. a file in the upload folder with no further traces | Unclear or with signs of system access |
| Possible root privileges of the attacker | Ruled out with good evidence | Cannot be ruled out |
| Availability of logs | Complete for the relevant period | Incomplete, overwritten or tamperable |
| Effort | Lower, if the finding is clear | Higher, but easier to plan |
| Remaining uncertainty | Higher, hidden backdoors are hard to rule out | Lower, if built cleanly from trustworthy sources |
| Downtime | Usually shorter | Usually longer, well controllable with preparation |
| Suitability for legacy systems | Problematic if the system is outdated anyway | Good opportunity to move to a supported PHP version |
As a rule of thumb: the less you know, the more speaks for a rebuild. With a vulnerability in the PHP interpreter that executes code in the context of the web server user, an attacker can use further vulnerabilities to gain more privileges. This can hardly be ruled out without a thorough investigation.
Both paths in practice
What “rebuild” really means
Rebuilding does not mean copying the old backup onto a fresh server. A rebuild starts with a clean operating system from an official source, current packages and a patched PHP version. The application is installed from the vendor’s original, and so are plugins and themes.
Only then is your own content added, and checked at that. Uploaded files must not contain executable scripts; the database can contain injected content, such as hidden admin accounts or scripts in posts. Configuration files are written anew rather than copied. All credentials are renewed: database, CMS admins, SSH keys, API keys, hosting panel.
Backups play an important role here, but only if their state predates the break-in and they themselves have not been altered. Several generations in separate locations make this verifiable; more on this under Backups following the 3-2-1 rule.
When cleaning up is defensible
A cleanup can make sense if the compromise was discovered early, complete logs are available and the investigation gives no indication of further access. The files found are then removed after being preserved, cron jobs, user accounts and SSH keys are checked and core files are compared with the vendor’s original.
A realistic assessment is important: web shells are often inconspicuous and hidden in several places. How to find them is described in Recognising and removing web shells. After a cleanup, the server should be watched closely so that an overlooked backdoor stands out.
Delete nothing before logs and files are preserved, and close the vulnerability before the server goes back on the network. Otherwise you lose the traces and invite the next break-in.
When you do not need a service provider
For a simple website on shared hosting, where the host manages the system and confirms the PHP patch, the decision often does not lie with you at all. You can reinstall the application from the original, check content and renew credentials, supported by the host. An experienced internal team can also manage a rebuild itself, provided evidence preservation and documentation are in place.
External help is worthwhile if root privileges cannot be ruled out, personal data might be affected, the insurer is involved or several systems are connected.
How does PHP SOS help?
- We preserve logs, files and database in an evidence-grade way before anything is changed.
- We assess the scope of the break-in and recommend cleanup or rebuild with reasons, separated into proven, probable and unknown.
- If needed, we rebuild the server from trustworthy sources, with a patched PHP version and renewed credentials.
- We take on malware removal where a cleanup is defensible, and document every step.
Conclusion
The question “rebuild or clean up?” is answered by what you know about the break-in. Anyone who does not know the scope reliably rebuilds. Anyone who can delimit it with good evidence may clean up. In both cases the same order applies: contain, preserve, close the vulnerability, then tidy up.
Frequently asked questions
Is rebuilding always better after a hack?
Not always, but often. If it is unclear how far the attacker got, a rebuild from trustworthy sources is usually the more reliable choice. With a tightly limited, well-evidenced compromise, a cleanup may suffice.
Can I just restore an old backup?
Only if it is certain that the backup was made before the break-in and contains no backdoor. In addition, the vulnerability must be closed beforehand, otherwise the server is immediately vulnerable again. Data of more recent date must be checked separately.
What do I need to preserve before rebuilding?
Logs, a copy of the files and the database and, if possible, an image of the system. You need this evidence for root cause analysis, insurance and a possible notification. Once deleted, it is gone.
Is it enough to delete the web shell that was found?
Rarely. Attackers often set up several backdoors, such as cron jobs, user accounts or SSH keys. Anyone who deletes only the visible file leaves the other access routes open.