CVE-2026-75650: Magento's StyleSmuggler Zero-Day

An unauthenticated attacker can now run arbitrary code on an unpatched Magento or Adobe Commerce store, and by the time Adobe shipped a fix, that wasn’t theoretical anymore. Sansec had already caught it in the wild, deploying a Rust-based backdoor. The bug is CVE-2026-75650, it carries the maximum CVSS score of 10.0, and Sansec’s name for it, StyleSmuggler, tells you exactly where to look.

What’s actually broken

Magento’s template engine trusts more than it should. Specifically, the styles property on products and CMS blocks, the field a merchandiser uses to add a bit of custom CSS to a listing, gets passed into Magento’s template rendering pipeline without the sanitization applied to fields Magento treats as genuinely untrusted input. That distinction, “design data” versus “user input,” is the whole bug. styles was built for CSS. Nothing stops it from carrying PHP.

The attack chain Sansec documented runs in two requests. The first smuggles PHP content into the styles field and gets Magento to write it to a file it can access later. That alone doesn’t execute anything, it’s just a file sitting there. The second request is where it gets ugly: it triggers Magento’s “Payment Transaction Failed Reminder” email template, and the template rendering path for that email reaches into dependency-injection scanner functionality that loads the planted file using PHP’s include or require_once. Those functions don’t read a file as inert text. They interpret it as PHP. The attacker’s code runs.

Nobody has to be logged in for any of this. Nobody has to click anything. The whole chain is unauthenticated, which is most of why the CVSS score maxes out.

Who found it, and how fast attackers moved

Sansec runs continuous monitoring across a large slice of the Magento ecosystem, which is how they catch active-exploitation patterns before vendors do. They spotted StyleSmuggler activity starting September 4. Adobe’s patch and public advisory landed September 8. That’s a three-to-four-day window where working exploit code was live against real stores and no official fix existed, and it’s the reason CISA moved this straight into the Known Exploited Vulnerabilities catalog the same day Adobe disclosed it.

What attackers did with the access is worth knowing in specific terms, not vague ones. Confirmed payloads include a Rust-compiled Linux backdoor, chosen presumably because compiled Rust binaries draw less attention from signature-based detection than a PHP shell would, and a separate PHP web shell built to execute arbitrary commands directly. Two different persistence strategies dropped on the same compromised hosts. That’s not a proof-of-concept researcher poking at a lab instance. That’s operators who had a plan for what to do once they were in.

Why this one is worse than the usual Magento CVE

Magento gets patched constantly, and most fixes here don’t make it into a dedicated post. This one earns it for a few reasons stacked together. It’s unauthenticated, so there’s no credential-stuffing prerequisite or session-hijacking step first. It’s remote code execution, the worst-case outcome, not an information leak or a denial of service. And it was live in the wild before the fix shipped, which means “I’ll patch it during next week’s maintenance window” was never a safe plan here, it was a plan built on information that was already stale.

There’s also the target itself. Magento and Adobe Commerce run a meaningful share of mid-market and enterprise ecommerce, and a compromised storefront isn’t just a defaced page. It’s a live path to customer PII, stored payment tokenization data, and order history, sitting behind a CMS that a lot of merchants treat as “set it up once and let the agency handle updates.” That operating model is exactly what turns a three-day exploitation window into a much longer one in practice.

Patching it

Adobe’s fix is hotfix VULN-39341, distributed as a composer patch from repo.magento.com rather than a full version bump. That matters for how fast you can move: you don’t have to plan a major-version upgrade to close this hole, just apply the patch.

composer require magento/security-patch-VULN-39341 --update-with-dependencies
php bin/magento setup:upgrade
php bin/magento cache:flush

Confirm the exact package name and version pin against Adobe’s own advisory before running this in production. Adobe’s security bulletins list the precise composer commands per affected version line, and Magento’s patching mechanics have enough version-specific quirks that copying a generic command without checking your version first is how patches silently fail to apply.

Affected versions are Adobe Commerce and Magento Open Source 2.4.4 through 2.4.9, and Adobe Commerce B2B 1.3.3 through 1.5.3. If you’re running anything in that range without VULN-39341 applied, that’s the entire population of exploitable stores. There’s no partial-affected middle ground to reason your way around here.

If you were already hit

Here’s the part teams skip: patching stops new exploitation, it does nothing about an attacker who got in three days before you patched. If your store was internet-facing and unpatched any time after September 4, treat “were we compromised” as a real question, not a formality.

Check for what Sansec’s writeup describes: unfamiliar files under media/ or var/ directories that don’t correspond to anything your team or agency deployed, cron entries you didn’t create, and outbound network connections from your application server that have no business existing on a storefront. A Rust binary running as a background process is not going to show up in a casual ls of your web root. If you don’t have file-integrity monitoring already in place, this is a reasonable trigger to add it, alongside rotating admin credentials, API keys, and any payment gateway secrets the compromised process could have read.

This isn’t the first time an authentication or input-handling assumption in a widely deployed platform turned into a KEV-catalog entry inside days. The same September CISA batch that includes this Magento bug also carries Kestra’s unauthenticated RCE, and LiteLLM’s second MCP auth bypass this year landed a few days earlier. If your team maintains Magento or Adobe Commerce for clients, this is also a good moment to check how WordPress core patching is handled across your portfolio, since the operational failure mode, “the CMS was set up once and nobody owns ongoing patching,” is identical across platforms. If patch management across a client fleet of ecommerce sites isn’t someone’s explicit job, that’s worth fixing before the next zero-day, not after.