In short: Switching the CMS after a hack only helps if the old system itself was the cause, for example because the vendor no longer delivers security updates or important extensions are no longer maintained. If the cause lay in outdated plugins, weak credentials or a vulnerability like PHP2Shell in the underlying PHP, a switch only shifts the effort. In any case: check content first, then move it, otherwise the malicious code moves with it.
When trust is gone
After a break-in, the mood is often unambiguous: “Never again with this system.” That is understandable. The website redirected visitors to other sites, Google issued a warning, customers asked questions. A new CMS feels like a fresh start.
The PHP2Shell situation shows, though, why this reflex can mislead. The vulnerability sits in the PHP interpreter, not in WordPress, TYPO3, Shopware or any other system. According to drweb.de, WordPress.org therefore plans no update of its own against it. Anyone who now switches from one PHP CMS to another PHP CMS ends up with the same dependency, just with a different logo. Which systems run on PHP is shown in the overview Which CMS and shop systems run on PHP.
The cause decides
Before you think about a switch, the cause of the break-in must be clarified. Typical entry points are outdated extensions, reused or weak passwords, missing two-factor login, an unpatched server or forgotten test installations. None of these causes is tied to a particular CMS.
Anyone who does not know the cause risks taking it along into the new system. A team that has so far postponed updates will do the same in the new CMS. An agency that used shared admin accounts will repeat that unless someone changes the procedure. The question is therefore less “which CMS?” than “which process?”.
Switching CMS after the hack: the weighing
| Criterion | Stay with the existing CMS and harden it | Switch to a different CMS |
|---|---|---|
| Cause of the break-in | Known and fixable, e.g. outdated plugin | Lies in the system itself, e.g. missing vendor updates |
| Vendor maintenance | Security updates are delivered | Vendor has ceased maintenance |
| Dependence on extensions | Few, maintained extensions | Many extensions without active maintenance |
| Effort | Cleanup, hardening, process change | Rebuild, migration, training, often redesign |
| Time to a secure website | Shorter | Longer, interim solution needed |
| Protection against PHP vulnerabilities | No change, PHP must be patched | No change, as long as the new system uses PHP |
| Long-term benefit | High, if processes are improved | High, if the old system was at its end anyway |
If most rows in your situation land on the left, switching is hardly worthwhile. Staying, cleaning up, hardening and improving the maintenance process brings more security for less money. For WordPress operators, WordPress and PHP2Shell summarises the key steps.
You do not always need a service provider for this decision. If the cause was clear, such as a known plugin with a published vulnerability, and your agency or admin has rebuilt the website cleanly, you can decide yourself. External help is worthwhile if the cause remains unclear or personal data might be affected.
If you switch: don't take the malicious code along
If the decision is to switch, the migration itself is a security risk. Attackers leave traces not only in files but also in the database. These steps help to move cleanly:
- Back up and isolate the old system: A complete backup as evidence, then take the old system off the network or make it reachable internally only.
- Export content selectively: Texts, page structure and media, not the complete database. Do not carry over user accounts but create them anew.
- Check content: Look through texts for injected scripts, hidden links and foreign redirects. How to do this is described in Checking the database for injected code.
- Filter media: Take over only expected file types, sort out files with double extensions or script content.
- Set up the new system cleanly: From the vendor’s original source, on a server with patched PHP, with new credentials and two-factor login.
- Plan redirects: Redirect old addresses to new ones so that search engines and visitors arrive, without leaving old paths open.
A CMS switch does not replace cleaning up the old server. If the old system keeps running, for example as a forgotten copy under a subdomain, the backdoor stays open.
The alternative that is often overlooked
Some companies find after a hack that they do not need the functions of a large CMS at all. A company website with a few pages that rarely change can do without PHP on the server. A static site generator produces finished HTML files that no longer need any server-side program logic. The advantages and disadvantages are described in Static websites: less PHP, less attack surface.
Conversely, this is usually not an option for shops, portals or websites with many editors. A dynamic system remains sensible there, and security comes from maintenance, hardening and monitoring.
Anyone unsure whether hidden access still lurks in the old WordPress will find the typical places to look in Finding backdoors in WordPress. This also helps in deciding whether a cleanup is realistic.
How does PHP SOS help?
- We first clarify the cause of the break-in and tell you whether it lies with the CMS or with process and server.
- We clean the existing system as part of malware removal or prepare it as evidence for a rebuild.
- For a switch, we check the content and media to be taken over for malicious code before they reach the new system.
- We set up the new server with patched PHP and a hardened configuration.
Conclusion
A CMS switch after a hack is rarely the solution, but sometimes the right occasion. If the old system is no longer maintained, a fresh start is worthwhile. If the cause lay in processes or the server, work on the process brings more than a new logo. In both cases: check first, then move.
Frequently asked questions
Does switching CMS help against PHP2Shell?
No, as long as the new CMS also runs on PHP. PHP2Shell sits in the PHP interpreter, not in the CMS. What matters is the patch level of PHP on the server, not the system on top of it.
Is WordPress less secure than other CMS?
That cannot be said across the board. Many break-ins stem from outdated extensions, weak credentials or missing updates, and these causes exist in every system. Its popularity does make a CMS a more frequent target of automated scans, however.
Can I simply export content from the hacked CMS?
Only after checking. The database may contain injected scripts, hidden links or foreign admin accounts. Uploaded files can disguise malicious code. Export content selectively and check it before importing.
When is a CMS switch really sensible?
If the vendor no longer delivers security updates, if the website depends on extensions that are no longer maintained, or if the system simply no longer fits today’s requirements. The hack is then the occasion, not the reason.