A Magento Store Got Backdoored in 50 Minutes. Here's the Patch — and What It Doesn't Undo.

Note: Active exploitation began September 4, 2026. Adobe’s emergency hotfix (APSB26-146) shipped September 7, 2026 — one day old as of this writing. If you run Magento Open Source or Adobe Commerce and haven’t patched yet, that’s the most useful thing you can do with the next ten minutes, before you finish reading this.

Here’s the number that should stop you mid-scroll if you run a store on Magento or Adobe Commerce: one server, managed by an e-commerce development platform, went from untouched to fully backdoored in 50 minutes after the first confirmed attack. No login. No stolen password. No phishing email an employee had to click. The attacker sent a request to a public-facing store and fifty minutes later owned the box.

That’s the headline fact of StyleSmuggler, tracked as CVE-2026-75650, a CVSS 10.0 — the maximum possible severity — remote code execution vulnerability that Dutch e-commerce security firm Sansec discovered being actively exploited in the wild. It affects every current version of Magento Open Source and Adobe Commerce, including the latest 2.4.9 release, plus Adobe Commerce B2B. If your store hasn’t applied Adobe’s hotfix yet, you are, right now, running software with a known, actively-exploited, unauthenticated way in.

What actually happened, in order

Date	Event
September 4, 2026, 22:20 UTC	Sansec detects the first confirmed exploitation in the wild
September 4–5, 2026	Attacks continue; one monitored store compromised within 50 minutes of the initial attack window
September 5, 2026	Sansec publishes an early advisory and ships blocking rules for its Sansec Shield product
September 7, 2026, 20:20 UTC	Adobe releases emergency hotfix VULN-39341 via security bulletin APSB26-146
Ongoing	Adobe and Sansec both recommend scanning for existing compromise, not just patching forward

The vulnerability itself is almost elegant in a way that should worry you more, not less. It abuses Magento’s own template system — specifically, the styles property used to generate a routine “Payment Transaction Failed Reminder” email. An attacker injects malicious PHP code through that property, and when the email template renders, the code runs. No authentication step exists anywhere in that chain, because a failed-payment reminder email is exactly the kind of automated, no-login-required process a store runs constantly on its own, for its own customers, all day.

Sansec’s own scale estimate is the number that should reframe how you think about this: the underlying bug touches an estimated 75% of Adobe Commerce and Magento installations worldwide, and as of the most recent public reporting, Sansec had confirmed 4,275 stores already breached in active attacks — including household names like Whirlpool, Ray-Ban, National Geographic, and Segway. If brands with actual security budgets and dedicated IT staff got hit, a two-person shop running a Magento install a freelancer set up two years ago was never the priority target — it was just as reachable as everyone else, because the attack doesn’t care who you are. It’s a script that hits public-facing stores and doesn’t check payroll size first.

Worse, exploitation was confirmed against stores that had already applied Magento’s official July and August 2026 security patches — meaning “we’re current on our updates” gave zero protection here, because the vulnerable code predated both of those patch cycles and nobody had found it yet. That detail matters more than it might seem: it’s the difference between “we got hit because we were behind” (a process failure you can fix by patching faster) and “we got hit even though we were current” (a detection-gap failure that patching alone doesn’t solve).

Who’s actually affected

Platform / version	Affected?
Adobe Commerce 2.4.4 – 2.4.9	Yes
Adobe Commerce B2B 1.3.3 – 1.5.3	Yes
Magento Open Source 2.4.6 – 2.4.9	Yes
Magento 1.x (end-of-life since June 2020)	Not directly named in the advisory, but already unsupported and a materially worse security posture regardless
Shopify, BigCommerce, WooCommerce, Squarespace	Not affected — this is a Magento/Adobe Commerce-specific template-engine flaw

If you’re not on Magento or Adobe Commerce, this specific vulnerability doesn’t touch you — but the pattern underneath it (an automated, no-login process that quietly executes untrusted input) is worth a five-minute gut check on whatever platform you are running, because “no authentication required” flaws in unglamorous automated processes are a recurring category across e-commerce software, not a one-platform problem.

What the attackers actually installed

This isn’t a defacement or a smash-and-grab. Once in, attackers have been deploying two distinct payloads, and the more sophisticated one is worth understanding because it tells you what “patched” does and doesn’t undo:

