On 4 September 2026, attackers started breaking into Magento and Adobe Commerce stores through a flaw that had no fix. Adobe published one three days later. In those three days, the stores getting hit were not the neglected ones running years-old code. At least one of them was sitting on the newest patch level Adobe offered for its release line.
That is an awkward fact for the way most owners think about store security, which runs roughly: we pay someone to apply the patches, so we are covered.
Dutch e-commerce security firm Sansec found the flaw, named it StyleSmuggler, and published its advisory early because stores were being compromised while it was being written. Adobe's security bulletin followed on 7 September. It rates the bug 10.0 on a 10-point scale and confirms the part that matters commercially: no login required. Anyone who could load your storefront could run code on your server.
The severity is not the uncomfortable part of that bulletin. The affected-versions table is. Every supported release line of Adobe Commerce, Adobe Commerce B2B and Magento Open Source is listed as vulnerable at its latest August 2026 patch level. Not "if you have fallen behind". At current.
The Hacker News reported the detail that should change how you brief your team. The first compromised store its responders handled had Adobe's July and August 2026 security updates applied and sat at the most recent patch level available for its release line. It was also running a commercial Magento security product, licensed and enabled, which was actively blocking other malicious traffic against that same store at the same time.
It was breached hours before any rule existed that could have caught this particular attack.
The hosting and development firm that responded put it bluntly: patch status was irrelevant here, and that is the part merchants most need to hear.
Every disclosed vulnerability opens a gap between the moment attackers start using it and the moment a fix exists. For StyleSmuggler that gap ran three days, according to Tenable's write-up. Three days is short by industry standards. It was still long enough for multiple stores to be backdoored.
Nothing in your patching process touches that window, because during it there is nothing to patch. What you have instead is whatever else you built: how fast you would notice, how fast you could take a defensive measure that costs you revenue, and whether anyone is authorised to make that call at midnight on a Friday.
You want to know which side of that you sit on before the night you have to decide. The interim advice during the September window was to temporarily switch off the part of Magento that serves modern frontends. For a classic or Hyvä storefront, that is an inconvenience. For a headless or app-driven storefront, it closes the shop. Same advisory, two businesses, completely different decision.
A second store in the same incident was running a patch level Adobe had published in August 2024, eight releases behind current at the time it was breached.
The reflex is to call that negligence. It usually isn't. Applying a Magento security patch is not a button. It is a release: a staging deploy, a regression pass over checkout and payments, a maintenance window, and a rollback plan for the moment something in your extension stack disagrees with the change. Stores fall behind because that release costs real money and real attention, and there is always something more urgent in the queue.
The cost is deferred, not avoided. Magento's exploitation record is not theoretical. Three earlier Adobe Commerce and Magento flaws sit in the US government's catalogue of vulnerabilities confirmed to be exploited in the wild, added in 2022, 2024 and 2025. Attackers watch this platform closely, and they move on it faster than most merchants can convene a call.
Four things separated the stores that came through September well from the ones that didn't, and only one of them is about patching.
Someone can authorise an unscheduled release. Not a committee. One named person who can approve a documented risk at an inconvenient hour, and who understands that "we'll look at it Monday" is itself a decision with a price attached.
The path to production has been used recently. An emergency patch pushed through a deploy process nobody has exercised in four months is how a security fix becomes an outage. Routine Magento maintenance is boring for exactly this reason: it keeps the emergency path warm.
Monitoring is scoped wider than the storefront. In the September incident, a scheduled malware scan ran against one compromised store and reported it clean, because the implant had installed itself one level above the directory the scan was pointed at. A scanner that only looks where you told it to look will only ever tell you what you told it to say.
Credential rotation is a rehearsed procedure, not a research project. After a compromise, Adobe's guidance is to rotate the store's encryption key and everything it protects: admin logins, integration tokens, payment gateway keys, deploy keys. If nobody on your side knows where that list lives, you will be assembling it during an incident, on the day you can least afford to.
One compromised store gave itself away by emailing its own owner. The message looked like a broken order notification: template placeholders that had never resolved, a customer address on an invalid domain, an order total of zero.
It was not a broken order. It was exhaust from the attack passing through Magento's email templating. The merchant forwarded it to their agency as a bug report, and the investigation that started there found the backdoor within the hour.
Nobody needed tooling for that. Somebody just had to find a strange email suspicious rather than annoying.
What patch level are we on, and when was the last one applied? Who can approve an emergency release outside business hours, and have they ever actually done it? If our store were compromised tonight, how would we find out?
If the honest answer to the third one is "the bank would call us", you have a monitoring problem rather than a patching problem, and staying current will not fix it. Attackers who get in rarely announce themselves, and the quiet ones sit in checkout taking card numbers for months.
One more thing worth settling internally. Adobe's bulletin lists Magento Open Source and Adobe Commerce alike, so the edition you run changes your support contract and your bill, not your exposure to this class of problem.
Most of our work happens on Magento stores somebody else built, and the pattern repeats. The security gap is almost never the patch itself. It is that nobody has run the emergency path recently enough to trust it, and no single person owns the decision to use it. When we took over a fragile multi-store retailer, the first useful thing we did was not a patch at all. It was working out what would actually happen on a bad night, and writing it down while everyone was calm.
If your store runs on Magento and nobody has tested that answer lately, this is the kind of problem we take on at Encomage. Our engagements usually open with a plain audit of the patch position, the deploy path and who holds the pager, before anyone argues about which fix goes first.
Let’s build something powerful together - with AI and strategy.
