Adobe Commerce APSB26-146: what to verify after the hotfix is installed

Adobe published Security Bulletin APSB26-146 on 7 September 2026 and updated its remediation article on 11 September. This page was written against both on 14 September 2026. Adobe has already revised the remediation article once, so check the date at the top of Adobe’s page against the date here before you act on anything below.

If your team installed the hotfix and stopped there, two jobs may still be open: confirming the patch reached the build that is actually serving traffic, and rotating potentially exposed credentials. Adobe’s linked remediation article covers both; the short bulletin does not reproduce the rotation instructions.

The vulnerability is CVE-2026-75650. Adobe rates it critical, scores it 10.0, requires no authentication to exploit, and categorises it as CWE-1336, improper neutralization of special elements used in a template engine. The impact is arbitrary code execution and the bulletin carries priority rating 1. Adobe states it is aware of the CVE being exploited in the wild, and the remediation article adds that the exploitation targets Adobe Commerce merchants. That last point is why the rotation matters: a store could have been reached before it was patched.

Establish four things before you follow any instruction

The guidance is version-specific and edition-specific, and the affected-version lists are not identical across editions. Write these down first:

• Edition. Adobe Commerce, Adobe Commerce B2B, or Magento Open Source. Each has its own affected-version list in the bulletin.
• Deployment model. Adobe Commerce on Cloud, Adobe Commerce on-premises, or self-hosted Magento Open Source. The verification step Adobe documents is headed for Cloud merchants, and several rotation steps are Cloud-specific.
• Exact version and patch level. Not “2.4.6” but the patch level, because Adobe’s patch table maps seven different files to different version ranges. A store on 2.4.6-p13 and a store on 2.4.6-p11 take different files.
• B2B module version, where you run it. Adobe Commerce B2B carries its own affected list, from 1.5.3-2026-aug down to 1.3.3-2026-aug.

The lists Adobe published are these. Adobe Commerce: 2.4.9-2026-aug, 2.4.8-2026-aug, 2.4.7-2026-aug, 2.4.6-2026-aug, 2.4.5-2026-aug and 2.4.4-2026-aug, each “and earlier”. Adobe Commerce B2B: 1.5.3-2026-aug, 1.5.2-2026-aug, 1.4.2-2026-aug, 1.3.4-2026-aug and 1.3.3-2026-aug, each “and earlier”. Magento Open Source: 2.4.9-2026-aug, 2.4.8-2026-aug, 2.4.7-2026-aug and 2.4.6-2026-aug, each “and earlier”.

The Magento Open Source list stops at 2.4.6 where the Adobe Commerce list continues down to 2.4.4. Read the list for your own edition rather than the first one on the page.

Three jobs live inside this advisory

Adobe’s remediation article states the requirement as applying the patch and rotating your encryption keys. Read it closely and there are three distinct pieces of work, only the first of which is what “we installed the hotfix” usually means.

1. Apply the correct patch for your exact version. Adobe’s table maps version ranges to seven different files, with a composer-patches bundle covering the current lines and separate .patch.zip files going back through 2.4.4. Adobe added a note that the hotfix is now compatible with all Adobe Commerce and Magento Open Source versions between 2.4.4 and 2.4.7, which is a change from the original scope and a reason to re-read the table rather than working from an early copy of it.
2. Verify it actually applied to the build that is running. Adobe documents one way to do this, for one deployment model.
3. Rotate credentials on the assumption they were exposed. This is the step that closes an exposure the patch cannot reach backwards to undo.

Verification is documented for one deployment model

Adobe introduces its own check by saying it “isn’t possible to easily determine if the issue was patched”. That sets the expectation fairly.

The method is the Quality Patches Tool. Install it, then run vendor/bin/magento-patches -n status and look for the VULN-39341 entry carrying an Applied status. The heading above that procedure reads “Confirm the hotfix is applied (Adobe Commerce on Cloud merchants only)”.

If you run Adobe Commerce on-premises or Magento Open Source, Adobe documents the patch and the rotation for you but does not document this confirmation step for your deployment. Have the platform engineer verify that the correct patch’s changes are applied to the deployed application files, supported by the patch-application log or build manifest and a deployment record. Merely finding the patch archive or a lockfile is not proof it applied. Check each environment and every instance serving traffic; a patched build on the build server does not protect an older release still running in production.

A passing status check establishes that the patch is applied now. It does not assess earlier exposure, which may predate the 7 September advisory, and it is not a compromise assessment.

Rotation is the step that closes the exposure

The encryption key encrypts integration tokens, payment gateway credentials and system-privileged automation tokens. Rotating that key generates new protection for those secrets. It does not invalidate secrets that were already read, and Adobe says so on its own page.

