Case Study · Security response · Old PHP, moved overnight
A whole estate, onto supported PHP overnight
When a critical PHP flaw was published and the official fix only covered the newest versions, we put a stop-gap on every server before the fix was out, then rebuilt every site it didn't cover on supported PHP the same night.
Trusted by:
Once we knew the fix wasn't coming for some of our clients' sites, there was no point waiting for one. We built new servers that afternoon and moved everything that night. That's what looking after someone's software is for.
A critical flaw, and no fix coming for older PHP
In October 2026 details of a critical flaw in PHP leaked a day before the fix. It was the kind that lets someone run their own code on your server.
We look after a lot of PHP sites and business systems for clients, spread across several servers and dozens of containers. When the official fix came out, it only covered the newest versions of PHP. Some of our clients' sites ran on versions it didn't cover, which meant no fix was coming for them, ever.
These were live businesses: publishers, back-office systems, client portals. Waiting wasn't an option, and neither was taking them offline.
- Details of the flaw leak.
- Every server and container checked.
- Stop-gap applied everywhere.
- Official fix, newest versions only.
- First rebuilt server live.
- Second rebuilt server live.
- Last live site moved.
- Development copies done.
No fix for older versions
The official fix only covered the newest PHP. Sites on older versions would stay open to the flaw for good unless they moved.
Several servers, dozens of sites
Different servers, different set-ups and different code, all needing checking at once, not one at a time over a fortnight.
Live businesses, no downtime window
Orders, bookings and publishing don't stop for a security flaw. Whatever we did had to happen without customers noticing.
Newer PHP is stricter
Code that ran happily on the older versions needed adjusting before it would run on a supported one.
Jobs that mustn't run twice
Scheduled tasks like nightly backups and syncs had to move with each site, and never run on the old and new servers at the same time.
"Patched" isn't always patched
A server can report the fix installed while still running the old copy in memory. That needed checking, not assuming.
Close the door first, then move what couldn't be fixed
Two things at once: a stop-gap everywhere straight away, and new homes for every site the official fix didn't cover, built and switched the same night.
Check everything
Every server and container we look after: which PHP each site runs, and whether a fix would exist for it.
Stop-gap everywhere
The leaked details showed exactly how the flaw was used, through one setting most sites never need. We switched it off on every server before the official fix was out. Not a full fix, and we didn't treat it as one.
Build new servers alongside
For each affected server, a new one with current, patched PHP, with a snapshot of the old one taken first.
Copy, match and adjust
Every site and database copied across, the old database settings matched so nothing behaved differently, and the code adjusted wherever newer PHP was stricter.
Test privately, then switch
Each site tested on its new server before anyone else saw it. Then we moved the server's address across, so there were no DNS changes to wait for.
Keep a way back
The old servers were stopped, not deleted, ready to switch back to if anything looked wrong.
What we did, in short
A stop-gap in fifteen minutes. Every unfixable site moved before morning.
The official fix came out at three in the afternoon. By the early hours, nothing we look after was waiting for one.
- Every server and container checked for the PHP version each site runs
- Stop-gap setting applied everywhere, ahead of the official fix
- Official fixes installed wherever PHP was new enough to get one
- New servers built for everything the fix didn't cover, on supported PHP
- Sites, databases and scheduled jobs moved, and old database settings matched
- Every site tested privately before the switch
- Switched by moving server addresses: no DNS waiting
- Old servers kept, stopped, as a way back
- A full restart check after every PHP update from now on
What changed
Nothing we look after was left waiting for a fix.
Nothing left waiting for a fix
Every site we look after got the official fix, a supported vendor patch, or a new home on supported PHP.
No DNS changes to wait for
Moving server addresses meant each switch took minutes, and switching back would have too.
Newer servers where it mattered
The rebuilt servers run current, supported operating systems, not just newer PHP.
A safer update routine
Full restarts and a check for old code still in memory after every PHP update, not just a reload.
What our clients say
19 clients. A few of their words.
A well-rounded team, ensuring a full suite of expertise & resource is always available. CDS Global have seen the successful completion of major projects over the years where Dev Partners' ability to grasp the underlying business needs to provide a future-proof solution has been invaluable.
We have worked with Jason & his team to develop our Shopify store, and the experience was outstanding from start to finish. The design is clean, modern, and perfectly aligned with our brand identity, while the build is fast, responsive, and easy to manage on the backend. They clearly understood our vision and delivered a store we're genuinely proud of. Highly recommend to any brand looking for a top-quality Shopify partner.
After ongoing issues and delays with our previous developers, we brought in Rob & Jason at Dev Partners to take over all our websites and bespoke software. What a breath of fresh air, fully focused, excellent pre-launch designs and clear communication throughout. Highly recommended.
BPC Energy Ltd turned to Dev Partners for a complete turnkey solution, and they exceeded our expectations. The team handled everything from project management to development and support with real care and attention. They understood what we were aiming for, stayed on top of every detail, and always delivered on schedule with excellent quality.
Is your software on an old version?
If you're not sure what yours runs on, or nobody's looking after it, start here.
Is your software on an old version?
Tell us what you have and we'll tell you where you stand.
What the system does, roughly how old it is, and who looks after it now (if anyone). If you don't know what it runs on, that's a normal answer here.
What we will cover:
- What it runs on, and whether that still gets security fixes
- What's exposed if it doesn't
- What it would take to move it somewhere supported
Rather talk now? Book a call or ring 01474 639 089.
We reply within one working day.
