Magento crypt key rotation

The Magento crypt key (the crypt/key value in app/etc/env.php) encrypts stored secrets and signs the JSON Web Tokens that grant access to the admin REST API. When attackers read this key, through CosmicSting or any other file-read flaw, they can mint their own admin API tokens and control your store without ever touching the admin login. Rotating the key is how you take that capability away.

In our forensic work we keep seeing stores that rotated the key and assumed they were clean, only to find the attacker still had access weeks later. Rotation closes one door. It does not close the others. This guide covers how to rotate the key properly and the steps that must go with it.

What rotation does and does not do

Key rotation invalidates tokens that were forged from the stolen key. That is the CosmicSting path, and closing it matters.

Rotation does not revoke access that does not depend on the key:

• Admin and integration API tokens are stored in the database, not derived from the key. Magento keeps active bearer tokens in the oauth_token table as plaintext values. They are not encrypted with the crypt key, so rotating the key neither revokes them nor expires them. Integration tokens in particular never expire on their own. An attacker who created an integration keeps working through it after you rotate.
• Admin passwords are not derived from the key. A reset of the key does not change any password or end any logged-in session.
• A new key gets stolen again if the underlying leak is open. If the file-read vulnerability that exposed the first key is still present, the attacker simply reads the new key and mints fresh tokens. Patch the root cause before, or at the same time as, rotating.

So rotation is necessary but never sufficient. Treat it as one item in the full lockdown below.

How to rotate the key

1. Patch the root cause first. Apply all relevant Adobe security patches so the new key cannot be read straight back out. Rotating before patching wastes the effort.

2. Generate a new key and re-encrypt stored secrets. Adobe provides built-in functionality to change the encryption key, which also re-encrypts existing secrets with the new key. See Adobe's encryption key rotation troubleshooting guide for edge cases.

3. Invalidate the old key. Generating a new key does not invalidate the old one. Magento keeps every key version in app/etc/env.php under crypt/key (newline-separated, oldest first), and tokens forged from any listed version still validate. To close the stolen key, replace its value rather than only appending a new one. The encryption key manager module from GENE Commerce automates rotation and re-encryption and is worth using here.

   Before you drop an old key value, confirm nothing still depends on it. Stored secrets and some integration records are tied to the key version that encrypted them. Removing a key that legacy data still relies on will break that data, so re-encrypt first, then remove.

4. Flush caches so the change takes effect:

   bin/magento cache:flush
   

Rotation is not enough: the full lockdown

Rotate the key as part of a single coordinated lockdown, not on its own. Do all of these together so an attacker cannot use one path to re-establish another.

1. Reset all admin passwords and disable or delete any admin user you do not recognise. See how to change all Magento admin passwords. Invalidate active admin sessions as well.

2. Purge API tokens and remove unknown integrations. This is the step most cleanups miss. Review System > Extensions > Integrations in the admin and delete any integration you cannot positively account for. Attacker-created integrations often carry generic, sequential names (Integration2, Integration3) and grant permanent tokens that survive password and key rotation. At the database level, the live tokens are in oauth_token and the integrations in oauth_consumer. Clearing the stale token rows and deleting the rogue integrations is what actually ends that access. Also shorten the admin and customer token lifetimes so any token you miss expires sooner.

3. Rotate the rest of the secrets. Change the database password, rotate SSH keys and hosting account credentials, and rotate payment and third-party integration secrets. Update app/etc/env.php accordingly.

4. Block the attacker. Block known attacker IPs and restrict the admin REST token endpoint (/rest/*/V1/integration/admin/token) and the admin panel to a small set of trusted IPs. That token endpoint bypasses admin IP restrictions and two-factor authentication, so it is a common re-entry point.

5. Scan and verify. Run eComscan again after cleanup to confirm no backdoors remain, and confirm the storefront is clean. For the wider incident response process, see malware or vulnerability found, what next?.

Stay protected

Sansec Shield blocks the attacks that lead to crypt key theft, including exploitation of flaws you have not patched yet. Combined with eComscan for server-side detection, it stops the leak that makes key rotation necessary in the first place.