Adobe Commerce’s Zero-Day Is Patched—Stolen Keys Still Need Rotation

Adobe released an emergency hotfix for Adobe Commerce and Magento Open Source in its September 7 security bulletin. The company classifies CVE-2026-75650 as a critical, unauthenticated arbitrary-code-execution vulnerability, gives it a CVSS score of 10.0 and confirms that it has been exploited in the wild.

Installing the hotfix closes the vulnerable route, but it cannot reverse an intrusion that happened before installation. SecurityWeek’s September 8 report says affected operators should rotate the Commerce encryption key and every credential protected by it, including administrative passwords, database credentials, integration tokens, OAuth secrets, SSH and deployment keys, and API keys.

Which Adobe Commerce versions are affected

The official matrix covers multiple maintained branches and all platforms. Operators need to compare the complete installed version, including the dated release suffix, rather than assuming that a supported branch or an earlier clean patch-status result means the dedicated hotfix is present.

• Adobe Commerce: 2.4.9-2026-aug and earlier, 2.4.8-2026-aug and earlier, and the August 2026 releases and earlier in the 2.4.7, 2.4.6, 2.4.5 and 2.4.4 branches.
• Adobe Commerce B2B: 1.5.3-2026-aug and earlier, 1.5.2-2026-aug and earlier, and the August 2026 releases and earlier in the 1.4.2, 1.3.4 and 1.3.3 branches.
• Magento Open Source: 2.4.9-2026-aug and earlier, 2.4.8-2026-aug and earlier, and the August 2026 releases and earlier in the 2.4.7 and 2.4.6 branches.

The remedy is a hotfix for CVE-2026-75650 rather than proof that every deployment has already been updated. Each production node, administrative host, standby system, staging environment and restorable image that can return to service needs its own patch verification.

Patch every deployment before treating the entry point as closed

The first containment task is to inventory every place where the affected application can run, apply the appropriate hotfix and verify its status on each live instance. A completed package upload or successful CI/CD job does not establish that every node loaded the corrected code.

Any system that cannot be verified should remain an explicit exception rather than disappearing behind an overall “patched” status. One reachable, vulnerable clone or standby host can preserve the entry point even when the primary storefront has been updated.

Patch verification is only the boundary between stopping new exploitation through this flaw and investigating what may already have happened. It does not remove a web shell, terminate a malicious process, delete an unauthorized account or invalidate a copied credential.

Active exploitation means the host must be investigated

Sansec’s StyleSmuggler investigation places the first observed attacks on September 4 and documents changing payloads, malicious background processes, cron-based persistence, a Rust backdoor and PHP web-shell activity. That evidence makes an application-only file check too narrow for affected environments.

The compromise hunt should cover unexpected PHP files in writable directories, modified application files, suspicious report entries, unauthorized scheduled tasks, unfamiliar administrator changes, unusual authentication events, outbound connections and processes masquerading as ordinary system services. Investigators should also review the period before the hotfix was installed, because a clean system state after patching does not explain earlier execution.

Relevant logs and suspicious artifacts should be preserved before files are deleted or hosts are rebuilt. If available evidence cannot establish whether attacker-controlled code ran or secrets were accessed, the uncertainty belongs in the recovery decision; a clean malware scan alone cannot prove that credentials were not copied.

Why rotating only the Commerce encryption key falls short

The Commerce encryption key protects stored values inside the application. Rotating it changes how Commerce encrypts those values, but it does not revoke a password, token or private key that an attacker may already have extracted in usable form.

Revocation takes effect at the system that authenticates the credential. A database password must be changed at the database, an API key at its provider, an OAuth secret at the authorization service, and an SSH or deployment key wherever its public counterpart grants access. Merely replacing a value in Commerce configuration can interrupt the application while leaving the attacker’s copy valid.

Recovery should follow an order that avoids placing fresh secrets on a system that may still be controlled:

1. Contain suspect systems, inventory all affected deployments and apply the hotfix.
2. Verify installation on each instance and preserve evidence needed for investigation.
3. Hunt for web shells, backdoors, unauthorized accounts, scheduled persistence and suspicious host activity.
4. Remove persistence or rebuild compromised systems from trusted components before introducing replacement secrets.
5. Rotate the Commerce encryption key using the supported procedure.
6. Replace administrative passwords, database credentials, integration tokens, OAuth client secrets, payment-provider credentials, third-party extension keys, SSH keys and deployment credentials at their original issuers.
7. Update approved secret stores and application configuration, revoke the previous values, and monitor for attempted use of retired credentials.

The hotfix is available, but the compromise count remains unknown

The established position is that CVE-2026-75650 exposed affected Adobe Commerce and Magento Open Source installations to arbitrary code execution without authentication, exploitation occurred before the emergency fix became available, and post-exploitation persistence has been observed. Public information does not yet establish how many stores were compromised or whether investigators have identified every payload variant.

A defensible recovery state therefore requires more than a patched label. It combines verified hotfix coverage, a documented compromise assessment, removal of discovered persistence, source-level revocation of potentially exposed credentials and monitoring for attempts to reuse the retired access.

Also read:

• A Beautiful Online Store Can Still Lose the Sale: Fix the Buying Path
• The LEVEL5 Astronomy Glossary Still Works—But Its 2002 Entries Need Checking
• Creative AI Is Core for 75% of Users—but Most Outputs Still Need Editing