Where were you on the clock? A retro framework for the Magento zero-day

Edition 048 · 10 September 2026

At 11:20pm BST on 4 September, Sansec – experts in eCommerce security logged the first confirmed exploitation of a Magento and Adobe Commerce flaw now called StyleSmuggler. CVSS 10.0, the maximum severity score the scale goes up to, for an unauthenticated remote code execution flaw triggered by a fake “Payment Transaction Failed Reminder” email that Magento’s own template engine turned into a working PHP backdoor. One of the servers Sansec tracked went from first hit to fully compromised in about fifty minutes.

Adobe shipped a fix on 7 September, ahead of its usual patch cycle. The next day, CISA (the US Cybersecurity and Infrastructure Security Agency) added it to its Known Exploited Vulnerabilities catalog and gave American federal agencies until tomorrow, 11 September, to have it closed. No UK regulator is chasing you the same way, but the clock ran the same regardless of where your business sits. If you run Adobe Commerce or Magento Open Source anywhere between 2.4.4 and 2.4.9, that’s the pace you were up against, whether or not anyone told you so.

This isn’t really a piece about patching. By the time you read it, most teams reading Breakthrough Commerce will already know whether their stores are safe. The more interesting question is the one almost nobody can answer cleanly: where was your team, specifically, at each point on that clock? Not “did we deal with it” in the vague, reassuring way incident summaries get written after the fact, once the dust has settled and nobody wants to relitigate a stressful week. Where were you at 11:20pm on the 4th. What did you do on the 5th, when Sansec published mitigation advice and there was still no patch to apply. What happened between the 7th and whenever your production environment actually ran the fix, not whenever the ticket said “in progress.”

Everyone was busy. That’s not the same as effective

Every team that touched this incident was doing something during the week it ran. Someone opened a ticket. Someone forwarded the Adobe advisory to the platform team. Someone told a stakeholder “we’re on it.” That’s a week of visible activity that never quite resolves into a clear account of what actually happened, in what order, with what result. The teams that come out of an incident like this looking competent aren’t the ones who worked hardest during the week. They’re the ones who can answer four questions about it now, specifically, without checking Slack first.

Four questions, in the order the clock actually ran

When did you first know? Sansec published its advisory on 5 September, a full two days before Adobe’s patch existed. If your first knowledge of StyleSmuggler came from Adobe or the US CISA rather than a security feed, a Slack alert, or an agency that was already watching, that’s not a moral failing, but it is data. It tells you whether you have a detection mechanism or you’re waiting for the news to arrive.

What did you do before the patch existed? For three days, the only defence was Sansec’s own advice: disable GraphQL, which isn’t an option if your storefront is headless, or the narrower community mitigations from Disrex, ProxiBlue and Graycore, blocking PHP’s proc_open, mounting temp directories as non-executable, rotating credentials on anything that looked exposed. None of that required Adobe. It required someone already reading the advisory on the 5th and deciding to act on it rather than wait.

How long from patch to actually patched? Adobe released the fix on the 7th. “In progress” isn’t the answer to this question. The answer is a date, and ideally it’s close to the 7th, not the 11th others were racing to beat.

Did anyone check for existing compromise? A server can go from first hit to backdoored in under an hour. If your store was exposed for any part of that three-day window before the fix existed, patching closes the door but doesn’t tell you whether someone already walked through it. Checking means rotating admin passwords, API tokens and database credentials, not just confirming the version number changed.

The order of the answers is the actual finding

Most teams can eventually produce an answer to all four, if you push. What the sequence reveals is different from what any single answer does. A team that knows the discovery date but can’t name what it did before the patch has a monitoring capability and no response capability. A team that patched fast but never checked for prior compromise has a deployment pipeline and no incident process. Run the four questions on your own team or your agency this week, in order, and the gaps won’t be subtle. They rarely are, once someone actually asks.