A Rust-based Linux backdoor that disguises itself as legitimate system processes — showing up in a process list as [kworker/u:8:0], fc-cache, or chronyd, names chosen specifically to blend into normal Linux server activity and not draw a sysadmin’s eye during a routine check. It phones home to command-and-control infrastructure disguised as Network Time Protocol (NTP) traffic — the background clock-sync traffic every server sends constantly and essentially nobody inspects — using 48-byte UDP packets on port 123 crafted to look like ordinary NTP replies. Beacon traffic has been observed reaching a specific external IP and a set of spoofed NTP domains.

A PHP dropper deploying a web shell, giving attackers a simpler, more direct way to execute arbitrary PHP commands on the compromised server going forward, independent of the Rust backdoor. The dropper itself is tiny — around 485 bytes — and it plants the web shell inside Magento’s product-image cache directory, a location almost nobody manually inspects because it’s supposed to contain nothing but auto-generated thumbnail images. The shell only executes PHP commands when it receives a specific header in the request, so a casual look at the file (if anyone even opened it) wouldn’t obviously reveal what it does.

The design choices here aren’t accidental. Disguising a backdoor as a kernel worker process, hiding its network traffic inside NTP packets, and burying a web shell in a folder that’s supposed to hold nothing but thumbnails are all aimed at defeating exactly the kind of “does anything look weird” glance a busy small-shop admin gives a server, if they look at all. Nobody scrutinizes NTP traffic or opens image-cache folders looking for PHP. That’s the entire point of choosing them. Sansec also observed a second, updated version of the Rust backdoor appear on September 6 — this one disguised as fc-cache rather than the original [kworker/u:8:0] — which tells you the attackers were actively iterating on their evasion the same week the rest of the industry was scrambling to respond, not running a single static payload.

Patching stops the door from opening again. It does not close a door that’s already open.

This is the part that matters most and gets skipped in a lot of “just update” coverage: applying Adobe’s hotfix prevents new exploitation. It does not remove a backdoor that’s already been planted. If your store was compromised between September 4 and whenever you patch, the hotfix closes the vulnerability that let the attacker in — it does not evict them once they’re already inside.

Sansec’s own recommendation, and the correct sequence, is four steps, not one:

1. Apply the hotfix (VULN-39341 / APSB26-146) immediately. This is the step that stops new exploitation. It’s necessary and it’s not sufficient on its own.
2. Scan for existing compromise. Sansec offers eComscan specifically for this; the signature to look for includes the disguised process names above and NTP-port traffic to unexpected destinations. If you don’t have a security vendor relationship, at minimum have someone technical check running processes for anything using the chronyd or fc-cache name that wasn’t there before, and check outbound traffic on port 123 to destinations that aren’t your actual configured NTP servers.
3. Rotate encryption keys and every credential the store touches — admin passwords, API keys, payment gateway credentials, anything the compromised server had access to. A backdoor with root-equivalent access on your server has had access to everything that server can see, which for most Magento installs includes customer payment tokens, admin sessions, and database credentials.
4. Assume the worst until you’ve verified otherwise. If you can’t confidently answer “was my server touched between September 4 and today,” the honest posture is to treat it as compromised and go through the scan-and-rotate steps anyway, rather than hoping you were one of the stores that got missed.

There’s a fifth step worth asking honestly, separate from the four above: where does your most recent clean backup actually live? If it’s on the same server or an always-connected NAS, the backdoor could reach it too, which turns a bad week into a from-scratch rebuild. The offline backup drive piece covers that specific gap and the cheap fix for it.

A worked example: what a two-person store actually does this week

Say you run a 12-SKU home goods store on Magento Open Source, built by a freelance developer two years ago who isn’t actively on retainer anymore. You don’t have a security team. Here’s the realistic path:

Day 1 (today): Contact your hosting provider or the freelancer who built the site and ask directly: “Has the StyleSmuggler hotfix (APSB26-146 / VULN-39341) been applied?” If they don’t know what you’re talking about, that’s your answer, and it’s worth paying for a few hours of someone’s time today rather than waiting for a scheduled maintenance window that might be weeks out.

Day 1–2: Once patched, ask the same person to check for the specific compromise indicators — the disguised process names and the anomalous NTP traffic pattern — rather than assuming “patched” means “clean.” If they can’t do this themselves, a Magento-specialist security firm (Sansec and several competitors offer paid one-time scans) is a reasonable few-hundred-dollar expense given what’s at stake.

