Case study · Collectibles webshop · Netherlands
Magento 2.4.4 store moved to a new server and brought up to 2.4.9 on PHP 8.4
An old PHP version, a dated theme and 4,112 PHP files hiding in the media folder. We moved the store to a new server, cleaned it, upgraded it and tested it there before switching DNS. Customers never saw any of it.
- Magento 2.4.9
- PHP 8.4
- MySQL 8.4
- OpenSearch
- Laravel Forge
2.4.4 → 2.4.9
Magento version, on a new server
4,112
Disguised PHP files removed from media
PHP 7.4 → 8.4
End-of-life runtime replaced
01
Problem
The shop ran Magento 2.4.4 on PHP 7.4, which stopped getting security fixes in 2022.
It shared a server with another hacked store, and the media folder was full of PHP files pretending to be something else.
02
What we found
4,112 PHP files in media, mostly webshells dressed up as images and uploads. Some had been planted only recently.
PHP 7.4 on the live site, with no security fixes since November 2022.
A second hacked store on the same server, so cleaning in place was never going to last.
An old theme and extensions that wouldn't run on PHP 8.4 without code changes.
03
What we did
First we put the old server behind a login so nobody could reach the webshells.
Then we set up a new server and moved the store over, checking media files by what was inside them instead of trusting the extension.
We upgraded to Magento 2.4.9 on PHP 8.4, MySQL 8.4 and OpenSearch, and patched the theme and extensions to work on PHP 8.4.
We tested the shop and the admin three times over, real checkout included, before and after DNS moved.
04
Result
Live on the new server, no PHP files left in media, and checkout taking orders as usual.
HTTPS with HSTS, a fresh sitemap every day, and search suggestions working like before.
The old server stays locked as a fallback until it's switched off.