A newly discovered, unpatched security flaw in Magento Open Source and Adobe Commerce is being actively exploited to gain server-level code execution without any login credentials, according to Dutch e-commerce security firm Sansec. The company, which found and named the bug "StyleSmuggler," reported that exploitation began on September 4 and said it decided to go public early because stores were being compromised in real time.

As of September 6, Adobe had issued no advisory, CVE number, patch, or workaround, with its Adobe Commerce security bulletin page still showing nothing more recent than the August 11 update.

Sansec says every current version of the software is vulnerable, including 2.4.9, and confirmed it successfully replicated the full unauthenticated attack chain on fresh installs of Magento Open Source 2.4.7, 2.4.8, and 2.4.9. Notably, the first known victim was running 2.4.6-p15 with all of Adobe's July and August security patches applied — meaning full patch compliance did not prevent the breach. Sansec has not yet reproduced the exploit against Adobe Commerce itself, and Adobe hasn't specified which of its products or versions are impacted.

For merchants without Sansec's Shield protection, the recommended stopgap is to disable GraphQL until a real fix is released. Hosting provider Disrex Group notes that this workaround isn't viable for headless or progressive-web-app storefronts that depend on GraphQL, though most traditional and Hyvä-based storefronts don't need it.

Adobe's next scheduled patch release lands September 8, though it's unconfirmed whether it will address this vulnerability.

Independent confirmation came from Disrex, which published its own incident response findings on September 5 covering two breached stores and a third that was targeted but not compromised. Both breached stores ran Magento Open Source (not Adobe Commerce) and were self-hosted via Disrex's RexHosting brand. One store, despite having Sansec's Shield actively deployed and blocking other attacks, was hit at 23:10 UTC on September 4 — before any protective rules against this exploit existed. The second store, running a patch level roughly two years out of date, was breached the following morning. Disrex emphasized that timing, not patch status, determined which stores got hit during that roughly eight-hour exposure window.

Disrex flagged that its published repository was assembled quickly with AI assistance during the live incident and hadn't undergone full review or live testing.

On the technical side, Sansec describes the malware as a hidden background process disguised as a legitimate Linux kernel thread, with its binary tucked into a hidden directory under the site's user account (rather than the public web root) and a cron job re-launching it every five minutes. Disrex adds that the binary is a compact, self-contained Rust executable (~1.9MB) built for both x86-64 and ARM64 systems, and that the malicious cron entry is written directly to the crontab spool file — a technique that leaves no trace in standard system logs.