Unpatched StyleSmuggler Zero-Day Hits Magento and Adobe Commerce Stores

Active exploitation of an unpatched zero-day vulnerability in Magento Open Source and Adobe Commerce has begun compromising e-commerce platforms globally. Discovered by e-commerce security firm Sansec and dubbed StyleSmuggler, the critical flaw allows unauthenticated remote attackers to execute arbitrary code on an online store’s underlying web server and establish persistent backdoors. Attacks were first observed in the wild on September 4, prompting early public disclosures before Adobe could issue a security advisory, patch, or CVE identifier. Because the exploit targets core core components of the platform, patch status on affected installation lines has proven irrelevant—fully updated systems running the latest security updates remain vulnerable.

Mechanics of the StyleSmuggler Chain

The attack leverages a two-stage unauthenticated remote code execution (RCE) chain combining log poisoning with unsafe file inclusion within Magento’s core rendering engine.

1. Log Poisoning / File Planting: The attacker initialises the chain by delivering a payload containing malicious PHP code into a file that Magento writes locally during routine operations, such as an error log or system failure report.
2. Template Trigger & File Inclusion: The attacker triggers Magento’s native “Payment Transaction Failed Reminder” email process. While rendering the message template, the platform processes a directive embedded in the request that invokes a sequence of internal classes.
3. DI Compiler Execution: The class sequence ultimately leads into legacy code designed for the command-line dependency-injection (DI) compiler—specifically within files under setup/src/Magento/Setup/Module/Di/Code/. This code executes an include directive pointing directly to the path of the poisoned log file created in stage one.

Because the execution occurs while Magento is rendering the transactional email server-side, the attack succeeds regardless of whether the email is successfully delivered or opened by a recipient. Once executed, a PHP dropper attempts six distinct execution functions (system, exec, shell_exec, etc.) to pull down and execute a secondary payload.

Implant Mechanics and Persistence

Data captured by incident response team Disrex Group during live breaches at hosting provider RexHosting provides detailed visibility into the post-exploitation binary dropped on compromised servers.

Rather than relying on web shells planted in the web root, attackers drop a 1.9 MB stripped, statically linked Rust binary targeting x86-64 and arm64 Linux architectures. The binary installs into the site user’s home directory at ~/.local/share/.gvfsd/gvfsd-user and masks its process name in system monitors as [kworker/u:8:0], mimicking a legitimate Linux kernel worker thread.

Path: ~/.local/share/.gvfsd/gvfsd-user
Process Alias: [kworker/u:8:0]
Type: ELF 64-bit LSB executable, x86-64/ARM64, statically linked, stripped (Rust)

Persistence is established by writing a cron entry directly to the Linux spool file under /var/spool/cron/crontabs/ rather than invoking the crontab binary. By modifying the spool file directly, the attack avoids generating standard system log events associated with cron updates. The cron task executes every five minutes to verify the process is active, re-adding itself within seconds if removed.

Notably, post-exploitation telemetry reveals that the implant does not necessarily require immediate outbound C2 traffic to function. On analyzed systems, the malware opened 28 local connections to the store’s Redis cache on port 6379. By reading Magento’s session storage directly from Redis memory, attackers can harvest active admin and customer sessions without triggering outbound network detection rules.

Scope and Affected Systems

The vulnerability affects all current versions of Magento Open Source and Adobe Commerce, including versions 2.4.7, 2.4.8, and 2.4.9. Sansec confirmed the full unauthenticated chain against clean default installations of these releases. In the wild, compromised targets include systems running version 2.4.6-p15 configured with the latest official security updates available.

Independent breach investigations confirm that both fully patched stores and older patch levels (such as 2.4.7-p2) fell victim within an eight-hour window on September 4 before protective signatures were deployed.

Because e-commerce servers handle session tokens, customer personally identifiable information (PII), and payment processing pipelines, an unauthenticated server compromise carries severe consequences. An attacker with arbitrary code execution under the web user context can read environment secrets, modify database contents, inject payment skimmers into storefront JavaScript, or pivot to session stores.

Recommended Workarounds and Detection

With official patches from Adobe pending, organizations operating Magento Open Source or Adobe Commerce must implement temporary network and application safeguards immediately.

• Disable GraphQL (Temporary Workaround): For storefronts built on classic PHP themes or Hyvä that do not rely on headless or Progressive Web App (PWA) architectures, temporarily disable GraphQL endpoints. Blocking GraphQL traffic interrupts the request chain required to trigger the transaction failure template exploit.
• Inspect Cron Spool Files: Audit /var/spool/cron/crontabs/ directly for abnormal entries running hidden binaries from ~/.local/share/ or similar user-space paths, rather than relying solely on crontab -l.
• Monitor Process Tables: Search for processes disguised as kernel threads running under unprivileged site user accounts (e.g., [kworker/u:8:0]). Genuine kernel threads execute exclusively under root (PID 2 parent tree).
• Audit Redis Activity: Monitor local Redis instances on port 6379 for unusual concurrent connections originating from non-standard local processes or binaries executing outside the web server daemon tree.
• Rotate Credentials and Invalidate Sessions: If an implant or suspicious process is identified, flush all active Redis sessions, clear web application session tables, and rotate all administrative credentials, database keys, and API secrets.