Magento Security - complete overview

Sansec has investigated Magento breaches since 2015. We run the largest eCommerce forensics practice in the world and take apart dozens of hacked stores every week. This guide distills what we see in those investigations into the controls that actually keep attackers out.

Magento is powerful and flexible, and that complexity is exactly what attackers target. A default install is not safe by itself. The stores that stay clean are the ones that patch fast, lock down admin access and watch their own files.

How Magento stores get hacked

These are the attacks we see most often in our incident response work.

1. Unpatched core vulnerabilities. Attackers weaponize Adobe security releases within hours of publication. SessionReaper (CVE-2025-54236), an unauthenticated remote code execution flaw, was used in automated attacks against more than half of all stores worldwide. PolyShell lets attackers upload executable files through the REST API, and we have seen exploitation attempts against 79.5% of stores. Earlier, merchants who waited more than two weeks to apply the June 2024 patch had their crypt keys stolen through CosmicSting, which we confirmed on more than 4,200 stores. With a crypt key, an attacker mints an admin API token, exports customer data and injects skimmers into CMS blocks.

2. Template code execution. The TrojanOrder attack runs arbitrary code by abusing Magento's email template parsing. Adobe fixed it in 2022. We still find newly hacked stores running the vulnerable code years later. An attacker places a crafted order, and the malicious payload fires when the confirmation email renders.

3. Outdated system libraries. A read-only attack often escalates to full server access through outdated Linux libraries such as glibc. Attackers chain this to drop backdoors directly on the host.

4. Stolen or guessed admin passwords. Leaked and reused credentials let attackers log straight into the admin panel. Weak passwords and missing two factor authentication turn a credential leak into a full breach.

5. Vulnerable third party extensions. Most stores run dozens of extensions, and that code is rarely audited. Skimmers and webshells hide in extension files and writable directories, where no version check will find them.

The targets are not small. Sansec has cleaned up breaches at Swatch, Ray-Ban, Cisco, Carlsberg, Segway, Whirlpool and many other well known brands.

Best practices for Magento security

1. Patch within hours

Apply every Adobe security release within hours of publication. Attackers reverse engineer patches the same day. Track the Adobe security bulletins and plan a deploy for each one.

Patching within hours still leaves a gap. With AI tools, attackers turn a published fix into a working exploit faster than most teams can test and deploy it. Scanners hit every Magento store within hours. Some attacks start before a fix exists. Attackers exploited StyleSmuggler, a Magento zero-day, from September 4, 2026. Sansec Shield blocked the attacks from 07:15 UTC on September 5, eight hours after we found the campaign. Adobe published its hotfix on September 7 at 20:20 UTC, almost three days after the first attacks. Merchants then still had to wait for their developers to deploy the hotfix. You need protection that is active before your patch is.

2. Block attacks with a web application firewall

A web application firewall (WAF) blocks exploit requests for a vulnerability you have not patched yet. Sansec Shield is a WAF for Magento. Sansec adds Shield rules for new Magento and PHP vulnerabilities. While you test and deploy the patch, Shield blocks the matching requests to your store during the first attack waves.

3. Enforce two factor authentication

Turn on Magento's built-in two factor authentication for every admin account. Require strong, unique passwords. Use role based permissions so each staff member only gets the access they need.

4. Put the backend behind a VPN

Make a VPN (such as WireGuard or Tailscale) the only way into the backend: the Magento admin panel, SSH and the database port. An attacker with a stolen admin password then also needs VPN access. A vulnerability in the admin panel can't be exploited from the internet. An IP allowlist does the same for staff with fixed addresses, but agencies and remote staff tend to grow it into a long, unmaintained list.

5. Make the code read-only