Day 2–3: Rotate every credential that touches the store regardless of scan results: admin panel passwords, payment gateway API keys, database credentials, any third-party integration tokens (shipping, email marketing, inventory sync). This is tedious and doesn’t feel like it’s “doing” anything if the scan came back clean — do it anyway, because a clean scan means “we didn’t find evidence of compromise,” not “we’re certain there was none.”

Week 1 follow-up: Have a real conversation about who’s actually watching Adobe’s security bulletins going forward. If the answer is “nobody, until something breaks,” that’s the actual root cause this incident exposed, and it’s worth either assigning it explicitly to your hosting provider’s support contract (many include this) or subscribing directly to Adobe’s PSIRT bulletin list yourself — free, and the single highest-leverage five minutes of setup you can do after this incident passes.

Why this specific attack should change how you think about “just keep the platform updated”

There’s a version of small-business security advice that says “keep your software updated and you’re basically fine.” StyleSmuggler is a useful, uncomfortable counterexample: every current version was vulnerable, including the version released the same month. Being current wasn’t the failure here — the vulnerability existed in code that had been shipping, unnoticed, across every 2.4.x release. Updating to the latest version before September 7 would not have protected you, because the latest version was the vulnerable one.

That doesn’t mean “updates don’t matter” — it means updates are necessary but not sufficient, and the sufficient part is monitoring for the gap between “a vulnerability exists” and “a patch exists,” which for StyleSmuggler was measured in days, and for the specific stores hit first, in minutes. A store owner who checks in on security news weekly would have had a multi-day window of exposure even doing everything else right. That’s not a reason to give up on patching quickly — it’s the reason patching quickly, plus having someone actually watching security advisories for the specific platform you run, both matter. If nobody on your team or your dev shop’s team is subscribed to Adobe’s security bulletin list or a service that tracks Magento-specific CVEs, that’s the actual gap this incident exposes, more than any individual missed patch.

This isn’t Magento’s first time, and that’s the actual pattern worth noticing

If you’ve run a Magento store for more than a couple of years, StyleSmuggler will feel familiar in shape even though it’s new in detail. Magento — and the broader Adobe Commerce codebase it grew into — has a long history of exactly this category of incident: unauthenticated remote code execution flaws, often in unglamorous corners of the platform (admin panel edge cases, import/export tooling, template rendering), followed by mass automated scanning and exploitation within days of disclosure. The end-of-life of Magento 1 in 2020 left tens of thousands of stores permanently exposed to a growing pile of unpatched vulnerabilities, and a meaningful share of “random small e-commerce site got hacked” stories over the following years trace back to exactly that population.

The pattern isn’t that Magento is uniquely bad software — it’s a large, complex, widely-deployed platform, and platforms with those three properties are permanently attractive targets regardless of how good the underlying engineering is. The lesson isn’t “switch platforms in a panic.” It’s that running a large, complex, self-hosted commerce platform is an ongoing operational commitment, not a one-time setup task, and StyleSmuggler is this year’s reminder of that fact, not the first and almost certainly not the last.

Comparing your options for staying ahead of the next one

Approach	What it covers	What it costs	Best fit
Manual patching, DIY monitoring	Nothing until you personally read a bulletin and act	Your time, inconsistently	Only realistic if someone on your team genuinely tracks Adobe security bulletins as part of their job
Hosting provider with managed Magento support	Patching cadence, often proactive alerts on critical CVEs	Usually bundled into hosting cost or a modest add-on	Most small shops — verify your current host actually does this rather than assuming
Dedicated Magento security vendor (e.g., Sansec Shield)	Real-time blocking rules often shipped faster than official patches, plus compromise scanning	A few hundred dollars a year and up	Stores with real transaction volume where downtime or a breach has real dollar consequences
Migrate to a hosted platform	Platform vendor owns patching entirely; you can’t fall behind on updates you never apply yourself	A recurring platform fee, plus migration cost and lost customization	Stores where the operational burden of self-hosting has consistently exceeded the benefit of the flexibility it buys

None of these is free, including “do nothing,” which just moves the cost to whenever the next StyleSmuggler-shaped incident finds you unpatched and unmonitored.

