Adobe published a security update for Adobe Commerce and Magento Open Source on 11 August 2026. At the time, Adobe said it wasn't aware of anyone exploiting the problems it fixed. On 24 September the US cyber security agency added one of them to its list of vulnerabilities known to be under active attack.
Nothing changed about the fix in between. What changed is that the window to install it quietly ran out. If you run an online store on Adobe Commerce or Magento, this is worth ten minutes today.
First, does this apply to you?
This is a flaw in Adobe Commerce and Magento Open Source, which are two versions of the same shop software.
If your store runs on Shopify, WooCommerce, BigCommerce, Squarespace or Wix, this one isn't yours and you can stop here. If you're not sure, the people who built the site will know in a sentence, and the question to ask them is simply whether the store runs on Magento or Adobe Commerce.
What the flaw lets someone do
Shop software decides who's allowed to see and do what. A customer can see their own orders. A staff member can see more. An administrator can see everything.
This flaw let someone get access they were never granted. Adobe's own bulletin records two details that matter more than any score: no authentication is required, and no administrative privileges are required. In plain terms, the attacker doesn't need an account on your store, and doesn't need to trick one of your staff into clicking anything.
Adobe categorises it as a privilege escalation issue and rates it critical, with a severity score of 9.1 out of 10, and records a high impact on both the confidentiality and the integrity of the data. The reason a shop is a worse place than most for that to happen is what is sitting in it: customer names, addresses and order histories.
Why this one got attention six weeks late
The fix has existed since 11 August. That's the part worth sitting with.
Adobe's bulletin from that day says plainly that "Adobe is not aware of any exploits in the wild for any of the issues addressed in these updates". That was true when it was written. It was never a promise about the future.
On 24 September the US Cybersecurity and Infrastructure Security Agency added CVE-2026-71362 to its Known Exploited Vulnerabilities catalogue. Entries reach that list on evidence of active exploitation rather than on prediction, and the entry set a remediation date of 27 September for US federal civilian agencies.
The shape of this one isn't a same-day scramble. Nobody had to move in hours; the fix has been available the whole time. That isn't a reason to take it slowly now, though. A flaw on that catalogue is being exploited somewhere, and the only part you control is whether your own store is still running a July release.
How to check
You need the version your store is running. If you don't have admin access yourself, this is the question for whoever does: which Adobe Commerce or Magento version are we on, and did the August security patch go on?
Adobe names the versions in its bulletin. The affected ones are the July 2026 releases and earlier, across Adobe Commerce 2.4.4 through 2.4.9, Adobe Commerce B2B, and Magento Open Source 2.4.6 through 2.4.9. The fixed ones are the matching August 2026 releases, so 2.4.9-2026-aug, 2.4.8-2026-aug and so on down the line.
The pattern is easier than it looks. Your version ends in a month. If it ends in July 2026 or earlier, the fix isn't on. What you actually want is the August 2026 release that matches your own line, so 2.4.7-2026-jul needs 2.4.7-2026-aug, and Adobe's bulletin lists the pair for every line it supports.
Then sort yourself into one of these, because what happens next is different for each.
Your version is the August 2026 release for your line.
You're patched. That isn't the same as knowing nothing happened in the six weeks before, which is the next section.
Your version ends in 2026-jul or earlier.
The fix hasn't been applied. Raise it today with your developer or whoever hosts the store.
You don't know and can't find out.
That's a bigger finding than this flaw. Somebody needs to be able to answer it within a day.
A developer or agency maintains the store.
Forward them this and ask when the August security patch was applied.
Applying it now doesn't tell you about the last six weeks
This part's uncomfortable and it matters more here than it would on a brochure site.
Installing the update stops the flaw being used from that point on. It doesn't undo anything that happened before, and it doesn't tell you whether anything did. A store that sat on a July release through September was reachable for that whole stretch.
Working out whether something happened isn't a do-it-yourself job. It needs someone with access to the server and the store's own logs, which means your host, your developer, or a security professional.
If your store was on an affected version at any point after 11 August, the things worth asking for are the server and admin logs from that date onward, a check for administrator accounts nobody recognises, and a look at whether any files changed that shouldn't have. Ask sooner rather than later, because logs get discarded after a set period.
And if anything does turn up, don't tidy it away before someone has looked. Deleting the evidence is the fastest way to lose any chance of understanding what happened, and on a store that also means losing the ability to work out whether customer data was involved.
Who's responsible for the patch going on?
I don't build Magento stores. I'm writing this because the pattern behind it's the one I see most often, on every platform.
Shop software updates aren't like phone updates. They can affect a theme, a payment extension, a shipping integration, so they need testing, and testing needs somebody's time booked. That's a real reason they get deferred, and it's why six weeks passes.
The honest version is that "we'll do it at the next release" is a decision, not a delay, and it's worth making deliberately rather than by default. If nobody can tell you when the last security patch went on, that's the thing to fix before the next one lands.
That someone can be your developer, your host if their plan covers it and you've confirmed that it does, an agency you already work with, or a care plan like the one I run. Disclosure, since I've just named my own: that last one is a service I sell. What matters isn't which, it's that you can name them.
The routine worth keeping
The specific flaw will be replaced by another one. What lasts is the habit: knowing what your store runs, and knowing who is on the hook for patching it.
Pages worth acting on
What to read next
Is your WordPress site patched against CVE-2026-87902?
WordPress patched a critical flaw on 22 September and CISA added it to the actively exploited list three days later. Many sites installed the fix on their own. Here's how to confirm yours did.
Read articleCustom-coded vs WordPress: a real-world speed comparison
The same local business, the same services, one website replaced by another, both measured with Google PageSpeed Insights on the same day. Not a laboratory test, but the closest the real world gets.
Read articleAbout this notice
Published 2026-09-26 and accurate to the sources linked above as at that date. Security situations move, so check the vendor's own advisory before you act on anything here.
This is general information about a published vulnerability. It's not advice about your site, which nobody can give without looking at it, and nothing here should be treated as a substitute for your own provider or a security professional.
Questions local business owners usually ask next
Not sure when your store was last patched?
If nobody can answer that within a day, that's the thing worth fixing before the next flaw lands. Send me the address and I'll tell you what I can see from the outside.