Magento and Adobe Commerce security: harden the admin, patch fast, stop skimming

Magento and Adobe Commerce stores are attacked because a single unauthenticated flaw can turn into a card skimmer on every checkout within hours. The pattern has repeated for years: a critical bug is published in an Adobe security bulletin (APSB), mass scanning starts within days, attackers steal the store's encryption key or plant a backdoor, then inject JavaScript that copies payment data. This guide covers the controls that break that chain on Adobe Commerce and Magento Open Source 2.4.x: admin hardening and 2FA, patch cadence and version support, the encryption key in app/etc/env.php, extension risk, Content Security Policy on payment pages, and detection. It is written for ecommerce engineers, agency and hosting teams, and the security people who sign off PCI DSS for a Magento estate.

Key takeaways

• Patch speed is the main control. CVE-2024-34102 (CosmicSting) and CVE-2025-54236 (SessionReaper) were both unauthenticated, both rated Priority 1 after exploitation began, and both are in the CISA Known Exploited Vulnerabilities catalogue.
• The encryption key is a credential. The key in app/etc/env.php protects payment and integration secrets and, in the CosmicSting campaigns, was stolen to forge API tokens; rotate it after any suspected file read.
• Patching is not cleaning. A store that was exploited before it was patched may still hold a skimmer in CMS blocks, a rogue integration, an extra admin user or a web shell.
• The admin is the crown jewel. Custom admin path, 2FA, network allowlisting, short sessions and least-privilege roles shrink the most abused entry point.
• Every extension is your code. Third-party modules run with full application privileges; fewer, maintained, reviewed extensions are a security decision, not only a performance one.

How Magento stores get compromised

Most incidents follow one of four routes. Knowing which one you are defending against decides where to spend effort.

The end goal is usually the same: JavaScript in the checkout that copies card data and posts it to an attacker domain, which ATT&CK tracks as T1056.003 Web Portal Capture. Sansec reported that in the CosmicSting campaigns attackers read the encryption key from env.php, forged a JSON Web Token with unrestricted API access, then edited CMS blocks to append skimming scripts; it also reported groups compromising more than 2,000 stores in a few hours in October 2024. See the Client-Side Security Guide for the browser side of the problem.

Patching, APSB bulletins and version support

Adobe publishes Commerce fixes as APSB bulletins on its security bulletin index, which now points to the Adobe Trust Center. Adobe's best practices note that security updates usually ship quarterly, but out-of-band bulletins happen: in 2026 alone the index lists APSB26-05 (10 March), APSB26-49 (12 May), APSB26-73 (14 July), APSB26-92 (11 August), APSB26-146 (7 September) and APSB26-138 (8 September). Subscribe to the Adobe Security Notification Service and read the priority rating, not only the CVSS score: Adobe raises the priority when exploitation starts.

Support windows

Adobe gives each 2.4 release three years of standard support from general availability. Its lifecycle policy currently lists end of standard support as 31 May 2027 for 2.4.7, 31 May 2028 for 2.4.8 and 31 May 2029 for 2.4.9; 2.4.6 left standard support on 11 August 2026 and is in extended support until 31 August 2027, with a final security-only period to 31 May 2028. 2.4.4 and 2.4.5 are in a security-only period ending 31 May 2027. From 1 June 2027 Adobe says it will stop maintaining cloud environments on unsupported versions. PHP matters as well: the same page notes PHP 8.1 reached end of life on 31 December 2025 and PHP 8.2 does so on 31 December 2026, and warns that PCI compliance is at risk on those versions. Magento 1 has been out of support since June 2020 and any remaining Magento 1 store should be treated as a migration emergency rather than a hardening project.

• Emergency path: when a bulletin is Priority 1 or the CVE appears in KEV, apply the isolated patch or hotfix within 72 hours, even if the full patch release takes longer to test.
• Normal path: move to the next -pN security release within the quarter; test on staging with a copy of production configuration (minus live payment credentials).
• Compensating control: a WAF virtual patch buys hours, not weeks. It does not replace the code fix. See the Web Application Firewall Guide.

See the Patch Management Guide for cadence and exception handling across an estate.

Hardening the Admin

Adobe's own launch checklist puts Admin protection first. The settings live under Stores > Settings > Configuration > Advanced > Admin > Security unless noted.

Do not forget the other doors. Cloud projects should turn on MFA for SSH, which Adobe documents for Commerce on Cloud. Hosting control panels, phpMyAdmin, staging sites and old subdomains running a copy of the store need the same treatment, because attackers find them through certificate transparency and DNS.

The encryption key and secrets in env.php

Adobe Commerce encrypts recoverable data, such as payment-related values and integration passwords, with ChaCha20-Poly1305 using a 256-bit key, and hashes data that never needs decrypting with SHA-256. The key sits in app/etc/env.php, the same file that holds database credentials and other environment settings. Anyone who can read that file can decrypt stored secrets, and CosmicSting showed it can also be used to mint valid API tokens.

