Recognise the signs in time
Many breaches go unnoticed for weeks because the store appears to run normally. The damage happens quietly, so watch for subtle changes in behaviour and administration.
On Magento, the most common attacks are card theft through injected scripts in the checkout (skimmers, often called Magecart), abuse of your server as a relay for spam, and unauthorised access to the admin panel.
- Unknown admin accounts, or admin logins from unfamiliar locations or at odd times.
- Customer complaints about unauthorised charges after placing an order.
- Unexplained high outbound mail volume, or your domain suddenly being blacklisted.
- Strange or recently modified files, extra JavaScript in the checkout, or unknown scheduled tasks (cron).
- Warnings from your payment provider, host, bank, or a security notification.
The first hours: calm and careful
The biggest mistake in the first hours is deleting everything in a panic. Discarded log files and overwritten code make it impossible to find the entry point, so the attacker simply returns after your 'clean-up'.
First take stock and preserve evidence. Make a full backup of the current (infected) state of files and database before you change anything, and document what you observe with timestamps.
- Put the store into maintenance mode if needed, rather than tearing it down.
- Change every password: Magento admin, database, SSH/FTP, hosting and email.
- Rotate API keys, payment and integration tokens, and the Magento encryption key where possible.
- Invalidate active admin sessions and disable unknown administrator accounts.
- Inform your hosting and payment providers; they can help stop ongoing abuse.
Find the entry point
Cleaning up without knowing the cause is mopping the floor with the tap still running. Set aside time to establish how the attacker got in before you bring the store back online.
In Magento stores the cause is often overdue security patches, a vulnerable or outdated extension, or an upload flaw used to place malicious files on the server (a well-known route to remote code execution).
Compare your files against a clean copy of the same Magento and module releases, review the access and error logs around the first odd behaviour, and look for files created or changed outside of a normal deploy.
Clean up and harden
Where possible, restore from a demonstrably clean backup from before the breach, combined with fresh core and module files from your version control. Never blindly restore a backup whose infection date you do not know.
Remove injected scripts, leftover web shells, and unauthorised accounts and tasks. Then apply all outstanding Magento security patches and update or remove vulnerable extensions.
- Run a full scan again afterwards to be sure nothing returns.
- Restrict write and execute permissions in media directories and tighten the server configuration.
- Only re-enable payments and open the store once the checkout is provably clean.
Your GDPR duty in the EU
If personal data or card data was exposed in the breach, this is a data breach under the GDPR and you have a legal notification duty. Treat it as an obligation, not a choice.
In most EU member states you must report a notifiable breach to your supervisory authority within 72 hours (in the Netherlands, the Autoriteit Persoonsgegevens). If affected individuals are likely at high risk, you must inform them as well. Carefully document the nature of the breach, the data involved and your response measures; a security partner can advise, but final accountability remains with you as the data controller.