In production mode, Magento only needs to write to var/ and pub/media/ while it runs. Your deploy process writes generated/ and pub/static/, after which they stay read-only. Have a separate deploy user own all other files, and give the PHP process read access only, or mount the code directory read-only. An attacker who exploits a vulnerability then can't add a backdoor to a module, change index.php or inject a skimmer into a JavaScript file. Also block PHP execution in pub/media/ and var/ in your web server configuration, so an uploaded PHP file does not run.

6. Require signed commits

Attackers who steal a developer's git credentials or a deploy key can push malware into your source repository. Your next deploy then installs it on every server. If you clean a server and reinstall from the repository, you install the malware again. ConnectPOS exposed its GitHub credentials on its website for four years. Anyone who found them could have added malicious code to thousands of retail installations. Require signed commits on the branches you deploy from, for example with a GitHub branch protection rule, and have your deploy script reject unsigned commits. Give the production server a read-only deploy key, and keep signing keys off it.

7. Remove unused extensions and tools

Every extension, plugin and tool on the server is code an attacker can exploit, whether your store uses it or not. Use Composer to uninstall extensions you no longer need, so their files are deleted. Disabling a module in Magento leaves its code on disk, and some vulnerable modules can still be exploited while disabled. Delete database managers such as phpMyAdmin and Adminer from the server. Even a password-protected copy can be abused, and attackers also install these tools as backdoors. Also remove old test scripts, staging copies and backup archives from the web root. Review the list of installed extensions after every project and uninstall unused ones.

8. Disable GraphQL if you don't use it

Magento's /graphql endpoint accepts requests without a login, and every module with GraphQL support adds code that runs on those requests. StyleSmuggler attacks posted their payload to /graphql, and the Amasty disclosure included SQL injection through GraphQL. PWA Studio and other headless storefronts, mobile apps and some themes and extensions use GraphQL, so check with your developer first. If nothing uses it, disable the Magento modules with GraphQl in their name, or block /graphql in your web server configuration.

9. Keep the host system updated

A patched Magento on an outdated server is still exploitable. Apply security updates for the operating system, PHP and libraries like glibc on the same schedule as Magento patches. An outdated glibc lets attackers escalate a file-read bug such as CosmicSting to code execution.

10. Choose your hosting provider carefully

Most merchants rely on their hosting provider for part of their security. Before you sign or renew, ask the provider:

• What is your security policy?
• Which tasks do you take responsibility for in the contract: OS and PHP updates, Magento patches, a WAF, malware scans, backups?
• How fast do you apply a fix for a critical vulnerability?
• What did you do during PHP2Shell in October 2026? When was PHP updated on my server, and did you tell me?

If the contract does not name a task, plan to do it yourself.

11. Scan your files for malware

Adobe's free scan only checks core Magento and runs from the outside. It cannot see private extension code or writable directories, which is where most malware lives. Run eComscan on the server to detect skimmers, backdoors and known vulnerable extensions across the full codebase.

12. Set a Content Security Policy

A Content Security Policy limits which scripts the browser will run and stops many skimmers from exfiltrating card data even after an injection. See our Magento CSP guide.

13. Log database changes

Attackers often add skimmers to the database, for example to core_config_data or a CMS block. Version control does not record these changes, and MySQL does not log writes by default. Without a log, you can't tell when the skimmer was added. Use triggers to record every write to the tables attackers use, as described in our database audit log guide. The triggers have no impact on store performance.

14. Monitor and back up

Watch admin logins and file changes for anything unexpected, and keep automated off-site backups so you can recover fast after an incident.

15. Prepare to rotate your secrets

After a breach, you need to replace every secret the attacker could have read. Keep an inventory of them: database passwords, staff passwords, SSH keys, payment gateway credentials and API keys for third-party services. For each one, write down where it is used and how to replace it, and test the procedure before an incident.

Include the Magento crypt key. With this key, an attacker can sign an admin token for the REST API without a password, and that token works for as long as you keep the key. Rotating the key alone does not lock the attacker out: also reset all admin passwords and remove unknown API integrations. Our crypt key rotation guide lists the steps.