What I Learned When My Magento Store Was Hacked

The short version

I kept my store patched. When Adobe fixed a critical flaw called SessionReaper, I installed the update. But I read the version number, not the whole bulletin. It also said the upload address the attack used still needed blocking by hand, and I missed that. Bots found the gap and used it to drop junk files on my store. With the patch in, they couldn't run them, but they shouldn't have been able to put them there.

None of this was a targeted attack. These are automated tools that scan every Magento store on the internet, looking for anything not fully locked down. I'm sharing it because it shows how easily one missed line can matter, even for someone who builds Magento software for a living.

How it unfolded

1. Sept 2025

   Adobe publishes an emergency fix for SessionReaper (CVE-2025-54236). The bulletin also says the patch doesn't close the upload address the attack uses, and that it should be blocked by hand.

2. Oct to Nov 2025

   Attacks on SessionReaper start worldwide in late October and the first junk files land on my store. At the start of November I install Magento 2.4.8-p3, which includes the fix, so the flaw can't be used to run code. What I don't do is block the upload address.

3. Nov 2025 onwards

   Bots keep using that open address to drop junk files into my media folder. Nothing looks wrong from the shop front.

4. March to April 2026

   A new flaw, PolyShell, is published with no patch for my version. Within three weeks bots use it to plant web shells. My server's configuration stops them being run.

5. 5 Sept 2026

   Another store I look after goes down. Investigating it leads me to the same files on mine. I block the upload addresses at the firewall and on the server the same day.

6. 7 to 8 Sept

   Adobe announces another critical flaw, StyleSmuggler. I patch it the next day. The following night, attackers probe my checkout for it and fail.

7. 17 Sept

   I find and stop a hidden backdoor program that appeared during the clean-up, and upgrade the store to Magento 2.4.9 and PHP 8.4.

8. Oct 2026

   I fix the knock-on damage: junk pages in Google's index, bots abusing the checkout, and server settings left over from the emergency work.

What I missed

One line. Adobe's SessionReaper bulletin said the patch stopped attackers running code, but the file upload address it abused still needed blocking separately, for example with a firewall rule. I installed the patch, saw the version number change and moved on. That's the whole mistake, and it's one I won't make again: read the whole bulletin, not just the version number.

In hindsight there was a clue, too. In April 2026, Netcraft flagged one of the dropped files. I should have followed it back to its cause.

What held

• The patch. With the SessionReaper fix installed, the files bots dropped couldn't be used to run code, and there's no sign any ever were.
• The server configuration. The web shells planted through PolyShell, a flaw with no patch for my version at the time, were blocked from being served, and there's no sign any of them ran.
• Backups. Automated daily server backups were in place throughout, so there was always a safe point to go back to.

What I did about it

1. Contained it the same day. Blocked the upload addresses at the firewall (Cloudflare) and on the web server.
2. Kept the evidence. Moved every planted file out of the website rather than deleting it, and wrote the attack up for Adobe's security team and my PCI scanning provider.
3. Swept properly. Searched the contents of every file, not just names and extensions, because attackers hide code inside real images. Early sweeps missed some; I kept going until repeated scans came back clean.
4. Patched fast. When Adobe announced StyleSmuggler during the clean-up, I applied the fix the next day. Attackers tried it on my checkout the night after, and it didn't work.
5. Found what files can't show. A hidden program had been started on the server during the clean-up. Checking running processes, not just files, found it, and it was stopped. How it got there couldn't be established, because the server logs from that day had already been rotated away, which is another lesson in itself.
6. Upgraded. Moved to Magento 2.4.9, which closes PolyShell, and PHP 8.4, twelve days after finding the problem.
7. Fixed the knock-on damage. Closed the checkout routes bots were abusing, hid the Magento version, and cleaned up thousands of junk pages Google had indexed by switching on canonical tags, writing a proper robots.txt, generating a sitemap and keeping search pages out of the index.

Where it stands now

The store passes my own Magento Store Health Check and SEO & Indexing Check with no errors and no warnings. Both tools exist because of this: they look for the warning signs I now check for on every store I look after.

Lessons for every Magento store owner

• Read the whole security bulletin. Some fixes need a manual step as well as the update. The version number won't tell you that.
• Patch quickly. Attackers were testing my store for StyleSmuggler within about two days of it being announced.
• Treat odd signals as clues. A takedown notice, strange files in the media folder, or failed orders with nonsense addresses all point to something worth following up.
• Know which web server you run. .htaccess rules protect nothing on nginx. Check the protection actually works on your setup.
• Check processes as well as files. Not everything an attacker leaves behind is a file in your website.
• Keep backups you can actually restore. Without them, a clean-up becomes a rebuild.

Worried about your own store? Run the free health check, or book a free health review and I'll look it over with you.