Adobe Commerce Zero-Day: CVE-2026-75650 Patch Guide
Respond to the Adobe Commerce CVE-2026-75650 zero-day with a practical patch, credential rotation, verification and incident review plan.
Adobe has confirmed active exploitation of CVE-2026-75650, a critical Adobe Commerce and Magento Open Source vulnerability that can allow an unauthenticated attacker to execute arbitrary code. Adobe published priority-1 bulletin APSB26-146 on 7 September 2026 and updated its urgent implementation guidance on 9 September.
This is not a routine patch-cycle item. An internet-facing commerce platform sits beside customer accounts, orders, payment integrations, fulfilment systems and privileged automation. If the site is in an affected release line, the response needs to combine a version-specific hotfix, credential rotation, evidence preservation, production verification and enhanced monitoring.
This guide is for Australian ecommerce owners, operations managers, technology leaders, developers and agencies responsible for Adobe Commerce or Magento Open Source. It explains what is known, what to do first and how to avoid declaring success after only changing one file.
Three signals that change the response
Severity, exposure and confirmed exploitation make this an incident-response priority.
CVSS 10.0
Adobe rates the template-engine flaw critical, with potential arbitrary code execution.
No login required
Adobe says exploitation does not require authentication, increasing exposure for public stores.
Exploited in the wild
Adobe has confirmed attacks targeting Adobe Commerce merchants, so patching alone is not enough.
Check whether your Adobe Commerce or Magento store is affected
Start with deployed evidence, not the version someone remembers from the last project plan. Record the production product, release line, exact build, B2B module version where relevant, hosting model and deployment route. Compare that evidence with Adobe's current version-specific table before downloading a patch.
| Product | Adobe's affected scope | What to verify |
|---|---|---|
| Adobe Commerce | Listed 2.4.4 through 2.4.9 release lines at or before the stated August 2026 versions | Exact deployed build, Cloud or on-premises, current patch inventory |
| Adobe Commerce B2B | Listed B2B release lines from 1.3.3 through 1.5.3 at or before the stated August 2026 versions | Base Commerce build plus B2B package version |
| Magento Open Source | Listed 2.4.6 through 2.4.9 release lines at or before the stated August 2026 versions | Exact deployed build and how custom patches are applied |
Do not infer safety from a recent deployment date. A store deployed last week can still contain an affected August build. Conversely, do not apply a random patch package to an unidentified version. Adobe provides different hotfix downloads for some release groups, and the current advisory is the source of truth.
Also inventory every production storefront, regional instance, staging environment connected to live services, admin host, cron worker and autoscaling image. One patched web node does not protect an unpatched worker or an old deployment artefact that can return during rollback or scale-out.
Patch, rotate, investigate and verify as one workflow
Use the right order of operations
Emergency changes fail when teams work in parallel without an agreed sequence. The goal is to reduce exposure quickly while keeping enough evidence to determine whether the store was touched.
- Open an incident record. Name a technical lead, business owner and communications owner. Record times, decisions and evidence locations.
- Preserve evidence. Protect web, application, admin, deployment, database, WAF, CDN and identity logs before retention windows or attackers erase useful history.
- Confirm the deployed scope. Map every affected node, worker, region and image to an exact Commerce or Magento version.
- Obtain the matching Adobe hotfix. Use the live APSB26-146 implementation table, not a file copied from another store.
- Rehearse the deployment. Apply it through the normal code-controlled release path in staging or integration, then test the commercial journeys that matter.
- Deploy and verify production. Confirm the patch status on each production role and prevent unpatched artefacts from returning.
- Rotate the encryption key and dependent credentials. Coordinate service owners so a partially rotated integration does not silently stop orders or fulfilment.
- Hunt for compromise and monitor. Review the exposure window, suspicious changes and credential use, then keep enhanced alerts in place.
If evidence suggests active compromise, involve an incident-response specialist before making changes that could destroy forensic data. Business continuity matters, but so does knowing whether an attacker retained another path into the environment.
Apply the hotfix through a controlled deployment
Adobe Commerce on Cloud
Adobe's current Cloud path uses the project codebase and the m2-hotfixes mechanism. Cloud Patches for Commerce 1.1.21 also includes the APSB26-146 fixes. Confirm which mechanism your project uses, update the relevant tooling if required, and keep the patch in version control so rebuilds and scale-out nodes receive the same protection.
Adobe provides a verification example that checks whether the VULN-39341 composer hotfix is reported as applied. Run the current command from Adobe's advisory in the correct environment and retain the output with the incident record. Verify every role, not only the node that served your terminal session.
On-premises Adobe Commerce and Magento Open Source
Adobe supplies command-line instructions for its composer patch. Test the exact patch against the exact production build in a representative environment, take a current backup and document rollback conditions. After production deployment, verify the changed files or patch state, clear caches as required and confirm that no automation replaces the patched files.
The Commerce Version Tool can generate a security patch-status report showing applied, missing and unknown patches. Use it as supporting evidence, while treating the specific APSB26-146 verification steps as authoritative for this incident.
Do not turn the hotfix into an uncontrolled upgrade
A critical fix needs speed, but scope still matters. Avoid bundling unrelated extensions, theme changes or infrastructure migrations into the same release. A focused change produces clearer test results, a safer rollback decision and better evidence that every production instance received the protection.
Rotate the encryption key and every dependent secret
Adobe's guidance is unusually important here: changing the Commerce encryption key is necessary, but it does not invalidate credentials an attacker may already have obtained. Those credentials must be replaced at their source and then updated in Commerce.
| Credential group | Owner to involve | Proof of completion |
|---|---|---|
| Commerce encryption key | Commerce platform owner | Rotation completed using the current supported method; encrypted configuration revalidated |
| Administrator accounts | Identity and ecommerce owners | Passwords reset, unexpected users removed, active sessions reviewed |
| REST, SOAP and GraphQL integrations | Integration owners | Old tokens deactivated, new tokens issued and least privilege confirmed |
| Payment gateways | Finance, payments and provider contacts | Credentials rotated at the provider, then updated and tested in Commerce |
| Database, SSH and deployment access | Hosting and DevOps owners | Old secrets revoked, pipelines updated, access tests passed |
| Shipping, tax, ERP, CRM and marketing APIs | Operations and application owners | Each external key replaced at source and end-to-end data flow confirmed |
Sequence the work deliberately. Adobe's published process places the site into maintenance mode, pauses cron, rotates keys and credentials, clears caches, restores cron and leaves maintenance mode; Cloud merchants may also need a redeployment for new database credentials. Build a credential register first so no long-running worker, webhook receiver or scheduled export keeps using a revoked secret.
Investigate the exposure window without destroying evidence
Confirmed exploitation changes the question from “is the patch installed?” to “was this environment accessed before the patch?” Preserve originals and work from protected copies where possible.
- Review web, CDN and WAF requests for unusual template-related traffic, unexpected response patterns and spikes around the disclosed period.
- Inspect application exceptions, new or modified PHP files, scheduled jobs, deployment artefacts and configuration changes.
- Review administrator creation, privilege changes, unusual logins and API-token activity.
- Check outbound connections and unexpected calls from web or worker nodes.
- Compare database changes affecting administrators, integrations, configuration and payment settings.
- Correlate payment, shipping, tax, CRM and ERP provider logs with Commerce activity.
- Record every action, timestamp and evidence source so later investigation can reconstruct the response.
This list is a starting point, not a set of vendor-published indicators of compromise. Do not invent indicators from generic attack patterns. Use verified intelligence from Adobe and your security providers, and escalate uncertain findings to qualified incident responders.
Run a commerce-specific verification matrix
A successful deployment does not prove the store is safe or operational. Test the patch, rotated secrets and core customer journeys together.
| Test area | Minimum scenario | Evidence |
|---|---|---|
| Patch state | Every web node, worker and build artefact reports or contains the correct hotfix | Versioned deployment and patch-status output |
| Storefront | Browse, search, category, product and content pages render normally | Automated checks and sampled responses |
| Customer identity | Registration, login, reset, saved addresses and account access | Successful and denied-path test results |
| Checkout | Guest and account checkout across major payment and shipping methods | Test orders, gateway records and Commerce logs |
| Operations | Order capture, invoice, shipment, refund and cancellation | Back-office and downstream system confirmation |
| Integrations | ERP, CRM, 3PL, tax, search, marketing and analytics flows | Fresh events processed with new credentials |
| Security | Old credentials fail; new credentials have expected scope; alerts remain active | Negative tests and monitoring screenshots or exports |
| Recovery | Rollback artefacts cannot reintroduce the vulnerable build | Updated runbook and immutable release reference |
Schedule a second verification after normal traffic, cron and integration cycles have run. Some failures appear only in overnight exports, fulfilment batches or delayed payment webhooks.
Australian businesses should connect the technical response to legal and customer decisions
If logs or other evidence create reasonable grounds to suspect that personal information was accessed or disclosed, activate the organisation's data-breach response plan. Under Australia's Notifiable Data Breaches scheme, a suspected eligible data breach must be assessed reasonably and expeditiously, with all reasonable steps taken to complete that assessment within 30 calendar days.
That is not a reason to wait 30 days. It is an outer assessment requirement, not a target response time. Bring privacy, legal, insurance, payment-provider and communications owners into the incident early enough to preserve options and meet any shorter contractual or sector-specific duties.
ASD guidance also emphasises containment, documentation and evidence preservation. For an actively exploited internet-facing platform, the practical balance is to preserve volatile evidence promptly, deploy the vendor fix through a controlled path, rotate dependent secrets and continue investigating under enhanced monitoring.
A practical response plan for ecommerce teams
Adjust the timing to your environment, but keep the dependencies and evidence visible.
0–2 hours
Open the incident, preserve logs, identify every deployment, confirm versions and assign owners.
2–8 hours
Obtain the matching hotfix, rehearse it, test key journeys and prepare the credential-rotation sequence.
8–24 hours
Deploy, verify all roles, rotate dependent secrets, run negative tests and begin the compromise review.
What good ongoing ownership looks like after the emergency
Once the immediate risk is contained, turn the incident into a stronger maintenance model:
- Maintain a current register of Commerce versions, extensions, environments, images and technical owners.
- Automate security-bulletin review and patch-status reporting with an accountable human decision-maker.
- Keep secrets in managed stores, map each secret to its issuing system and rehearse rotation.
- Retain centralised, protected logs long enough to investigate delayed discoveries.
- Run repeatable checkout, payment, fulfilment and integration tests for every security release.
- Document how a new support partner can obtain repository, hosting, Adobe entitlement and monitoring access during a technical takeover.
The useful outcome is not only one patched store. It is a store that can prove what is deployed, rotate credentials without chaos and respond before a vulnerability becomes a customer-impacting incident.
Sources checked
- Adobe Security Bulletin APSB26-146
- Adobe Commerce urgent hotfix and credential-rotation guidance
- Adobe Commerce Cloud Patches release notes
- Adobe composer patch instructions
- Adobe Commerce encryption key guidance
- Adobe Commerce Version Tool patch-status report
- ASD's ACSC patching guidance
- ASD's ACSC incident-response guidance
- OAIC data-breach preparation and response