Adobe published APSB26-146 on 7 September for CVE-2026-75650, a CVSS 10.0 unauthenticated code execution flaw it confirms is being exploited. The fix is a composer hotfix rather than a version bump, and Adobe's own remediation asks you to rotate credentials at your payment provider as well.
What Adobe Shipped, and When
Adobe published APSB26-146 on 7 September, a day ahead of the scheduled release. The bug now has a number, CVE-2026-75650, and a score that leaves no room above it.
CVSS 10.0. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, which is network reachable, low complexity, no privileges, no user interaction, and a changed scope, meaning the damage does not stop at the application. Adobe rates it Priority 1 and classifies it CWE-1336, improper neutralization of special elements in a template engine. That matches what the researchers described last week, injection into Magento's template system.
Adobe also states plainly that it is aware of CVE-2026-75650 being exploited in the wild against Commerce merchants. That is the vendor confirming what stores were already seeing.
The affected list is wider than the early reporting suggested. Adobe Commerce 2.4.4 through 2.4.9, Adobe Commerce B2B 1.3.3 through 1.5.3, and Magento Open Source 2.4.6 through 2.4.9, in every case at the August 2026 patch level and earlier.
It Is a Hotfix, Not an Upgrade
This is the first thing that trips people, because the usual answer to a Magento security release is to move to the next patch version.
There is no version to move to. The fix ships as a composer patch called VULN-39341, applied on top of the release you are already running. Adobe has tested it only against the August 2026 patch level of each supported version. It may work on others and that has not been verified, which is Adobe's polite way of saying try it somewhere that is not production first.
Two warnings from Adobe's own instructions, both worth obeying. Take a backup before you start, and apply it on staging or integration before production. A CVSS 10.0 is a good reason to hurry and a bad reason to skip the rehearsal.
Applying It, Step by Step
Where to get it. The hotfix is published at Adobe's package repository:
https://repo.magento.com/patch/VULN-39341-composer-patches.zip
Unzip it and you get composer patch files. The one referenced throughout Adobe's own instructions is VULN-39341_Hotfix_COMPOSER.patch, and the examples below use that name.
Check which strip level applies before changing anything. A composer patch is an ordinary unified diff, so patch can tell you whether it will apply cleanly without writing a byte. Adobe's instructions say to use -p1 and to fall back to -p2, and this is how you find out which without discovering it halfway through:
cd /path/to/magento
patch -p1 --dry-run < VULN-39341_Hotfix_COMPOSER.patch
A clean dry run means the real thing will apply. Errors about missing files usually mean the paths are one level off, so try the same command with -p2.
On-premises Adobe Commerce and Magento Open Source
Adobe's documented steps are to upload the patch to the installation root and apply it. The maintenance mode around it is our addition rather than Adobe's, and it is there because you do not want traffic hitting half-patched code:
cd /path/to/magento
php bin/magento maintenance:enable
patch -p1 < VULN-39341_Hotfix_COMPOSER.patch
php bin/magento cache:flush
php bin/magento maintenance:disable
Adobe's version of the last step is to refresh the cache from the admin under System then Cache Management. The CLI flush above does the same thing and is easier to put in a runbook.
Adobe Commerce on cloud infrastructure
Cloud does not take a patch applied by hand, because the next deploy would overwrite it. The patch goes into the repository and the build applies it:
mkdir -p m2-hotfixes
cp VULN-39341_Hotfix_COMPOSER.patch m2-hotfixes/
git add -A
git commit -m "Apply VULN-39341 hotfix for CVE-2026-75650"
git push origin
If the m2-hotfixes directory does not exist in your project root, create it. The push triggers the build, and the patch is applied during it.
Confirm it actually took
Do not skip this. A composer patch that fails to apply is not always loud about it, and Adobe recommends the check explicitly for cloud merchants because there is otherwise no easy way to tell.
composer require magento/quality-patches
vendor/bin/magento-patches -n status | grep "39341|Status"
You are looking for a row naming VULN-39341 with the status Applied. Anything else, including no row at all, means you are not patched no matter how the earlier command exited.
The Sentence Most of the Coverage Will Skip
Read Adobe's own resolution wording carefully. It does not say apply the patch. It says you must apply the patch and rotate your encryption keys.
Then it adds the sentence that should change how you plan your week. Rotating the encryption key alone does not invalidate credentials that may already have been exposed, so rotate all associated credentials at their source, at the payment gateway or the third party service, and not only inside Commerce.
Sit with what that means. Adobe is telling merchants to go and rotate their Stripe, Braintree, Adyen and PayPal credentials at the provider. A vendor does not write that sentence about a vulnerability. It writes that sentence about a breach.
The reasoning is in the same note. The encryption key protects integration tokens, payment gateway credentials and system-privileged automation tokens. Anything that could read those before you patched still holds them after you patch, because the patch closes the door and changes nothing about what already walked through it.
So the honest reading of APSB26-146 is that Adobe is treating affected stores as potentially compromised rather than merely vulnerable. Everything below follows from that.
The Order Is Not Arbitrary
Adobe's remediation runs to thirteen steps. The order carries most of the value and it is worth understanding rather than following blind.
Patch first. Rotating credentials through an unpatched application means issuing fresh secrets into a store somebody may still be reading.
Then maintenance mode, and cron disabled. Rotation touches the encryption key while background jobs are re-encrypting values, and a cron run in the middle of that is how you end up with rows encrypted under two different keys and a store that will not boot.
Then the key, then everything the key was protecting. Admin passwords, REST, SOAP and GraphQL integration tokens regenerated from System then Extensions then Integrations, OAuth client secrets for connected applications, payment gateway credentials at the provider, database credentials, SSH and deploy keys, and the API keys for shipping, tax and any extension that holds one.
Then cache flush, cron back on, maintenance mode off, in that order.
What the Patch Still Does Not Do
If your store was hit before you patched, none of the above removes what was left behind. The implant reported last week ran as a background process disguised as a kernel worker, persisted through a cron entry, and connected out to a command and control host.
Patching does not touch it. Rotating credentials does not touch it. Those are two different jobs and only one of them is described in the bulletin.
The compromise checks are in our write-up from last week, and they take a minute. Run them before you consider this closed, and run them even if the patch applied cleanly, because a clean patch on a compromised host is a locked door in a house somebody is already standing in.
If You Only Have an Hour Today
The full thirteen steps are a maintenance window, and not everyone can take one this afternoon. If you have to triage, this is the order that buys the most safety per minute.
Apply the patch and verify it. That stops new intrusions and it is the only step that does.
Run the compromise checks. Five minutes, and the answer changes everything after it. A store with indicators needs an incident, not a checklist.
Rotate the payment gateway credentials at the provider and the admin passwords. These are the two that turn into money and into control fastest, and neither depends on the maintenance window.
Then book the window for the encryption key and the rest, because that part genuinely needs cron stopped and the store closed, and doing it badly is worse than doing it on Thursday.
Sources: Adobe Security Bulletin APSB26-146, Adobe hotfix and rotation instructions, How to apply a composer patch, Quality Patches Tool
Or read how we handle it in Security & Compliance.
Related Articles
Kubernetes Network Policies for Microservices
Implement zero-trust networking in Kubernetes with network policies that control pod-to-pod traffic, namespace isolation, and egress filtering.
SecurityHow to Read a CVE and Decide in Ten Minutes If It Touches You
An alarming headline and a severity score are not a decision, and the score cannot become one because the part of it that would describe your environment is the part nobody filled in. This is the ten minute route from a CVE number to a defensible answer, covering what the scoring specification actually says, why your installed version number may be lying about whether you are patched, and which public sources report real exploitation rather than the possibility of it.
SecurityHow to Block an Attack Without Blocking Your Own Client
The rate limit that finally stops the credential stuffing is also the one that locks out your customer's head office on Monday morning, or quietly drops a payment provider's webhook and leaves a hundred orders unpaid. This guide builds the version that does not do that, starting with getting the real client address right behind a CDN, then an allowlist that works because nginx does not account requests with an empty key, a dry run week that shows you who you were about to break, and a fail2ban jail with the same allowlist repeated. It ends with the list of addresses that must never be banned.