A newly reported zero-day affecting Magento Open Source and Adobe Commerce is being exploited in the wild to execute code on e-commerce servers and install a persistent Linux backdoor. The vulnerability has been named “StyleSmuggler” by Sansec, the Dutch e-commerce security firm that disclosed active exploitation, and it should be treated as an active incident, not a routine patch-management ticket.
The most important operational detail is that, at the time of reporting, Adobe had not yet published a CVE, official advisory, patch, or vendor workaround. Sansec says attacks began on September 4, and evidence shared by incident responders indicates that both fully current and older Magento installations may be exposed. That means merchants should not assume they are safe simply because the store was recently patched.
What is known about the attack
According to the reporting, the exploit chain can be triggered without logging in and results in server-side code execution. Sansec reproduced the unauthenticated chain on clean Magento Open Source 2.4.7, 2.4.8, and 2.4.9 installations, and the first observed victim reportedly ran Magento 2.4.6-p15 with Adobe’s July and August 2026 security updates applied.
The attack appears to use Magento’s own application behavior as part of the chain. In broad terms, malicious PHP is first planted into a file that Magento writes, such as a report or log file. The attacker then causes Magento to execute that content through the platform’s “Payment Transaction Failed Reminder” email rendering path. The email does not need to be opened, and the attack may still work even if delivery fails.
That combination makes the issue especially dangerous for production stores. It does not look like a simple credential-theft event, and it does not require an administrator to click a link. It is a server compromise path that can leave behind a backdoor outside the normal web root.
Why defenders should look beyond the document root
One important lesson from the incident response details is that the implant may live under the site user’s home directory rather than inside the Magento document root. Published indicators describe a process disguised as [kworker/u:8:0], a name that resembles a Linux kernel thread, and a binary placed at ~/.local/share/.gvfsd/gvfsd-user. A cron entry may restart the implant every five minutes.
That matters because many web-store security checks focus on the application directory. If a scanner is pointed only at the document root, it may miss malware installed one level above it. Administrators should review the full account context available to the Magento user, including user cron files, home-directory hidden folders, temporary directories, and running processes owned by the site account.
A real kernel thread with a bracketed name should be owned by root and should not look like a normal user-space process consuming resident memory. A bracketed [kworker/u:8:0] process owned by the Magento site user is suspicious and should be investigated immediately.
Practical checks for Magento operators
Until an official fix is available, store owners and hosting teams should prioritize detection and containment. Start by searching both var/report/ and var/log/system.log for suspicious injected markers, not just one location. Incident responders have reported marker drift, including variants similar to X_TRACE_, X-TRACE-, and shortened header-like strings, so narrowly matching only one exact value may miss activity.
Review logs for unusual “Payment Transaction Failed Reminder” activity, especially messages that look malformed, contain raw template variables such as {{var ...}}, show .invalid customer addresses, or display zero-value transaction details. These emails can be confusing because they may resemble broken orders, but in this case they may be exhaust from the exploit path.
On the host, inspect cron spools for entries that repeatedly execute a hidden gvfsd-user binary or a temporary .kw_ file. Check for files such as ~/.local/share/.gvfsd/gvfsd-user, lock files matching .gvfsd_ patterns, and unexpected executables under /tmp. Where possible, hash both the file on disk and the running executable through /proc/, because responders observed a case where the in-memory binary differed from the disk copy.
Also review outbound and internal connections from the site user. While some published indicators include command-and-control infrastructure, responders also observed an implant that did not call out and instead held connections to the store’s Redis session storage. That means a lack of obvious external beaconing does not prove the host is clean.
Mitigation while waiting for Adobe
Sansec’s interim recommendation for stores not protected by its Shield product is to temporarily disable GraphQL until Adobe releases a fix. This may be disruptive for headless and progressive web app storefronts, but many traditional Magento storefronts may be able to operate without GraphQL for a short emergency window.
Community responders have also published unofficial web-server rules and code-level hardening, but these should be treated as temporary risk reductions rather than vendor patches. Rules that inspect only query-string parameters may not block variants delivered through POST or JSON bodies. Code patches that restrict Magento dependency-injection scanner behavior may break third-party modules and may be overwritten by future Composer operations if not applied through a maintained patch workflow.
Two defense-in-depth settings are worth reviewing regardless of the exact exploit path: disabling dangerous PHP process-spawning functions, especially proc_open where feasible, and mounting temporary execution locations such as /tmp, /var/tmp, and /dev/shm with noexec. These controls will not fix the vulnerability, but they can make it harder for a PHP dropper to launch a downloaded native implant.
If compromise is suspected
Do not treat this as a quick file cleanup. Preserve evidence first, including logs, cron entries, suspicious binaries, process metadata, and copies from /proc where relevant. Remove persistence before killing the process, because the running implant may recreate its cron entry. Avoid running broad maintenance commands that overwrite timestamps before responders understand what changed.
After containment, invalidate sessions, rotate Magento administrator credentials, rotate the crypt/key in app/etc/env.php where appropriate, and replace payment provider, integration, and database credentials exposed to the application. Even if no skimmer is found, a server-side backdoor with access to session storage and environment secrets is enough to justify credential rotation.
For now, Magento and Adobe Commerce operators should monitor vendor advisories closely, apply the official Adobe fix as soon as it becomes available, and assume that a fully patched store still needs immediate inspection. StyleSmuggler is already being used against real stores, and the absence of a CVE should not delay response.
Source: The Hacker News source