9 min read - Adobe Commerce zero-day: prove the fix, then rotate credentials

Adobe updated its emergency Commerce instructions on 8 September 2026 after releasing a hotfix the previous day. The company says CVE-2026-75650 has been exploited in the wild against Adobe Commerce merchants. Its response asks affected operators to apply the version-specific hotfix and rotate the encryption key plus the credentials that key may have protected.

That second action changes the management decision. A green deployment does not close the work if an attacker may have read a payment credential, integration token or deploy key before the hotfix landed. The response needs one owner who can connect the Commerce release, infrastructure evidence and third-party credential changes.

The response board below is for operators, agencies and technology leaders responsible for an Adobe Commerce or Magento Open Source installation. It is an operational synthesis, not a report about an Exceev client or a substitute for Adobe support and qualified incident response.

Treat the hotfix as an incident change

Adobe's security bulletin APSB26-146 rates the vulnerability critical with a CVSS base score of 10.0. It says an unauthenticated attacker can exploit improper neutralisation in a template engine to execute arbitrary code. Adobe lists affected Adobe Commerce branches from 2.4.4 through 2.4.9, affected Adobe Commerce B2B branches, and Magento Open Source branches from 2.4.6 through 2.4.9. The exact affected release notation and matching patches belong in the change record; a broad label such as "Magento 2" is too imprecise for approval.

The timing supports incident handling rather than an ordinary maintenance ticket. CERT-FR published its advisory on 8 September, confirming remote arbitrary code execution and active exploitation as reported by Adobe. Canada's Cyber Centre also reported on 8 September that CISA added CVE-2026-75650 to the Known Exploited Vulnerabilities catalog. Neither notice proves that a particular shop was compromised. They do remove the basis for waiting on a routine patch window merely because no alert has fired.

Give the response four connected workstreams:

One response owner should keep those records aligned. The people doing each task can differ, but separate tickets with no shared timeline make it easy to close the patch while a payment gateway credential remains valid.

Match the patch to the running release

Start with the build that actually serves traffic. Record the Commerce product, full version, hosting model and relevant B2B module version before changing it. If several storefronts share infrastructure, don't assume they share an identical patch state.

Adobe's 8 September instructions map current and earlier releases to several VULN-39341 patch archives. Use that live table rather than copying a filename from an incident chat. The page covers Adobe Commerce on Cloud, on-premises installations and Magento Open Source, but the application method and the verification step depend on the environment.

Test the applicable hotfix in a representative non-production environment if the exposure and business situation allow it. Capture checkout, order, transactional email and scheduled-job results that match the shop's real extensions. Emergency does not mean unrecorded: note who accepted any test gap and how the team will watch the affected path after deployment.

For Adobe Commerce on Cloud, Adobe documents a check with the Quality Patches Tool and the magento-patches status command. Preserve the output showing the VULN-39341 patch as applied. For other environments, follow the applicable Adobe instructions and keep equivalent deployment evidence. A successful pipeline or a file copied into a patch directory is not the same as proving the running application includes the change.

Rotate credentials at their source

Adobe's instruction is unusually explicit: rotating the Commerce encryption key alone does not invalidate credentials an attacker may already have read. The company tells merchants to rotate associated credentials at the payment provider or other source system as well as updating Commerce.

Build the credential list from configuration and integration inventories, not memory. Adobe names administrator passwords, REST, SOAP and GraphQL integration tokens, OAuth client secrets, payment gateway API credentials, database credentials, SSH or deploy keys, privileged service accounts, and API keys for shipping, tax and other extensions. A given shop may use only part of that list, or may have other extensions with their own secrets.

Sequence the work around dependencies. If a database credential changes before the application configuration can receive it, the storefront may fail while the incident is still active. If the team changes the local copy but leaves the old gateway key valid at the provider, the exposed credential still works. For each secret, record five things: the issuing system, account or integration, privilege, new activation time, and evidence that the former credential can no longer authenticate.

Don't paste old or new secrets into the response board. Store only identifiers, owners and status there, with the sensitive value kept in the approved secret system. Redact command output before adding it to a ticket, and treat logs from failed integrations as potentially sensitive during the change.

Adobe's documented sequence places the hotfix before maintenance mode, credential changes, cache flushing and return to service. Follow the current vendor procedure for the installed platform. The response owner should also decide when to pause checkout, scheduled jobs and integrations so retries do not create duplicate or partially processed business actions.