So Adobe instructs merchants to rotate the credentials themselves, at their source. A payment gateway API key is rotated at the payment gateway. A third-party service token is rotated at that service. Doing it only inside Commerce leaves a working credential in somebody else’s hands.

Adobe publishes the rotation as an ordered sequence, and the order matters because several steps interact with cron, maintenance mode and, on Cloud, a redeploy that picks up new database credentials. Follow it from Adobe’s page rather than from a copy, since it is the part most likely to change. The scope it covers is broad: encryption keys, every admin panel password, REST, SOAP and GraphQL integration tokens regenerated from System > Extensions > Integrations, OAuth client secrets for connected applications, payment gateway credentials at the provider, database and Fastly credentials through a support ticket, SSH and deploy keys, cron and service-account credentials, and API keys for shipping, tax and other integrated extensions.

One ordering caveat is ours rather than Adobe’s: remediation can change evidence an investigator needs. If you see an unexpected admin account, an unrecognised integration token or an unexplained change, involve your security provider immediately to coordinate containment, evidence preservation and remediation. Do not leave an actively exposed store serving traffic while waiting for an investigation.

Two consequences follow from that list, and neither is a Commerce task. Payment gateway credentials sitting in scope means your PCI obligations are in scope too, and whoever owns that relationship needs telling. Support-ticket credentials mean a queue you do not control, so raise those early rather than at the end of the checklist.

The checklist

Action	Who typically owns it	Evidence it is done	Authoritative instructions
Record edition, deployment model, exact version and patch level, B2B version	Whoever holds the deployment record	A written inventory per environment, not a recollection	Bulletin APSB26-146, affected-version tables
Select and apply the patch file for that exact version	Hosting or platform engineer	The patch file named in a release the deployment log shows going live	Adobe’s remediation article, patch table
Confirm the patch is applied in the running build	Hosting or platform engineer	Quality Patches Tool status on Cloud; on other models, verified patched application files, the patch-application record and the deployment record	Adobe’s remediation article, confirmation section (headed for Cloud merchants)
Rotate encryption keys, then credentials at their source	Platform engineer with the payment and integration owners	Each provider’s own console showing a new credential and a rotation timestamp	Adobe’s remediation article, rotation sequence
Regenerate integration tokens and OAuth secrets	Whoever administers the integrations	Old tokens rejected on a test call; integrations reconnected and working	Adobe’s remediation article, rotation sequence
Notify the party who owns PCI scope	Merchant’s compliance or finance owner	A dated record that the notification happened	Your acquirer or QSA, not Adobe
Decide whether a compromise assessment is warranted	Merchant’s security provider	That provider’s scope and findings	Your security provider

The last two rows are on the list because the first five do not cover them, and because a checklist that stops at the technical steps reads as though the job ends there.

After remediation, review the support window

Two statements in Adobe’s lifecycle policy matter once the store is remediated.

The first is about entitlement. Adobe provides hotfixes for critical security issues “for all customers on a supported version”, even when they are behind on patch releases. A store outside its support window has no such promise for the next one.

The second is about what a hotfix is. In the same paragraph, Adobe writes that “a hotfix is not comprehensive and does not address all security issues that would be resolved by upgrading to the latest release”. That is the vendor saying the patch is a floor.

Alongside those sit three dates and one responsibility worth checking against your own estate. Adobe gives 1 June 2027 as the point it stops maintaining Cloud environments running unsupported versions, with suspended traffic named as one of the actions. PHP 8.1 reached end of life on 31 December 2025, which Adobe’s own table marks as putting PCI compliance at risk for 2.4.4, 2.4.5 and 2.4.6 installations that use it. Adobe describes the security-only transitional period as migration time rather than a support tier. And the third-party dependencies, MariaDB, OpenSearch, Redis, Valkey and RabbitMQ among them, stay the merchant’s responsibility throughout.

For a maintained estate on a supported line, the answer to all of that is usually an in-place upgrade. It keeps the store inside Adobe’s published support model and it is the shorter path. Our article on the 2.4.5 and 2.4.6 support dates has the full lifecycle table.

Replatforming is a different conversation with a different timescale. It earns its place when the upgrade itself surfaces what the store has been carrying: extension risk, checkout customisation, or commerce logic that another platform cycle will not fix. The Magento to Medusa migration guide covers those mechanics, and /migrate/magento/ is where a scoped review starts. Neither is an emergency remedy, and treating a live advisory as a reason to start a rebuild would put the store on an unpatched platform for longer.

Read the bulletin with its linked remediation instructions

The bulletin and the remediation article were last updated four days apart and serve different purposes.

The bulletin’s Solution section recommends users update their installation to the newest version, and lists the hotfix as the updated version. It does not mention credential rotation at all. The remediation article, updated on 11 September, states the requirement as the patch and encryption key rotation, and carries the note that rotating the key alone leaves already-exposed credentials valid.

