In October 2025, Sansec reported that 16–18% of all Magento stores had at least one backdoor injected six weeks after Adobe had already released a patch for the vulnerability being exploited (CVE-2025-54236, known as SessionReaper). The stores weren't hit because the patch didn't exist. They were hit because only 38% of stores had applied it. That gap — between patches released and patches installed is where most Magento breaches happen.
The threat landscape for Magento in 2026 has two converging pressures. First, Adobe moved to a monthly isolated security fix schedule starting January 2026, which means patch frequency has increased. The most recent bulletin, APSB26-49, was released on May 12, 2026 and addresses arbitrary code execution, privilege escalation, and denial-of-service vulnerabilities. Second, PCI DSS 4.0.1 became fully mandatory on March 31, 2025, adding new requirements around script management on payment pages that many stores are still not meeting. Sansec noted as recently as March 2026 that most stores had not enabled CSP reporting, a direct requirement under PCI DSS 4.0.
This guide covers every layer of Magento 2 security that matters right now core updates, admin panel hardening, server configuration, extension vetting, encryption, session protection, PCI DSS compliance, and monitoring. At the end is a practical 24-point checklist you can action immediately.
Why Magento Stores Are a Persistent Target?
Magento and Adobe Commerce collectively power a substantial share of mid-to-enterprise ecommerce. That scale makes them worth attacking. Sansec identifies an average of 30 new web skimming (Magecart) malware signatures every day, and the platform has been a Magecart target since 2015, when a critical vulnerability exposed over 3,000 stores in a single month. By 2022, Sansec had identified over 70,000 compromised Magento stores that had contained a digital skimmer at some point.
The financial cost of getting this wrong is concrete. IBM's Cost of a Data Breach Report 2025 puts the global average breach cost at $4.44 million. In the US, the average is $10.22 million, a record high. For ecommerce specifically, the Verizon DBIR 2025 attributes credential abuse as the vector in 22% of all breaches, and vulnerability exploitation jumped 34% year-over-year, with the median time from public disclosure to mass exploitation now measured in days, not weeks.
Magento-specific risks compound this. The 2024 CosmicSting vulnerability (CVE-2024-34102) affected 75% of Adobe Commerce and Magento stores and Sansec noted that one week after the patch was released, three quarters of stores were still unpatched. SessionReaper in 2025 showed the same pattern: high severity, available patch, low adoption. These aren't edge cases. They're the main attack surface.
1. Keep Magento Patched - Starting with APSB26-49
Adobe's patch schedule changed in January 2026. Instead of quarterly releases, the platform now follows a monthly isolated security fix schedule, meaning there are more patches, released more frequently, and the window between disclosure and exploitation is shorter than it used to be.
The latest bulletin, APSB26-49 (May 12, 2026), addresses multiple critical vulnerabilities including arbitrary code execution, privilege escalation, security feature bypass, and denial-of-service. If your store is running Adobe Commerce or Magento Open Source versions prior to the latest patched releases - 2.4.8-p4, 2.4.7-p10, 2.4.6-p14, or 2.4.5-p17, it is exposed to these vulnerabilities. Apply immediately.
The correct process for applying patches without breaking a live store:
- Test every patch in a staging environment that mirrors production. Don't skip this, even for urgent patches.
- Check all installed third-party extensions for compatibility before deploying to production.
- Back up the database and files before applying any patch.
- After applying, run Adobe's free Magento Security Scan Tool to confirm the patch registered correctly.
- Schedule patch reviews at minimum monthly so no bulletin sits unreviewed.
For stores still running end-of-life versions: Magento Open Source 2.4.4 has no extended security support. Extended support for 2.4.5 is available to Adobe Commerce customers only, not for Open Source users. If your store is on an unsupported version, upgrade planning is a security task, not a roadmap item.
2. Harden the Admin Panel
The admin panel is the highest-value target in a Magento store. Getting in through admin access means full control over products, orders, customer data, payment configurations, and file system access through theme editors. Most successful attacks either start at the admin panel or eventually reach it.
Use a Custom Admin URL
Magento 2's default admin URL is /admin. Change it. This isn't a substitute for real security, but it eliminates automated bots that hammer the default path. Set a custom path in app/etc/env.php or via the admin configuration under Stores > Configuration > Advanced > Admin.
Restrict Admin Access by IP
Allowlist specific IP addresses for admin access at the server level. If your team works from fixed IPs office, VPN, development machines only those IPs should reach the admin login page at all. Everything else should get a 403 before it hits Magento.
Enable Two-Factor Authentication
Magento 2.4+ enables 2FA by default and cannot disable it without a module. Don't disable it. Admins authenticate via a TOTP app (Google Authenticator, Authy). Even if a password is compromised — through phishing, a reused credential from another breach, or a keylogger 2FA stops the login. Credential abuse is the most common single breach vector according to Verizon 2025, and MFA is the most direct control against it.
Disable Admin Account Sharing
Navigate to Stores > Configuration > Advanced > Admin > Security and disable shared logins. With shared credentials, you can't track who made what change, you can't isolate a compromised session, and a password reset by one person locks out everyone else using it. Each admin user gets a unique account. The principle of least privilege applies here — grant each role only the access it needs, no more.
Set Admin Session Timeout
Configure session lifetime to 15–30 minutes under Stores > Configuration > Advanced > Admin > Security > Admin Session Lifetime. An unattended logged-in admin session — on a shared computer, in a coffee shop, after someone forgets to log out — is an open door. Session expiration closes it automatically.
Enable reCAPTCHA on All Login Forms
Magento 2.4+ includes Google reCAPTCHA v3 for admin and customer-facing forms. Enable it on the admin login, customer account login, registration, checkout, and password reset forms. This blocks credential stuffing and brute-force attempts without requiring a visible challenge for legitimate users.
Magento 2 Security Checklist (24 Critical Actions)?
The table below is a complete, prioritized checklist. Use it for initial hardening and as a recurring audit tool.
|
Security Action |
Category |
Priority |
Frequency |
|
Apply all security patches (latest: APSB26-49) |
Core |
Critical |
Monthly (from Jan 2026) |
|
Enable Two-Factor Authentication for admin |
Admin Security |
Critical |
One-time setup |
|
Use a custom admin URL (not /admin) |
Admin Security |
High |
One-time setup |
|
Restrict admin access by IP allowlist |
Admin Security |
High |
One-time setup |
|
Enable Google reCAPTCHA on all forms |
Admin Security |
High |
One-time setup |
|
Disable admin account sharing |
Admin Security |
Medium |
One-time setup |
|
Set admin session timeout (15–30 min) |
Admin Security |
Medium |
One-time setup |
|
Run Adobe's free Security Scan Tool |
Monitoring |
High |
Weekly |
|
Enable SSL/HTTPS across all pages |
Encryption |
Critical |
One-time setup |
|
Rotate encryption key periodically (CLI) |
Encryption |
High |
Quarterly |
|
Enable session validation variables |
Session Security |
High |
One-time setup |
|
Vet all extensions before installation |
Extensions |
High |
Per extension install |
|
Audit and remove unused/inactive extensions |
Extensions |
Medium |
Quarterly |
|
Implement a Web Application Firewall (WAF) |
Server |
High |
One-time setup |
|
Harden server: disable unnecessary services |
Server |
High |
One-time setup |
|
Configure Content Security Policy headers |
PCI DSS 4.0.1 |
High |
One-time + review |
|
Implement SRI for third-party scripts |
PCI DSS 4.0.1 |
High |
One-time + review |
|
Enable file integrity monitoring (FIM) |
Monitoring |
High |
Ongoing |
|
Set up automated daily/weekly backups |
Recovery |
Critical |
Daily/weekly |
|
Test backup restoration quarterly |
Recovery |
High |
Quarterly |
|
Apply principle of least privilege to roles |
Access Control |
High |
On user creation |
|
Enable admin action log monitoring |
Monitoring |
Medium |
Ongoing |
|
Keep PHP, MySQL/MariaDB dependencies updated |
Server |
High |
Per release |
|
Use a dedicated Magento security audit service |
Proactive |
Recommended |
Annually |
3. Vet Every Extension Before Installing
Third-party extensions are one of the primary attack surfaces in Magento. In May 2025, Sansec uncovered a coordinated supply chain attack where 21 Magento extensions from three vendors - Tigren, Magesolution, and Meetanshi, contained backdoors that had been injected six years earlier but activated simultaneously in 2025. Stores using these extensions silently ran Magecart-style skimming code without any visible sign of compromise.
Every extension you install has write access to your codebase. That's the nature of how Magento extensions work — they integrate at the framework level, not as isolated plugins. The vendor's security practices, update cadence, and access controls over their own codebase become your risk.
Before installing any extension:
- Buy only from the Adobe Commerce Marketplace or the extension developer's official site. Avoid nulled, cracked, or pirated extensions — they reliably contain malware.
- Check when the extension was last updated. An extension with no updates in two years likely has unpatched vulnerabilities and no support for current PHP/Magento versions.
- Verify the developer's reputation: check their response to past security reports, their own website's SSL status, and whether they have a responsible disclosure policy.
- After installing any extension from the Marketplace, verify it against Adobe's free Security Scan Tool to detect any injected code.
Audit your installed extensions quarterly. Remove anything unused, unmaintained, or unverified. Every inactive extension is dead code with a potential vulnerability that never gets patched.
For a higher-confidence starting point, MageDelight's extension catalog is built by a team that follows Magento coding standards and offers active support and updates.
4. Manage Encryption Keys Correctly
Magento uses ChaCha20-Poly1305 encryption for sensitive stored data, credit card information in transit, payment module passwords, and shipping credentials and SHA-256 hashing for data that doesn't require decryption. This is solid cryptography. The risk is in key management: if the encryption key is compromised, all encrypted data is compromised.
Starting with Magento 2.4.8, the Admin UI option to change the encryption key was removed. Key rotation now requires CLI access: enable maintenance mode, run the encryption key rotation command, flush cache, disable maintenance mode. Adobe's official guidance on encryption key management is the authoritative reference. Rotate your encryption key immediately if: a developer with key access leaves the team, you suspect any unauthorized server access, or the key has not been rotated in over a year.
Do not store the encryption key in version control. Do not keep it in a shared document or password file without proper access controls. It belongs in a secrets manager - HashiCorp Vault, AWS Secrets Manager, or equivalent.
5. Enable Session Validation
Magento 2 includes built-in session validation variables that compare stored session data against incoming requests. If the values don't match, the session terminates immediately. This protects against session hijacking where an attacker intercepts a valid session token and uses it to impersonate a logged-in user. SessionReaper (CVE-2025-54236), the most severe Magento vulnerability of 2025 by Sansec's assessment, exploited session handling directly. Patching the vulnerability is the fix; enabling all session validation variables reduces exposure to similar bugs.
Enable these under Stores > Configuration > General > Web > Session Validation Settings. The trade-off: enabling all validation variables can add minor server overhead. On modern infrastructure this rarely matters at scale. The protection is worth it.
Also set these session security configurations:
- Use database session storage rather than file-based storage, file-based sessions are more vulnerable to local file inclusion attacks.
- Set admin session lifetime to match your policy (15–30 minutes).
- Ensure session cookies are set with the HttpOnly and Secure flags to prevent JavaScript access and unencrypted transmission.
6. Meet PCI DSS 4.0.1 Requirements for Payment Pages
PCI DSS 4.0.1 became fully mandatory on March 31, 2025. Every previous transitional grace period for the new requirements has expired. Two requirements hit Magento stores hardest:
Requirement 6.4.3 - Script Management on Payment Pages
Every script loaded on a payment page must be authorized, its integrity verified, and its purpose documented. In practice this means implementing Subresource Integrity (SRI) checks for third-party scripts (analytics, chat widgets, ad pixels) and maintaining an inventory of all scripts with documented business justification for each. Sansec noted in March 2026 that most stores had still not enabled CSP reporting despite this requirement being enforceable for over a year.
Requirement 11.6.1 - Tamper Detection on Payment Pages
Your payment pages must detect unauthorized modification in real time. A server-side scan won't catch a Magecart skimmer that injects JavaScript through a compromised CDN or analytics provider the malicious code never touches your server. You need client-side monitoring that fires if payment page scripts or HTTP security headers are modified unexpectedly.
Implementation approach for both requirements:
- Implement Content Security Policy (CSP) headers that whitelist allowed script sources for payment pages.
- Add SRI hashes to all third-party scripts on checkout and payment pages.
- Deploy a client-side monitoring tool that alerts on script tampering or unexpected network requests from payment pages.
- Conduct a full script inventory audit most stores are surprised how many third-party scripts load on checkout.
For the payment processing setup itself: use hosted payment forms or iFrame-based payment integrations that keep cardholder data off your server. Adobe Commerce's Direct Post and hosted payment form methods route card data directly to the payment gateway without it passing through your Magento server. This significantly reduces your PCI compliance scope.
7. Harden Your Server Environment
Magento's application-level security only works if the server underneath it is properly configured. Quality hosting with a Web Application Firewall is not optional for any production Magento store handling real orders.
Web Application Firewall (WAF)
A WAF filters malicious HTTP requests before they reach Magento. It blocks SQL injection attempts, XSS payloads, path traversal requests, and known exploit patterns for Magento vulnerabilities. Adobe Commerce on Cloud includes a WAF; for Magento Open Source on-premises, deploy one at the server or CDN level (Cloudflare, Fastly, Sucuri, or a server-level ModSecurity ruleset).
Keep Dependencies Current
Note that MySQL 8.0 reaches End of Support on April 30, 2026. Adobe Commerce 2.4.5 and 2.4.7 will not provide support or compatibility validation for MySQL versions beyond 8.0. If you're running MySQL, migrate to a compatible MariaDB version now. PHP version compatibility also matters — Magento 2.4.7+ supports PHP 8.2 and 8.3. Running an EOL PHP version means your server isn't receiving security patches.
Disable Unnecessary Services and Access Points
- Disable the Magento Downloader, never install extensions directly from the admin panel.
- Restrict file write permissions: the Magento application doesn't need write access to its own core files.
- Disable XML-RPC if not in use.
- Block direct access to sensitive directories and files through your web server configuration (.htaccess, nginx rules).
- Use SSH key authentication for server access; disable password-based SSH login.
8. Monitor Continuously - Don't Rely on Periodic Scans Alone
The average breach lifecycle in 2025 was 241 days - 181 days to detect and 60 to contain - according to the IBM Cost of a Data Breach Report 2025. For a Magecart skimmer quietly collecting payment data in the background, 181 days of undetected operation is a significant amount of customer card data. Monitoring reduces detection time. Periodic scans are better than nothing but they miss real-time injection.
Monitoring measures to implement:
- Run Adobe's Magento Security Scan Tool weekly. It checks patch status, known vulnerabilities, and signs of malware injection. It's free for Magento merchants.
- Enable file integrity monitoring (FIM) to alert on unexpected changes to core Magento files. Any modification to a core file that you didn't initiate is a sign of compromise.
- Monitor admin action logs regularly. Unusual login times, logins from unfamiliar IP addresses, or unexpected admin user creation are early warning signs.
- Set up server-level log monitoring with alerts for failed login attempts, unusual traffic patterns, and requests to sensitive admin endpoints.
- Consider a dedicated ecommerce security monitoring service. Sansec's eComscan is the most comprehensive tool specifically for Magento/Adobe Commerce skimmer detection.
9. Backups Are a Security Control, Not Just a Recovery Tool
Ransomware is the scenario that makes this clear. A store that gets hit with ransomware — encrypted files, locked database, ransom demand — has two options: pay, or restore from backup. The 3-2-1 backup rule applies: three copies of data, on two different media types, one stored offsite. For a Magento store this means: automated daily backups of database and files, stored on a separate server or cloud storage (not just the same server), with at least one copy in a separate location or cloud account.
The critical step that most stores skip: test your backups. A backup you've never restored from is a backup you don't know works. Run a full restoration to a staging environment quarterly. Time the process. Know how long recovery takes before you need it under pressure.
- Automate daily database backups and verify their completion with an alert if they fail.
- Keep at least 30 days of daily backups and 12 months of monthly snapshots.
- Store backups in a location that's inaccessible from the web server, an attacker who compromises your server shouldn't be able to delete your backups.
- Document and test your recovery plan. This is a security requirement under PCI DSS Requirement 12 and a practical necessity.
10. Get a Professional Magento Security Audit
The Magento Security Scan Tool is useful but not comprehensive. A full security audit covers what automated tools miss: custom code vulnerabilities, misconfigured server settings, overly permissive admin roles, insecure third-party integrations, and client-side script exposure that server-side tools can't see.
A proper Magento security audit should check: the current Magento version and all applied patches, third-party extension inventory and their security posture, admin user roles and permissions, server configuration and web server rules, SSL/TLS configuration, file permissions, backup status, PCI DSS 4.0 compliance for payment pages, and known CVE exposure. MageDelight's Magento development and security services include a security review as part of their support and maintenance offering backed by a full-service team including Hyvä developers, migration specialists, and 24x7 support.
For stores that haven't had a dedicated security review in over 12 months, or that have recently added significant custom code or new extensions, a professional audit is the most efficient way to find issues before attackers do.
Which Security Measures Should You Prioritize First?
Not all stores are starting from the same baseline. Here's a scenario-based guide.
If your store hasn't applied the latest security patch: Stop everything else and apply APSB26-49 immediately. Known, unpatched vulnerabilities are the most exploited attack vector in Magento. Test in staging first, then push to production. Every day without the patch is exposure to actively-exploited code.
If your admin panel uses the default /admin URL or has no IP restriction: Fix these before anything else in the admin hardening section. These are the lowest-effort, highest-impact changes. A custom admin URL and IP allowlist stop automated attacks cold.
If you process payments directly through checkout (not via iframe/redirect): PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 apply to you and are already enforceable. Prioritize CSP implementation, SRI for third-party scripts, and a payment page script inventory. Non-compliance exposure includes card brand fines and potentially losing payment processing capability.
If you've recently installed third-party extensions without auditing them: Audit your extension list now. Remove anything unused. For extensions you're keeping, verify they were installed from legitimate sources, check update dates, and run a Magento Security Scan to check for malware signatures.
If you've never tested your backup restoration: Run a restoration drill to staging this week. You need to know the process works and how long it takes before you're under pressure from an incident.
Final Thoughts
Most Magento breaches are preventable. SessionReaper, CosmicSting, the 2025 supply chain attack on extension vendors — these all had patches or mitigations available. The stores that got hit were running behind on updates, using unvetted extensions, or operating without monitoring. The threat isn't sophisticated; it's patient.
The 24-point checklist in this article covers every layer: patches, admin hardening, extension security, encryption, session protection, PCI DSS compliance, server configuration, monitoring, and backups. Work through it systematically. Start with patches and admin hardening — those two categories cover the majority of common attack vectors. MageDelight's Magento 2 extension ecosystem and support services are designed around stores that take security seriously — actively maintained extensions, compatibility-tested updates, and a development team available for Magento security audits and maintenance when you need more than the checklist.
The Adobe Commerce Security Scan Tool is free and available right now. Running it takes under five minutes and gives you an immediate baseline. Start there.



