Magento security and incident response
Magento malware removal that doesn't come back next month
If there's a Magecart skimmer, a webshell or a root-level backdoor on your store, your customers' card details and your reputation are on the line. We stop the leak, keep the evidence, find how they got in and clear the infection from files, media, database and server. Then we change every exposed password and key, lock the store down and keep watching it. You get an incident report your acquirer, a PCI forensic investigator and your lawyer can all work from. Magento 2, Adobe Commerce and Magento 1, with active incidents handled first.
- Root-level server hacks handled
- Skimmers found in the database as well as files
- Incident report for your acquirer
- Active incidents go to the front of the queue
6
Backdoors found on one store that earlier cleanups missed
4,112
Disguised PHP files removed from one media folder
476,648
Rows checked and moved to a clean server on one rebuild
Merchants whose acquirer or payment provider has flagged a possible card data leak
Busy or multi-store Magento 2 and Adobe Commerce shops with a confirmed or suspected breach
Stores where the malware came back after someone else cleaned it
Businesses that need an incident report for the board, insurer or regulator
Magento 1 and OpenMage stores that take card payments
A typical cleanup runs a scanner, deletes what it flags and closes the ticket. The visible symptom goes and the attacker's access stays. On hacked Magento stores, the bit that brings it all back usually lives somewhere scanners don't look. A PHP file renamed to look like a product photo in pub/media. A cron entry that rewrites the skimmer every night. A systemd service named after a real system daemon. An extra SSH key on an old account. An admin user or API integration nobody remembers creating. JavaScript saved in core_config_data, CMS blocks or page builder content, where a file scan will never find it. Often the way in is still open too, through an unpatched extension, a leaked admin password or a server service exposed to the internet. A few weeks later checkout is sending card numbers out again, and your acquirer wants a timeline you can't give them. Fixing it for good means finding and closing the whole chain, and keeping evidence as you go.
signs-you-need-this.log
- ›Your acquirer or payment provider has flagged a possible card data leak
- ›The store was cleaned before and the same problems came back
- ›Admin users, API integrations or SSH keys you don't recognise
- ›Checkout loading scripts from domains you've never heard of
- ›Server CPU or outbound traffic is high and nobody knows why
- ›Google Safe Browsing or your host has sent a warning
We work through every incident in the same order. Nothing gets deleted until the evidence is saved, so the report holds up if an investigator or regulator asks for it.
- Step 01
Stop the leak
We cut live attacker sessions, reverse shells and outbound connections, lock the admin and, if needed, put checkout or the whole store behind a login. Card data stops leaving before the cleanup starts.
- Step 02
Save the evidence
Logs, file timestamps, database snapshots, running processes and network connections are captured before we change anything. If your acquirer brings in a PCI forensic investigator, it's all ready for them.
- Step 03
Find how they got in
A vulnerable extension, an unpatched Magento release, a leaked admin or API password, an exposed server service. If we skip this, the cleanup just buys the attacker a short break.
- Step 04
Clear files, media, database and server
We read code, vendor, media, database and server by what's inside each file, ignoring the names. That includes core_config_data, CMS blocks and pages, email templates, cron tables, crontabs, systemd units, SSH keys and user accounts.
- Step 05
Close it and change the keys
We patch the hole, change every password and key that could have been read, remove rogue users and keys, and lock down Magento, nginx, PHP, SSH and the WAF. If they had root, we rebuild on a clean server.
- Step 06
Keep watching
For a period afterwards we monitor file integrity, checkout scripts, admin logins and logs. A developer checks anything that changes, and then we issue the final report.
We go below the Magento folder
Plenty of cleanup services stop at the Magento directory. We work on the server too, looking at rogue processes, cron and systemd jobs, SSH keys and hidden binaries. When the machine can't be trusted, we build a new one and move over only data we've checked.
We look in the database
Today's Magecart skimmers often sit in core_config_data, CMS blocks and page builder content, where file scanners can't see them. We query for them directly and check each script that loads on checkout.
A report people can actually use
The timeline, the way in, the affected period and the evidence, written plainly enough for payment providers, PCI investigators, insurers and your own board.
An honest call on clean or rebuild
Sometimes cleaning in place is the wrong move. If the server, the code or the extensions can't be trusted, we'll tell you, explain why and give you a fixed-price plan for a clean rebuild.
From our clients
They rebuilt the entire site on a clean hardened server, migrating 20,000+ products, auditing 54 modules, and delivered a professional cutover report documenting every single step. Best developers I've worked with in 20 years of running web businesses.
Reviews from real clients. We leave their names off.
Related services
Emergency support
Store down, hacked or not taking orders? You get priority response and an experienced developer on it.
Magento upgrades
Get to Magento 2.4.9, PHP 8.4 and OpenSearch, tested on a copy of your store and released in a quiet window.
Magento audit
A fixed-price look at security, code, speed and upgrade path, with findings sorted by what matters.
Support & maintenance
A monthly retainer with developer time set aside for you, plus patches, monitoring and first call on incidents.
Tell us what you're planning for the store.
You'll speak to one of the developers. We'll tell you which route we'd take, what usually goes wrong on projects like yours and where we'd start.
Happy to sign an NDA · Everything tested on staging first · The code is yours