The bulletin links to the remediation article for installation instructions. Use them together: the bulletin identifies the vulnerability and affected editions, while the linked article supplies the version-specific patch and rotation procedure. The extra detail is not a contradiction, and an installed hotfix alone is not evidence that the full remediation sequence is complete.

Update note

Adobe has already revised its remediation article once, on 11 September 2026, to broaden hotfix compatibility across the 2.4.4 to 2.4.7 lines. Further revisions are likely while the advisory is live. Everything above reflects Adobe’s pages as read on 14 September 2026, and the dates in the Sources section below are the record of when. If Adobe’s guidance and this page disagree, Adobe’s page is right and this one needs updating.

WAYF has not performed incident response on this vulnerability, has not tested the hotfix, and this page does not establish that any store is secure. It is a reading of Adobe’s published guidance, with the edition and deployment differences made explicit.

Sources

• Adobe Security Bulletin APSB26-146 - CVE-2026-75650, severity, CVSS 10.0 and vector, priority rating, CWE category, and the affected-version lists per edition. Published 7 September 2026, read 14 September 2026
• Adobe, urgent action required for APSB26-146 - the patch table, the Cloud-only confirmation step, and the credential rotation sequence and its note. Last updated 11 September 2026, read 14 September 2026
• Adobe Commerce lifecycle policy - hotfix entitlement on supported versions, the statement that a hotfix is not comprehensive, Cloud enforcement from 1 June 2027, the PHP 8.1 end-of-life and PCI note, and third-party dependency responsibility. Last updated 19 August 2026, read 14 September 2026
• WAYF, Adobe Commerce 2.4.5 and 2.4.6 support dates - the full lifecycle table and the upgrade-versus-migration framing
• WAYF, Magento to Medusa migration guide - the commerce migration mechanics
• WAYF, Magento migration review - where a scoped upgrade-or-move review starts

FAQ

1. Does applying the APSB26-146 hotfix mean my store was not compromised?

   No. Adobe says CVE-2026-75650 was exploited in the wild, and the exploitation predates the hotfix reaching every store, so an installation could have been reached before it was patched. The patch closes the vulnerability from the moment it applies and says nothing about what happened before. Adobe's remediation article treats credential rotation as part of full remediation for that reason, and its own note says rotating the encryption key alone does not invalidate credentials that may already have been exposed.

2. How do I check that the CVE-2026-75650 hotfix actually applied?

   Adobe documents a check using the Quality Patches Tool: run vendor/bin/magento-patches -n status and look for VULN-39341 carrying an Applied status. Adobe heads that section for Adobe Commerce on Cloud merchants only, and introduces it by saying it is not possible to easily determine if the issue was patched. On-premises and Magento Open Source stores need their own evidence that the patch file matching their exact version is present in the build that is actually deployed.

3. Which versions does APSB26-146 affect?

   Adobe's bulletin lists Adobe Commerce from 2.4.9-2026-aug and earlier down to 2.4.4-2026-aug and earlier, Adobe Commerce B2B from 1.5.3-2026-aug and earlier down to 1.3.3-2026-aug and earlier, and Magento Open Source from 2.4.9-2026-aug and earlier down to 2.4.6-2026-aug and earlier. The Magento Open Source list stops at 2.4.6 where the Adobe Commerce list continues to 2.4.4, so read the list for your own edition.

4. Is rotating the encryption key enough?

   Adobe's remediation article says it is not. The encryption key protects integration tokens, payment gateway credentials and system-privileged automation tokens, and Adobe instructs merchants to rotate all associated credentials at their source, at the payment gateway or third-party service, rather than only inside Commerce. Adobe's published sequence also covers admin passwords, REST, SOAP and GraphQL integration tokens, OAuth client secrets, database and Fastly credentials, SSH and deploy keys, and third-party API keys.

5. Does a hotfix keep my store supported?

   Only while the store sits on a supported version. Adobe's lifecycle policy says it provides hotfixes for critical security issues to customers on a supported version, and states in the same paragraph that a hotfix is not comprehensive and does not address all security issues an upgrade would resolve. The policy also gives 1 June 2027 as the date Adobe stops maintaining Cloud environments running unsupported Commerce versions.

6. Should this advisory make us migrate off Adobe Commerce?

   Not on its own. The emergency work is the patch, the verification and the credential rotation, and none of that is a platform decision. Once the store is remediated, the questions worth asking are whether the release line is still supported, whether PHP and the other dependencies sit inside their own support windows, and how large the next upgrade is. An in-place upgrade is often the shorter path. A move to another commerce stack is a separately scoped project.