Magento Zero-Day Under Active Attack: Hackers Backdoor Online Stores Without Authentication

The vulnerability, dubbed “StyleSmuggler” by Dutch e-commerce security firm Sansec, is being exploited in the wild against online stores. Sansec said it observed attacks beginning on September 4, 2026, prompting the company to publish details before an official vendor fix was available.

At the time of reporting, Adobe had not published a CVE identifier, security advisory, patch, or official workaround for the vulnerability. Sansec said its testing demonstrated that the exploit works against multiple current Magento Open Source releases, including versions 2.4.7, 2.4.8 and 2.4.9.

Executive Summary

1. Threat Level: 🔴 Critical
2. Vulnerability: StyleSmuggler zero-day
3. Products: Magento Open Source / Adobe Commerce
4. Authentication Required: No
5. Primary Impact: Remote code execution and persistent backdoor installation
6. Exploitation: Active exploitation observed
7. CVE: Not assigned at the time of reporting
8. Vendor Patch: Not available at the time of reporting
9. Temporary Recommendation: Disable GraphQL where operationally possible

The vulnerability is particularly dangerous because attackers do not need valid administrator credentials to begin the attack. Successful exploitation can provide code execution on the server hosting an online store and allow attackers to establish persistence.

Key Takeaways

• Attackers are actively exploiting a previously undisclosed Magento vulnerability.
• Sansec has named the vulnerability StyleSmuggler.
• The attack can reportedly be performed without authentication.
• Successful exploitation can lead to remote code execution on the Magento server.
• Attackers have been observed installing persistent malware implants.
• Sansec reproduced the exploit against clean Magento Open Source installations running versions 2.4.7, 2.4.8 and 2.4.9.
• Affected stores may remain vulnerable even when they have installed the latest security updates available for their particular release.
• Adobe had not released an official patch or workaround when the vulnerability was disclosed.
• Sansec recommends temporarily disabling GraphQL for stores that do not require it.
• Independent incident-response investigations have confirmed exploitation against multiple Magento stores.

What Is the StyleSmuggler Vulnerability?

StyleSmuggler is the name given by Sansec to a newly discovered vulnerability in Magento's application logic.

Unlike many attacks against e-commerce platforms that rely on stolen administrator credentials, this campaign can reportedly begin without authentication.

The exploit abuses functionality within Magento that processes certain requests and dynamically handles application components. Attackers can manipulate this behavior to cause Magento to execute attacker-controlled PHP code.

The result is a serious server-side code execution vulnerability that can ultimately give attackers control over the web application environment.

Sansec said it was able to reproduce the complete unauthenticated attack chain on clean Magento Open Source installations running versions 2.4.7, 2.4.8 and 2.4.9.

How the Attack Works

According to Sansec's initial analysis, the attack occurs in multiple stages.

1. Attacker Sends a Crafted Request

The threat actor sends specially crafted requests to the vulnerable Magento application.

The attacker does not need to authenticate to the store before initiating the attack.

2. Malicious PHP Code Is Planted

The attack causes Magento to write attacker-controlled PHP content into a file generated by the application.

Sansec identified Magento-generated files such as failure reports as potential locations for the malicious content.

3. Magento Is Triggered to Process the File

The attacker then causes Magento to process the poisoned file through its normal application functionality.

One observed technique abuses the platform's “Payment Transaction Failed Reminder” email functionality.

The malicious code executes when Magento renders the email template, meaning the recipient does not necessarily need to open the email for exploitation to succeed.

4. Remote Code Execution

Once the malicious PHP code is processed, the attacker gains the ability to execute commands on the server.

This provides the foundation for deploying a persistent backdoor.

5. Malware Persistence

Investigators observed attackers installing an implant designed to remain active after the initial compromise.

The malware can disguise itself as a legitimate Linux kernel thread and establish persistence through cron jobs.

What Attackers Can Do After Compromise

Once attackers obtain code execution on an e-commerce server, they can potentially:

• Modify application files
• Create persistence mechanisms
• Access customer information
• Read application configuration
• Access stored sessions
• Steal credentials
• Access API keys
• Modify payment-related functionality
• Deploy additional malware
• Monitor application activity
• Potentially inject payment skimmers

However, independent investigation by Disrex Group into two compromised stores found no evidence of data exfiltration, rogue administrator accounts, payment skimmers or database backdoors on those particular systems.

This distinction is important: successful exploitation does not automatically mean every possible post-exploitation activity occurred.

Persistent Linux Implant Discovered

Investigators identified a Linux-based implant designed to maintain access to compromised stores.

The malware can masquerade as a legitimate kernel worker process using a name such as:

[kworker/u:8:0]

However, researchers noted that a genuine Linux kernel thread is normally owned by root and does not maintain ordinary resident memory in the same way as a user-space process.

A suspicious process using the same name while running under the web application's user account can therefore be an important indicator of compromise.

The implant was also observed using files such as:

~/.local/share/.gvfsd/gvfsd-user

and establishing persistence through cron.

Researchers reported that the malicious cron entry could cause the implant to restart every five minutes.

Affected Versions

Sansec reported that its testing successfully reproduced the attack against multiple current Magento Open Source releases, including:

Product	Version Status
Magento Open Source 2.4.7	Affected
Magento Open Source 2.4.8	Affected
Magento Open Source 2.4.9	Affected
Adobe Commerce	Impact not fully confirmed at initial disclosure
Adobe Commerce on Cloud	Impact not fully confirmed at initial disclosure

Sansec stated that it had not published a reproduction against Adobe Commerce or Adobe Commerce on Cloud at the time of its initial disclosure, and Adobe had not yet confirmed the complete scope of affected versions.

Why This Zero-Day Is Particularly Dangerous