Rotating the key

The Admin route (System > Other Settings > Manage Encryption Key) was removed in 2.4.8; use the CLI. Adobe's documented order:

1. Enable maintenance mode: bin/magento maintenance:enable.
2. Disable cron (./vendor/bin/ece-tools cron:disable on cloud, edit the crontab on premises).
3. Run bin/magento encryption:key:change and confirm it completes without errors.
4. Flush the cache (bin/magento cache:flush, or magento-cloud cc on cloud).
5. Re-enable cron, then bin/magento maintenance:disable.
6. Store the new key in your secrets manager or vault, not in a ticket or chat.

Rotation logs out every customer and Admin session except integration users. Sansec notes that rotation stops forged tokens but does not revoke API tokens already stored in the database, so after a suspected compromise also reset Admin passwords, delete unknown integrations and reissue integration tokens. If specific configuration values or payment fields need re-encrypting, follow Adobe's data re-encryption guidance.

Where identity fits

A Magento store is full of non-human credentials: the encryption key, database user, Redis and search credentials, payment gateway API keys, ERP and PIM integration tokens, deployment SSH keys and CI secrets. Treat each one as an identity with an owner, a scope and a rotation date.

• Lock sensitive values: use bin/magento config:set with --lock-env or --lock-config so payment and integration settings are written to env.php or config.php and cannot be changed from a compromised Admin session. Adobe's checklist recommends this.
• File permissions: env.php should be readable only by the web server user, and the code base read-only in production where the deployment model allows it.
• Integrations: review System > Extensions > Integrations monthly; every integration should map to a named system and owner, with the narrowest resource access.
• Repositories: env.php must never be committed; scan repositories and backups for it.

See the Secrets Management Guide and the API Key Management Guide for the wider programme.

Extensions and custom code

Extensions run inside the application with the same database access as core. Adobe's guidance is to source extensions only from the Adobe Commerce Marketplace or through your integrator, to keep the number of extensions and vendors low, and to review extension code before integration. Its extension developer guide tells developers to avoid eval, serialize and unserialize on untrusted input, md5 for sensitive hashing, predictable srand and mt_srand seeding, and unsafe use of ArrayObject.

• Never use nulled extensions: pirated copies of paid modules are a common way backdoors arrive.
• Inventory with Composer: composer.lock is your software bill of materials; track it in a dependency scanner so extension advisories reach you.
• Clean the docroot: Adobe tells merchants to check for leftover .git directories, accessible logs, SQL dumps, phpinfo files and SQL tunnels.

See the PHP and WordPress Security Guide for PHP-level hardening that applies equally to Magento hosts.

Stopping web skimming at the checkout

From 2.4.7, Magento's CSP module runs payment pages in the storefront and Admin in restrict mode by default and removes unsafe-inline from script-src on those pages, so only allowlisted inline scripts run. All other pages stay in report-only mode, and before 2.4.7 everything was report-only. This is a real control against injected scripts, but only if you keep the allowlist tight.

• Allowlist per directive: add hosts in a module's etc/csp_whitelist.xml to the specific directive that needs them (script-src, connect-src), never to default-src. Each entry is a door a skimmer can use to send data out, so connect-src deserves the closest review.
• Nonces for inline code: from 2.4.7, use Magento\Csp\Helper\CspNonceProvider::generateNonce() and SecureHtmlRenderer rather than adding hashes for every inline block.
• Collect reports: set a report URI under Stores > Settings > Configuration > Security > Content Security Policy, with separate URIs for the Checkout and Admin Create Order pages, and alert on new blocked domains.
• Extend restrict mode: once reports are quiet, set default/csp/mode/storefront/report_only to 0 for more pages; skimmers sometimes sit on cart or account pages to capture data before checkout.
• Script inventory and change detection: PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 require an inventory and authorisation of payment page scripts and a mechanism to detect unauthorised changes. See the PCI DSS for E-commerce Payment Page Scripts Guide, the Content Security Policy Guide and the Subresource Integrity (SRI) Guide.

Hosted payment fields or redirect payment pages from your payment service provider reduce how much card data your page can touch, but a skimmer can still overlay a fake form, so CSP and change detection still apply.

How to implement: a phased plan

