Incident response · 2026-07-07

Magento Malware Removal: A Step-by-Step Cleanup Guide

Removing malware from Magento is not just deleting a bad file — if you don't close the entry point and remove the backdoor, the attacker re-infects within days. This is the step-by-step cleanup that actually sticks: find the way in, clean everything, rotate secrets, and prevent reinfection.

Start by mapping the damage: run a free MageArgus scan for web-reachable indicators, then run the on-disk module to see files and the database.

By the numbers

Reinfection is common when only the visible payload is removed — MageArgus incident data
The entry point is almost always an unpatched CVE or stolen admin login — Sansec

1. Contain — don't destroy evidence

Put checkout into maintenance mode (or the whole store if severe). Take a full snapshot of files + database first — you'll want it for forensics and to compare later. Resist the urge to start deleting.

2. Find the entry point

You cannot clean what you don't understand. Check your Magento version against known CVEs, review access logs for suspicious POSTs to /rest/ or /checkout, and list admin users and integration tokens created recently. The entry vector tells you what to patch.

3. Remove web backdoors & injected code

Delete PHP that shouldn't execute in web-writable paths, and restore modified core/template files from a clean release:

find pub/media pub/static -iname '*.php*' -type f      # nothing should run here
grep -rIl 'eval(\|base64_decode\|_cc_ov\|api.telegram.org' pub/ app/ generated/ 2>/dev/null
composer install   # restore vendor files from clean packages

4. Clean the database

Skimmers and redirects often live in the DB:

mysql -e "SELECT * FROM core_config_data WHERE value LIKE '%<script%' OR value LIKE '%atob(%';"
mysql -e "SELECT * FROM cms_block WHERE content LIKE '%<script%';"

Remove injected snippets from CMS blocks/pages and config (head/footer includes), then flush cache.

5. Rotate every secret & remove persistence

Rotate the encryption key (bin/magento encryption:key:change), all admin passwords, DB and API credentials.
Delete rogue admin users and integration tokens.
Check crontab, shell-init files and ~/.ssh/authorized_keys for attacker persistence.

6. Patch, then verify

Upgrade off any EOL branch and apply all security patches so the same door can't be used again. Re-scan (remote + on-disk) to confirm clean, then lift maintenance mode. Follow up with the hardening checklist to reduce the odds of a repeat.

Frequently asked questions

Can I just restore from a backup?

Only if you know the backup predates the compromise and you also patch the entry vector. Restoring a clean backup onto an unpatched store just gets you re-hacked. Always patch and rotate secrets as part of recovery.

How do I know the cleanup worked?

Re-scan with both a remote and an on-disk scanner, confirm no rogue admins remain, and monitor for a few days. If the store was hit via a stolen key, rotating it is what actually locks the attacker out.