The most concerning aspect of the campaign is the combination of:

No authentication + Remote code execution + Active exploitation + Persistence

An attacker does not need to first compromise an administrator account.

Instead, a vulnerable internet-facing Magento installation may be sufficient to obtain an initial foothold.

For online retailers, this creates several potential risks because the affected server may have access to:

• Customer databases
• Order information
• Payment integrations
• API credentials
• Shipping systems
• Email services
• Cloud resources
• Internal administrative systems

A compromised storefront can therefore become more than a website-security incident—it can become a broader business and supply-chain security problem.

Independent Evidence of Exploitation

Disrex Group independently investigated multiple compromised Magento stores and reported finding exploitation activity.

Two stores hosted by the company were compromised, while a third was targeted but was not successfully breached. The company said both compromised stores were contained on the same day.

One of the stores was running Magento Open Source 2.4.8 and had Sansec Shield enabled, while another was running 2.4.7-p2.

The investigations provided additional evidence that the vulnerability was being actively exploited rather than existing solely as a theoretical proof of concept.

Warning Signs for Store Owners

Administrators should investigate unusual activity involving:

• Unexpected “Payment Transaction Failed Reminder” emails
• Magento errors containing unusual template data
• Suspicious entries in var/log/system.log
• Unexpected files under the Magento installation
• Suspicious files in the account's home directory
• Unknown cron jobs
• Processes masquerading as [kworker/u:8:0]
• Unexpected outbound connections
• Unusual Redis activity
• Unexpected PHP child processes
• Unknown administrator accounts

Disrex noted that some attacks poisoned var/log/system.log rather than var/report/, meaning defenders should not rely on a single directory when hunting for indicators.

Indicators of Compromise

Security teams can use the following indicators reported by Sansec and Disrex as part of their investigation:

Suspicious process:

[kworker/u:8:0]

Suspicious files:

• ~/.local/share/.gvfsd/gvfsd-user
• ~/.local/share/.gvfsd/.gvfsd<8hex>.lock_
• /tmp/.gvfsd<8hex>.lock_

Malicious infrastructure:

• 247.cdnflare[.]xyz
• 99.84.67[.]186:443
• 88.216.72[.]181

Additional indicators and hashes have been published by the researchers investigating the campaign.

Mitigation: What Organizations Should Do Now

Because an official vendor patch was not available at the time of disclosure, Magento administrators should treat this as an active incident-response priority.

1. Disable GraphQL Where Possible

Sansec's interim recommendation is to temporarily disable Magento GraphQL for stores that do not require it.

This is particularly relevant for traditional storefronts that do not depend on GraphQL.

However, headless and progressive-web-application architectures may require GraphQL, so administrators should assess business impact before disabling the functionality.

2. Monitor for Exploitation Attempts

Review web-server and application logs for suspicious requests and unusual Magento error activity.

Do not rely exclusively on the exact indicators already published because attackers can modify their payloads and infrastructure.

3. Search for Persistence

Check for:

• Unexpected cron jobs
• Unknown binaries
• Suspicious user processes
• Modified Magento files
• Unexpected PHP files
• Files outside the web root
• Unusual startup mechanisms

4. Disable proc_open Where Operationally Possible

Disrex recommends disabling PHP's proc_open function as an additional defensive layer.

This is not a replacement for a vendor patch, but it may reduce the ability of a successful exploit to launch external processes.

5. Use noexec Mount Options

Administrators can consider mounting temporary directories such as:

• /tmp
• /var/tmp
• /dev/shm

with the noexec option where compatible with their environment.

This can make it more difficult for downloaded binaries to execute.

6. Rotate Credentials if Compromise Is Suspected

If a store has been compromised, rotate credentials associated with the Magento environment, including:

• Magento administrator passwords
• Database credentials
• API keys
• Payment-provider credentials
• SMTP credentials
• Cloud credentials
• Integration tokens
• SSH keys

Other secrets stored in configuration files

Disrex specifically recommends reviewing and rotating credentials stored in app/etc/env.php.

If Your Store Is Already Compromised

• Incident response should be performed carefully.
• Do not immediately reboot or wipe the server if forensic investigation is required.
• Preserve evidence first and determine how the attacker established persistence.

Disrex recommends removing the malicious persistence mechanism before terminating the malicious process because the malware may otherwise recreate itself. It also recommends flushing Magento session storage and rotating relevant credentials.

Organizations should also consider taking the affected store out of production or placing it behind a maintenance page while the investigation is conducted.

What This Means for E-Commerce Security

The StyleSmuggler campaign highlights the risks associated with internet-facing e-commerce platforms.

Magento installations often sit directly on the internet and interact with highly sensitive systems. A vulnerability that provides unauthenticated server-side code execution can therefore have consequences far beyond website availability.

For security teams, the incident reinforces the importance of:

• Continuous vulnerability monitoring
• Web-application firewalls
• Application-layer logging
• File-integrity monitoring
• Least-privilege service accounts
• Secure credential management
• Network segmentation
• EDR monitoring on web servers
• Regular incident-response exercises
• Rapid threat hunting following zero-day disclosures

Bottom Line

The StyleSmuggler campaign demonstrates how quickly a newly discovered zero-day can move from vulnerability research into active exploitation.

Attackers are targeting Magento-based online stores with an unauthenticated exploit that can provide server-side code execution and establish persistent access. Independent investigations have confirmed compromises of multiple stores.

With no official vendor fix available at the time of disclosure, Magento and Adobe Commerce administrators should focus on exposure reduction, active threat hunting, credential protection and incident detection while closely monitoring Adobe's security advisories for an official remediation.

For merchants, the key message is simple: if your Magento store is exposed to the internet, assume it is a potential target and investigate accordingly.