1. Week 1, exposure: record every store, staging and old instance with version, patch level, PHP version and hosting. Check each against the lifecycle table and the latest APSB. Patch anything missing a Priority 1 fix first.
2. Week 1, assume breach on unpatched stores: if a store ran a vulnerable version after exploitation began, hunt before you call it clean: review Admin users, integrations, CMS blocks and pages, Design > Configuration HTML head and footer fields, core_config_data for script tags, and recently modified PHP files. Use the Web Skimming Incident Playbook if you find anything.
3. Week 2, keys and credentials: rotate the encryption key on any store that was exposed, reset Admin passwords, reissue integration and payment API keys, and lock sensitive settings to env.php.
4. Weeks 2 to 3, Admin: custom path, 2FA for everyone, network allowlist, lockout and session settings, role review. Pilot on one store, confirm agencies and support staff can still work, then roll out.
5. Weeks 3 to 6, checkout: confirm 2.4.7 or later CSP restrict mode on payment pages, wire up the report URI, build the payment script inventory, then extend restrict mode page by page. Roll back by setting report_only to 1 for the affected area if a legitimate script breaks.
6. Ongoing: enable the Security Scan Tool (weekly schedule recommended by Adobe), file integrity monitoring, a WAF, quarterly extension review, and a tested backup and configuration export.

Small merchants: a single store on managed hosting should focus on patching within days, 2FA, a custom Admin path, few extensions and hosted payment fields. Large estates and agencies: add central version tracking across stores, CI-based patch pipelines, a shared CSP report collector, and contractual patch SLAs with every agency and extension vendor.

Detection and measurement

• Security Scan Tool: Adobe's free scanner runs more than 21,000 tests for malware and misconfiguration from the Commerce/Magento account dashboard, on demand, daily or weekly.
• File integrity: alert on any new or changed PHP file outside a deployment, especially under pub/, media/ and generated/. See the File Integrity Monitoring Guide.
• Database watch: diff cms_block, cms_page and core_config_data daily for <script tags and new external domains.
• Admin and API events: new Admin users, role changes, new integrations, logins from new countries, and spikes in unauthenticated REST or GraphQL requests to customer and cart endpoints.
• Web logs: Sansec observed that CosmicSting key theft could succeed even when the request returned a 404, so do not dismiss odd requests on status code alone.

Common failure patterns

• Patching without rotating the key: after CosmicSting many stores patched but kept the old key, so forged tokens kept working. Adobe later issued a hotfix to invalidate old keys, and Sansec advises rotating after patching.
• Treating the patch as the end of the incident: skimmers stored in CMS blocks or configuration survive upgrades and redeployments because they live in the database, not the code.
• Agency and freelancer access left open: shared Admin accounts, old SSH keys and abandoned integrations from past projects give attackers valid access with no exploit needed.
• Staging and forgotten instances: an unpatched copy with production data or the same encryption key leaks the secrets of the live store.
• CSP left in report-only and unread: reports pile up with no one watching, or broad connect-src entries let a skimmer post data to an allowed domain.
• Running past end of support: Magento 1 or out-of-support 2.4 releases on end-of-life PHP receive no fixes, so every new bulletin becomes a permanent exposure.

Framework mapping

Relevant ATT&CK techniques: T1190 Exploit Public-Facing Application, T1078 Valid Accounts, T1195.002 Compromise Software Supply Chain, T1552.001 Credentials In Files, T1505.003 Web Shell and T1056.003 Web Portal Capture.

Practitioner checklist

• Every store, staging site and old instance is inventoried with version, patch level and PHP version, and all are inside Adobe support.
• Priority 1 APSB fixes and KEV-listed Commerce CVEs are applied within 72 hours; Adobe security notifications go to a monitored list.
• Stores that ran vulnerable versions were hunted for skimmers, rogue Admin users, integrations and web shells, not only patched.
• The encryption key was rotated with bin/magento encryption:key:change after any possible exposure, and the new key is held in a secrets manager.
• Admin uses a custom path, 2FA for every user, a network allowlist, lockout after 6 failures or fewer, and short sessions.
• Admin roles follow least privilege; integrations each have an owner and minimal resources.
• Extensions come from the Marketplace or a known vendor, are reviewed, and unused or abandoned modules are removed.
• Payment pages run CSP restrict mode with a tight allowlist, a monitored report URI and an authorised script inventory.
• File integrity monitoring, database diffing of CMS and configuration content, the Security Scan Tool and a WAF are in place.
• The Web Skimming Incident Playbook has been rehearsed with the agency, host and payment provider.

Standards and references

• Adobe Experience League: Security best practices for Adobe Commerce
• Adobe: Security bulletins and advisories for Adobe Commerce
• Adobe: APSB24-40 Security update available for Adobe Commerce
• Adobe: APSB25-88 Security update available for Adobe Commerce
• Adobe Experience League: Encryption key
• Adobe Developer: Content Security Policies in Adobe Commerce
• Adobe Experience League: Adobe Commerce lifecycle policy
• Sansec: CosmicSting research

Related NHI Mgmt Group resources: Web Skimming Incident Playbook · Cybersecurity for Retail and Ecommerce Guide · PCI DSS for E-commerce Payment Page Scripts Guide · Client-Side Security Guide · Secrets Management Guide