Put real numbers next to that comparison and the calculus gets clearer. A Sansec-style scan runs a few hundred dollars as a one-time event; a managed hosting add-on with proactive patching typically runs an extra $30–150 a month on top of base hosting. Compare that to the actual cost of a breach going undetected for even a few weeks: PCI compliance violations alone can trigger fines from your payment processor, a compromised store leaking customer card data creates notification obligations in most states, and — the cost that rarely makes it into these conversations — a store flagged by Google Safe Browsing or blacklisted by a payment processor for hosting malware can lose weeks of revenue before it’s even fully cleaned up and re-verified. A few hundred dollars a year for monitoring is cheap insurance against a multi-week revenue stoppage, not an optional upsell.

When this doesn’t apply to you

If you’re not running Magento or Adobe Commerce, this specific CVE isn’t your fire drill — skip straight to the pattern-level lesson instead of the specific remediation steps.

If your store runs on a fully managed hosting arrangement where patching is explicitly the provider’s contractual responsibility, verify they’ve actually applied it (a two-line email is enough) rather than doing the technical remediation yourself — that’s what you’re paying them for, and duplicating their work wastes your time without adding real protection.

If your Magento install processes no real customer data — a demo store, a staging environment with synthetic data, an abandoned project nobody actually uses — the urgency here is lower, though it’s still worth patching before an abandoned box becomes someone else’s launchpad for attacking other things on the same network.

The 15-minute checklist, right now

If you run Magento Open Source or Adobe Commerce and are reading this before doing anything else:

1. Confirm you’re on a patched build (VULN-39341 applied / APSB26-146 addressed) — if not, stop reading and do this first.
2. Check running processes for anything named chronyd, fc-cache, or [kworker/u:8:0] that your hosting provider or dev team can’t immediately explain.
3. If you have any log visibility into outbound network traffic, look for port 123 (NTP) traffic to destinations other than your actually-configured NTP servers.
4. Rotate admin credentials, API keys, and encryption keys regardless of what step 2 and 3 find — this is cheap insurance against a compromise you can’t fully verify one way or the other from the outside.
5. If you don’t have anyone who can do steps 2–3 competently in-house, this is a legitimate one-off reason to bring in outside help for a few hours rather than skip the check entirely.
6. Once you’re clean, subscribe to Adobe’s PSIRT security bulletin list so the next one doesn’t have a multi-day head start on you.

This connects to a broader habit worth building regardless of platform: a basic small-business data security checklist covers the same MFA-plus-patching-plus-backup discipline that would have shortened this incident’s blast radius, and the guest Wi-Fi / POS network separation piece covers the same “assume something on your network eventually gets compromised, so limit what it can reach” thinking that applies just as much to a backdoored web server as to a compromised laptop. If your store also sells across multiple channels, the multi-channel selling piece is worth a read for the adjacent question of how a single platform compromise can ripple into every channel synced to it.

Bottom line

StyleSmuggler is about as bad as unauthenticated RCE gets — maximum CVSS score, no login required, every current version affected, and a real-world compromise measured in minutes once an attacker started looking. Adobe’s hotfix closes the hole. It does not evict anyone who already walked through it before you patched. If you run Magento or Adobe Commerce, the sequence is patch, scan, rotate credentials, and then — the step that actually prevents the next one from catching you flat-footed — make sure someone is actually watching for the next bulletin before it becomes this article again with a different CVE number.

Sources

All facts accessed September 8, 2026.

• Original discovery, exploitation timeline, technical mechanism, and backdoor analysis — Sansec, “StyleSmuggler: Magento and Adobe Commerce 0-day RCE (CVE-2026-75650) under active attack”
• Additional technical detail on payloads (Rust backdoor and PHP web shell), affected version ranges, and Adobe’s hotfix response — The Hacker News, “Adobe Patches Magento Zero-Day Exploited to Deploy Rust Backdoor and PHP Web Shell”
• Confirmation of active exploitation, hotfix timeline, and broader industry response — BleepingComputer, “Magento StyleSmuggler zero-day exploited to deploy Linux backdoor”
• CVE severity rating and affected-store scale estimates — SecurityWeek, “Adobe Commerce Zero-Day Exploited to Backdoor Online Stores”
• PHP dropper size, product-image-cache web shell placement, and header-triggered execution detail — CSO Online, “Adobe Commerce max-severity bug comes under active attack”