Magento Zero-Day StyleSmuggler Hit Stores Before Adobe Patched

Attackers were breaking into Adobe Commerce and Magento stores for three full days before Adobe had a patch to give them. Sansec, the e-commerce security firm that first spotted the pattern, traced live exploitation back to September 4, 2026. Adobe didn't ship a fix until September 7, in an emergency out-of-band advisory, APSB26-146, flagged "Urgent Action Required." The vulnerability, CVE-2026-75650, carries a maximum CVSS score of 10.0, and Sansec gave it a name that's already sticking in security circles: StyleSmuggler.

The flaw sits in 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.4 through 2.4.9, covering roughly two years of releases including versions shipped as recently as August 2026. It lets an attacker with no login, no account, and no prior access achieve remote code execution, the worst outcome a web application can suffer. What separates this from an ordinary Patch Tuesday entry is the calendar. A store running a fully current, fully compliant install on September 5 was still exposed, because the fix simply didn't exist yet. That's a genuine zero-day gap, not a case of somebody skipping an update.

RelatedSAP Commerce Cloud RCE hit by attacks 3 days after patch

How does the StyleSmuggler exploit actually work?

Magento sends a lot of automated email, and one of those templates fires whenever a payment fails: the "Payment Transaction Failed Reminder." Like most of Magento's outbound mail, that reminder gets assembled by the platform's template engine, which supports its own lightweight syntax for pulling in dynamic values such as order numbers, customer names, and amounts owed. StyleSmuggler abuses that pipeline directly. An attacker plants malicious PHP inside content the engine will later process, then deliberately fails a payment so the reminder email gets generated. When the template engine renders that email, it doesn't just drop the attacker's text into place, it executes it, treating injected PHP as though it were legitimate template syntax the store owner wrote themselves.

That's the detail worth sitting with. Nobody had to click a link, open an attachment, or hand over a password. Failing a payment on purpose takes seconds on any public checkout page, and the mechanism that turns that failure into arbitrary code execution runs entirely on the server, automatically, the moment the reminder email gets queued.

Why does the backdoor's NTP disguise matter?

Once attackers had code execution, they used it to drop two things on compromised stores: a PHP web shell for hands-on access, and a backdoor written in Rust built to last longer. The web shell is standard fare. E-commerce breaches have used PHP shells for well over a decade, and most security tooling knows what to look for. The Rust backdoor's command-and-control channel is the part that makes this campaign stand out. Rather than phoning home over an obviously suspicious protocol, its traffic is dressed up to look like an ordinary Network Time Protocol handshake, the quiet background chatter every server generates just to keep its clock synced.

Firewalls and intrusion detection systems mostly wave NTP traffic through without a second look, because there's rarely anything worth inspecting in it. Piggybacking a backdoor's C2 traffic on that pattern isn't a trick that shows up in the average CVE writeup, and it means a store can be fully patched today and still be running an active backdoor installed during the exploitation window, hiding inside logs nobody thinks to scrutinize for a mundane time-sync service.

Why is Adobe telling everyone to rotate encryption keys, even after patching?

Because remote code execution doesn't just let an attacker run one command and walk away. Once code is executing inside Magento, it can read whatever the application can read, and that includes the encryption keys Magento uses to protect stored secrets: payment configuration, API credentials, integration tokens. Patching StyleSmuggler closes the door against new attacks, but it does nothing to invalidate a key that already left the building during the exploitation window. Adobe's guidance reflects that gap directly: every customer, patched or not, is being told to rotate encryption keys, because fixing the vulnerability and undoing what it already exposed are two separate jobs.

That's a heavier ask than the usual update-and-move-on advisory. Rotating encryption keys on a live Magento store touches payment configuration and third-party integrations, and getting it wrong can break checkout for real customers. It's also the step most likely to get skipped, since it doesn't carry the same visible urgency as applying a patch.

RelatedGeoServer Zero-Day Exploited Hours After Disclosure

Adobe Commerce and Magento power a large slice of mid-market e-commerce, the tier of retailers big enough to need real platform features but not big enough to run a fully custom stack. A maximum-severity, actively exploited zero-day in that ecosystem carries a commercial signal beyond the immediate incident. It's a reminder that demand for e-commerce security infrastructure isn't going away: WAF vendors that can virtually patch a template-injection bug before code ships, managed Magento hosting providers who handle emergency patching on a customer's behalf, and research firms like Sansec that catch attacks a vendor hasn't found yet. Each time discovery comes from a third party instead of the platform vendor itself, it chips away a little at platform-level trust in Adobe's commerce security posture.

Our take

The pattern worth noticing isn't just this one CVE, it's who found it. Sansec discovered StyleSmuggler in the wild, not Adobe's internal security team, and that's closer to the norm than the exception for high-profile e-commerce breaches lately. Third-party researchers watching live traffic across many stores tend to spot novel attack patterns faster than a vendor auditing its own codebase, partly because they see exploitation attempts as they happen instead of hunting for theoretical flaws. That's not a knock on Adobe specifically, it's a structural feature of how software this widely deployed tends to get attacked.

The other thing this story gets right that plenty of advisories miss: "patch immediately" undersells what actually needs to happen here. A patch stops the bleeding. It does nothing to put back what already leaked out during three open days. Treating key rotation as an optional follow-up, instead of as co-equal with patching, is exactly how a store ends up compromised months later by credentials nobody thought to change.

Original analysis by GenZTech Team. Source: Adobe.