Magento Admin Panel Compromised: Taking the Store Back

By Glenn Lyvers · Updated September 21, 2026 · 4 min read

Admin access to a Magento store is worth a great deal more than admin access to a blog. It reaches customer records, order history, payment configuration and the content system that renders your checkout, and it does all of that quietly. If you have found an administrator account you did not create, treat it as a serious incident rather than a piece of housekeeping.

How they get in

Unpatched Magento is the leading cause, and it is worth being blunt about why: security patches for Magento are published with detail, exploitation follows quickly, and a great many stores apply them late or not at all. If your store is behind on patches and the admin has been compromised, that is almost certainly your answer.

The rest of the list is familiar. Weak or reused admin passwords, brute-forced because the admin path was left at a predictable default. Third-party extensions with vulnerabilities of their own. Credentials stolen from a staff member's computer. And, on stores that have been compromised before, an account created during an earlier incident that nobody removed.

What they do with it

The valuable move is injecting a payment skimmer, which on Magento usually means adding code through the content system rather than editing files — a block of markup stored in the database and rendered onto checkout pages. That is covered in detail in my guide on Magento card skimmers, and it is the outcome to check for first.

Beyond that: exporting customer data, changing payment or payout configuration, creating additional admin accounts for later, generating API keys and integration tokens that survive a password change, and altering email templates so order notifications go somewhere useful to them. Each of those persists independently of the account you are about to delete.

What to do first

Preserve evidence before changing anything, as covered in preserving evidence — you will need the admin action log and the timeline, particularly if card data was involved. Then check your checkout for a skimmer immediately, because that is the finding that changes everything about your response and it is time-critical.

If you find one, disable checkout and notify your payment processor before continuing. If you do not, you still have an admin compromise to work through, but you have more room to be methodical about it.

Cleaning up the access

Delete admin accounts you did not create, and reset passwords on the ones you keep. Then, and this is the step most people miss, revoke every integration and API token — those are independent credentials that continue working perfectly after you change every password in the system, and they are the most common reason an attacker returns to a store that was supposedly secured.

Review admin roles as well as accounts, because granting a dangerous permission to an existing low-privilege role is quieter than creating a new administrator. Check the admin action log for what was actually done while they had access; on Magento that log is genuinely useful and it will often hand you the timeline directly.

Then check the store itself

Look through the content system for blocks and pages containing script tags, especially anything associated with checkout, and check configuration values that can carry markup. Look at your templates and any third-party extensions. Sweep the database for injected content.

Then verify your settings: payment methods and their credentials, payout destinations, email addresses on notifications, and any webhooks or integrations. Apply outstanding security patches, remove extensions you do not use, and rotate database credentials and the encryption key if there is reason to believe they were exposed.

Keeping the admin out of reach

Apply security patches promptly, which is the single measure that would have prevented most of these incidents. Use a non-default admin path, enable two-factor authentication on every admin account, and restrict admin access by IP address if your circumstances allow it — for a store with a small, known set of staff, that one control removes most of the risk.

Audit admin accounts and API tokens on a schedule rather than only after an incident, and remove access for people who have left. If the store takes card payments and you want it properly swept and verified rather than hoping you found everything, that is what I do — see the platforms I clean.

Common questions

I found an admin account I did not create. What now?

Treat it as a full compromise rather than deleting it and moving on. Preserve the admin action log first, check your checkout for a skimmer immediately, then remove the account, reset all admin passwords, and revoke every API and integration token — those keep working after password changes.

Why do API tokens matter so much?

Because they are separate credentials. Changing every admin password in the store does nothing to a valid integration token, so an attacker holding one retains access to data and configuration. Revoking and reissuing them is as important as the passwords, and it is the step most commonly skipped.

How do I know if they added a skimmer?

Load your checkout as a customer with developer tools open, account for every script, and watch the network panel while entering test card data. On Magento the payload is usually stored in the content system rather than in files, so also search your CMS blocks and configuration for script tags.

Does changing the admin URL actually help?

It stops a large volume of automated brute-force traffic aimed at the default path, which is worthwhile and free. It is not a security boundary against someone who finds the path another way, so pair it with two-factor authentication and, where practical, IP restrictions.

My store is behind on security patches. Is that how they got in?

Very likely. Magento patches are published with enough detail that exploitation follows quickly, and unpatched stores are found by automated scanning. Cleaning the store without applying the outstanding patches leaves the same door open, so the update is part of the fix rather than a follow-up task.