Online retailers running Magento Open Source or Adobe Commerce are confronting an unusually urgent threat: attackers are actively exploiting a previously unknown flaw that can lead to unauthenticated remote code execution. The vulnerability, named StyleSmuggler by Dutch e-commerce security company Sansec, reportedly affects current releases, including Adobe Commerce and Magento 2.4.9, and had no official vendor patch or CVE identifier when the research was disclosed.

This is not a theoretical proof of concept. Live compromises were observed before public disclosure, and researchers reproduced the full chain on clean installations of versions 2.4.7, 2.4.8 and 2.4.9. One early victim was reportedly running 2.4.6-p15 with recent security updates, underlining that ordinary patch compliance alone does not protect stores from a genuine zero-day.

How the two-stage attack reaches code execution

StyleSmuggler appears to turn legitimate Magento features against the server. In the first stage, a crafted GraphQL request manipulates style-related properties so malicious PHP can be written into a file produced during normal application activity. Researchers observed poisoned payment reports and system logs, rather than a conspicuous attacker-created script in the web root.

The attacker then abuses Magento’s template and email-processing path. A specially constructed directive reaches classes associated with the command-line dependency-injection compiler and causes the poisoned file to be included. Triggering Magento’s routine payment-failure reminder is enough to execute the payload while the message is rendered internally; no customer or administrator needs to open the email.

That indirect chain complicates both prevention and investigation. Controls focused only on uploaded files or obvious web shells may miss malicious content placed in trusted application logs. It also means defenders need to inspect the paths and application events surrounding GraphQL requests, failed-payment messages and template rendering as a connected sequence.

Implant hides as a Linux worker

After execution, a PHP dropper tries several process-spawning functions, downloads an implant and establishes persistence. Analysis described a compact, statically linked Rust binary built for x86-64 and ARM64 systems. It masquerades as a Linux kernel worker with a bracketed process name and is relaunched every five minutes through a cron entry written directly into the crontab spool.

Administrators can still distinguish the impostor. A genuine kernel worker runs as root and has no normal resident-memory footprint; a similarly named process owned by the website account and consuming memory deserves immediate investigation. Responders should also hash both the on-disk file and the live process because researchers saw cases where the two differed.

Network monitoring alone may not expose the implant. On one breached store, it opened dozens of connections to the site’s own Redis service and read live Magento sessions without making an external connection. That local activity could blend into normal commerce traffic while still giving the attacker access to valuable authenticated sessions.

Immediate defensive priorities

Until Adobe publishes a complete fix, store operators should assume that a single workaround may be bypassed. Sansec recommends temporarily disabling GraphQL where the storefront does not depend on it. Community hardening patches have also been released, but their authors caution that they address observed paths or traffic patterns rather than eliminating the underlying vulnerability.

• Search both var/report and var/log/system.log for injected content and published indicators.
• Review website-user processes, memory, crontab spool entries and unexpected Redis session access.
• Consider disabling PHP process execution functions such as proc_open where operationally safe.
• Mount temporary locations with noexec and restrict outbound access from commerce servers.
• Preserve forensic evidence and rotate administrative, database, payment and session secrets after suspected compromise.

Why retailers should act before a patch arrives

Commerce platforms sit at the intersection of customer identities, payment workflows and privileged back-office access. A server takeover can therefore produce fraud, stolen session data, card-skimming changes or a foothold into connected business systems. Teams should monitor Adobe’s security channels closely, test any official update quickly and deploy it as soon as possible. In parallel, incident responders should hunt for evidence dating back to the first observed attacks rather than treating installation of a future patch as proof that the environment is clean.