Investigate the pre-hotfix window

The Sansec Forensics Team's threat research calls the campaign StyleSmuggler and reports its first confirmed exploitation on 4 September. Sansec says it reproduced the unauthenticated chain on clean Magento Open Source 2.4.7, 2.4.8 and 2.4.9 installations. Its live report also describes several observed process names, files and network indicators.

Use those indicators as leads, not as a clean bill of health. Sansec describes an investigation that was still developing when reviewed on 9 September, and its observed payloads do not cover every action another attacker could take. The absence of a listed process or address therefore cannot prove that an internet-reachable affected shop stayed untouched.

Construct the exposure window from the last known unaffected state through the verified hotfix deployment. Review the evidence your environment retained: reverse-proxy and CDN requests, web and application logs, operating-system processes, scheduled tasks, changed files, outbound connections, administrator activity and integration-token use. Preserve original timestamps and copies before rebuilding or deleting suspect components.

NIST's final SP 800-61 Revision 3 places incident response within wider cybersecurity risk management and covers preparation, detection, response and recovery. That guidance does not analyse CVE-2026-75650. It supports the operating principle used here: the patch, investigation and recovery evidence belong in one managed response.

If the review finds unauthorised execution or persistence, escalate under the organisation's incident process. A blog post cannot decide the forensic scope, notification duties or safe recovery point for a specific merchant. Keep those decisions with the people who know the system, contracts and applicable law.

Protect the business path during recovery

Commerce incidents meet customers through failed checkouts, delayed orders and changed integrations. The technical team needs a short business map before it starts rotating access:

• Which payment, fulfilment, tax and customer-service connections may stop?
• Which queued jobs can replay, and how will operators detect duplicates?
• Which storefront functions can remain available without the affected integration?
• Who can approve maintenance mode and the return to normal traffic?
• Which customer or partner communications require legal and incident-owner review?

Use synthetic transactions after each high-impact change. Test the smallest set that proves the shop can accept an order, invoke the intended provider and record the outcome without reusing real customer data. Reconcile a sample in the downstream provider rather than accepting the storefront confirmation page as the only result.

Then watch the paths that changed. Authentication failures can reveal missed consumers of an old credential, but restoring the old secret to stop alerts would undo the revocation. Route each failure to an owner who can update or retire the caller.

Our earlier article on verifying trust after an exploited server update explains why patch state and recovery evidence answer different questions. The same distinction applies here, although the products, attackers and observed post-exploitation paths are unrelated.

Close with evidence, not a green ticket

Before the response owner closes the work, ask for an evidence packet that a second person can read without reconstructing the incident from chat history. It should identify the affected assets, exact versions, hotfix verification, exposure window, investigation limits, rotated credential identifiers, revocation checks, recovery tests and remaining monitoring.

Record open gaps plainly. Missing CDN retention, an extension with no known owner or an integration that cannot rotate without a supplier are decisions to manage. They are not reasons to mark the row complete.

After recovery, update the operating model. Give each Commerce integration a named owner and an issuing-system record. Rehearse an emergency patch on the current hosting model. Confirm that logs needed for exposure analysis survive long enough to investigate. These actions turn the next urgent bulletin into a known procedure, with less guessing while the storefront is under pressure.

Sources and limitations

We opened and reviewed every source below on 9 September 2026.

• Adobe security bulletin APSB26-146 establishes the vulnerability, affected release branches, severity, authentication condition and active-exploitation statement.
• Adobe's urgent action instructions, updated 8 September provide the version-specific hotfix table, verification guidance and credential-rotation sequence.
• CERT-FR advisory CERTFR-2026-AVI-1130 provides the French national advisory and points operators to Adobe's fix.
• Canadian Centre for Cyber Security advisory AV26-888 independently records the active-exploitation statement and the 8 September CISA KEV addition.
• Sansec's StyleSmuggler research supplies the observed campaign timeline and technical indicators. Sansec also sells Commerce security services, and its report describes an evolving investigation.
• NIST SP 800-61 Revision 3 supports the incident-management framing but does not assess this CVE.

Adobe's affected-version and patch tables can change. Sansec's indicators are time-bound and incomplete by design. We have not tested the hotfix, examined a merchant environment or verified compromise at any organisation. Confirm the live Adobe guidance for your exact release and use qualified incident support where the evidence requires it.