Is Your Old CMS Now a Security Risk? When to Move On

October has been a hard month for anyone running a website on PHP. In one week, three critical fixes landed: an authentication bypass in Laravel, ten fixes in Node.js, and PHP2Shell, a pair of flaws in PHP itself that can let an attacker with no login run code on a server. PHP2Shell is now being exploited, and working attack code is public.

Every PHP site was exposed until it was updated. But the sites that struggled most to get safe were not the custom-built ones. They were the WordPress, MODX, Joomla and Drupal sites that had quietly drifted out of date, and whose owners found out this month that updating was not as simple as pressing a button.

If that was your experience, this post is for you. It is not an argument that every CMS site should be thrown away. It is a way to judge whether yours has become a liability, and what to do if it has.

Why the same flaw hits CMS sites harder

PHP2Shell is in PHP, so in theory the fix is the same for everyone: update PHP and restart. In practice, a typical CMS site runs into three problems that a maintained Laravel application does not.

Stuck on an old PHP version

PHP 8.1 and older got no official fix. Plenty of CMS sites are still on those versions, not by choice, but because a plugin, theme or extra breaks on anything newer. The site cannot move forward until someone rewrites or replaces the part that holds it back, and that is not a job anyone wants to start during an active attack.

Security that depends on strangers

A typical WordPress site runs dozens of plugins. MODX sites rely on extras, Joomla on extensions, Drupal on contributed modules. Each is code written by someone else, to their own standard, updated on their own schedule, and some are no longer updated at all. Many public exploits for flaws like PHP2Shell need a second weakness in the site itself to work, and third-party add-ons are where that weakness usually comes from. We covered this in more depth in our PHP2Shell post and our review of WordPress security.

Hosting nobody controls

Many CMS sites sit on shared hosting, where only the host can update PHP. When a fix lands, the site owner can do nothing but wait and hope. Some hosts patched within hours this month. Others did not, and their customers had no way to know which kind they were with.

The versions that are already out of support

Some CMS sites are past the point where updating is even possible, because the CMS itself has stopped receiving fixes:

• Joomla 3 reached end of life in August 2023.
• Drupal 7 reached end of life in January 2025.
• MODX Revolution 2 has no published end-of-life date, but 2.8 is its final branch, it gets only critical security fixes, and it will not run on PHP 8.4. Extras are moving to MODX 3.
• WordPress only fully supports its latest release, so an old installation that cannot be updated because of a plugin is effectively unsupported.

A site on any of these is exposed to every flaw found from now on, with no fix coming. October's vulnerabilities will not be the last.

How to tell if your CMS has become a liability

Ask whoever looks after your site these questions. The answers will tell you quickly where you stand.

1. Which versions of the CMS and PHP does the live site run, and are both supported? If either is out of support, the site is already exposed.
2. How many plugins, extras or extensions does it use, and are they all still maintained? Anything abandoned is an open door that will never be closed.
3. Could the site move to the latest PHP version today? If the answer is "not without breaking something", it is stuck.
4. Who updates PHP on the server, and how quickly did they apply this month's fix? The answer should be a person and a date.
5. When did someone last restore a backup to check it works? A backup nobody has tested is a hope, not a plan.
6. Is the site doing more than publishing pages? Bookings, payments, member areas and integrations bolted onto a CMS are where risk and cost both build up.

If most of your answers were reassuring, your CMS is probably fine where it is. Keep it updated and keep the plugin list short. If several were not, the site has become a liability, and the next critical fix will be as stressful as this one.

Why a Laravel application is easier to keep safe

Laravel is not immune. It needed the PHP2Shell fix like everything else, and it shipped its own security fix this month. The difference is in what happens next.

• It runs on supported PHP by design. Every supported Laravel release requires a PHP version that got an official fix on day one. There is no plugin holding the site back.
• There is no plugin marketplace. The features are built for your business, and the code is yours. When a flaw is announced, the question "what might this expose?" has a clear answer.
• It lives on a server you control. When PHP needs updating, it gets updated, rather than waiting on a shared host.
• It is built to be upgraded. Laravel releases once a year on a published schedule, so keeping current is a planned task, not a gamble on twenty plugin authors.

For a maintained Laravel site, this month's response was simple: update PHP, update Laravel, restart the workers, run the tests. Routine, not a crisis.

Your team does not lose the ability to edit the site, either. Laravel sites have proper editing screens, built around your content rather than a generic one. We explain how in Content Editing in Laravel.

When moving is not worth it

Being honest about this matters. A small brochure site on a current version of WordPress, with a handful of well-known plugins, managed hosting and someone accountable for updates, is not a crisis. Moving it to Laravel would cost more than it saves.

Moving earns its keep when the site is stuck on unsupported versions, depends on add-ons you cannot replace, or has grown into something your business relies on: taking bookings, payments or member sign-ups, or connecting to other systems. Our list of signs you have outgrown your CMS goes into more detail.

What a move involves

Moving from a CMS to Laravel is a well-trodden path. Your content, URLs and search rankings come across, the old site stays live until the new one is ready, and your team gets editing screens that fit how they work. We have written plain guides for each platform:

• WordPress to Laravel
• MODX to Laravel
• Joomla to Laravel
• Drupal to Laravel

If cost and timing are the question, what a Laravel migration actually costs sets out realistic figures, and migrating without losing SEO covers the part most owners worry about.

Moving is only half of it

A new platform does not keep itself safe. This month showed that the deciding factor was not just the software a site ran on, but whether someone was responsible for updating it, and how quickly they did. That responsibility has two parts.

Managed hosting, for the server

Cheap shared hosting is where many CMS sites ran into trouble this month: the owner could not update PHP, and could not see whether the host had. Managed hosting puts a named team in charge of the server itself.

• PHP and the operating system are patched promptly, and someone confirms it was done.
• Long-running processes are restarted, so an update is actually in effect rather than just installed.
• Backups are taken off the server and tested, so the worst case is recoverable.
• The server is monitored, so unusual activity or a site going down is noticed by someone other than a customer.

Our managed DevOps covers this for Laravel applications.

Ongoing support, for the application

The server is only one layer. The framework, the packages the site uses and the code itself all get security fixes too, and a host will not apply those. Ongoing support is someone who knows your application keeping that layer current:

• Framework and package updates, with security fixes applied within days, and critical ones within hours.
• A planned yearly upgrade, so the site never drifts onto unsupported versions.
• Someone watching for announcements like this month's, rather than hearing about them from the news.
• A clear view of what your site runs, so the answer to "are we affected?" takes minutes, not a day.

The two fit together. When the parts are split between a host, a former developer and nobody in particular, the gaps between them are where updates get missed. Our support and maintenance retainers cover the application, alongside the hosting, so one team is accountable for both.

How we can help

At AugmentBLU we move businesses off ageing CMS platforms and onto Laravel, then host and look after them. For the sites we look after, this month's fixes were routine, and our clients did not need to do anything.

If this month left you unsure whether your site is safe, get in touch. We will check what it runs, tell you plainly whether it is exposed, and whether it is worth keeping, fixing or moving.

We reply within 24 hours.