StyleSmuggler Zero-Day Gives Attackers Remote Control of Patched Magento Stores

A previously unknown vulnerability dubbed StyleSmuggler is being actively exploited against Magento and Adobe Commerce stores, including systems running current security updates.

The attack provides unauthenticated remote code execution through Magento’s template-processing and GraphQL-related handling. Successful intrusions have installed a Rust-based Linux backdoor and, in some cases, a concealed PHP web shell.

SecurityAffairs publicly detailed the campaign on September 7, 2026, attributing the technical investigation to Sansec. The earliest observed exploitation occurred on September 4.

No CVE identifier, CVSS score, or official Adobe severity rating has been disclosed. The vulnerability’s status in the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog is also not known.

Current and fully patched stores remain exposed

StyleSmuggler affects Magento Open Source and Adobe Commerce, but an authoritative version matrix is not yet available.

Sansec reproduced the exploit on clean installations and identified an initial victim running Magento 2.4.6-p15 with the July and August 2026 security updates installed. Current Magento Open Source releases specifically identified as affected include:

• Magento Open Source 2.4.7
• Magento Open Source 2.4.8
• Magento Open Source 2.4.9

A separate account describes all Magento and Adobe Commerce versions as vulnerable. Until Adobe publishes an advisory, administrators should not assume an older, newer, or fully patched release is safe.

The exposure is substantial. Magento reportedly runs on more than 160,000 websites, including approximately 14,000 of the top one million sites. A server-side compromise can place customer records, administrative credentials, API tokens, payment-provider secrets, database passwords, and cloud access keys within an attacker’s reach.

Adobe was reportedly preparing a fix. A scheduled security release was expected on September 8, but it was not known whether StyleSmuggler remediation would be included.

A failed-payment notification becomes the execution trigger

The exploit targets Magento’s template-rendering pipeline. It injects PHP through processing associated with the styles property and GraphQL, bypassing controls intended to reject dangerous template content.

The observed chain has two main steps. First, an unauthenticated attacker creates or poisons a Magento record containing malicious PHP. One demonstrated route involves generating a failed-payment report.

Magento subsequently renders its standard Payment Transaction Failed Reminder notification. During that operation, the platform evaluates the poisoned content and executes the embedded PHP on the server.

No customer or administrator needs to open an attachment or follow a link. The exploit can succeed even if the notification email is never delivered because execution occurs during Magento’s server-side rendering process.

An unexplained increase in failed-payment reminders may therefore indicate exploitation. It is not definitive evidence, since genuine payment failures produce the same notification type.

Changing Magento’s session backend does not reliably block the attack. In one incident, an attempt involving session storage failed. Eight seconds later, the same operator switched to a file uploaded through Magento’s custom-options functionality and achieved code execution.

That rapid change suggests attackers are actively adapting their delivery methods. Defenses built around a single payload location or proof-of-concept pattern are unlikely to be sufficient.

Rust backdoor hides behind Linux process names and NTP traffic

Successful attacks have deployed a compact Rust-based Linux implant. The malware runs in the background, connects to attacker-controlled infrastructure, and waits for commands.

No subsequent commands from the implant had been observed when the findings were published. However, a host running the backdoor must still be treated as compromised because the operator retains remote command capability.

The malware has changed its process masquerading between samples:

• An early sample appeared as [kworker/u:8:0]
• A variant seen on September 6 used fc-cache
• A sample seen on September 7 used chronyd

These names imitate a kernel worker, the Linux font-cache utility, and a common time-synchronization daemon. Process names alone cannot distinguish the implant from legitimate software.

The fc-cache version copied itself to ~/.cache/fontconfig/fc-cache, created a PID lock file, and established cron persistence. Its scheduled task relaunched the implant every 30 minutes.

Other builds used different persistence. One chronyd variant relied on cron, while another restarted itself without leaving a visible cron entry. An empty crontab is therefore not evidence that a server is clean.

Earlier samples communicated through TLS and WebSockets. Newer versions disguise command-and-control traffic as Network Time Protocol activity by sending UDP packets to port 123.

The implant resolves ntp.timesync.to every 60 seconds and transmits 48-byte packets resembling NTP server responses. Only the first four bytes follow a conventional NTP-like structure. The remaining data can carry the implant identifier, hostname, username, operating-system version, uptime, memory and disk usage, root status, and malware version.

The observed domains were associated with 185.157.160.251 on September 7. The backdoor can also query ipify, icanhazip, ident.me, and ipinfo.io to determine the server’s public IP address.

Before beaconing, it checks Linux’s TracerPid value for evidence of debugging or tracing. If tracing is detected, the malware still installs but suppresses its network communications.

A second actor concealed a web shell in image-cache directories

Investigators also found evidence of an apparently separate operator exploiting compromised stores. This actor installed a small PHP dropper that wrote a web shell into Magento’s product-image cache.

The shell was placed beneath hash-like directory names, helping it blend into generated cache content. It normally returned an ordinary-looking 404 response.

The malicious functionality became available only when a request supplied the correct X-Cache-Token header. The shell would then execute PHP received through a POST parameter.

Before installing the shell, the dropper contacted:

457cfa2fb7p5.daf892t5qau4og8pi4cghbc6fhm1dim3u.oast.site

That address belongs to a public out-of-band testing service commonly used to confirm that injected code has executed. The recovered payload originated from a Magento Store request header, while its PHP tags remained JSON-escaped in Magento’s stored record.

Removing a visible Rust process is consequently not enough. An affected server may also contain modified records, poisoned templates, uploaded payloads, cron persistence, and PHP shells hidden in writable media or cache locations.

Indicators defenders should investigate now

Magento operators should correlate application, host, DNS, and network telemetry rather than relying on a single indicator. Priority checks include:

• Surges in Payment Transaction Failed Reminder activity
• Unexpected PHP or JSON-escaped PHP tags in Magento records
• Modified templates, suspicious reports, and unusual custom-options uploads
• Processes named [kworker/u:8:0], fc-cache, or chronyd running from abnormal paths
• The file ~/.cache/fontconfig/fc-cache
• Cron jobs executing suspicious binaries every 30 minutes
• Repeated crontab: command not allowed messages involving accounts such as www-data
• PHP files beneath pub/media, especially product-image cache directories
• Requests containing the X-Cache-Token header
• DNS requests for ntp.timesync.to
• Connections involving 185.157.160.251
• Unexpected outbound UDP/123 traffic or 48-byte NTP-like packets
• The listed OAST domain in Magento, web-server, DNS, or proxy logs

A legitimate-looking chronyd process producing nine rapid NTP server-mode packets every minute is particularly suspicious. Administrators should compare such traffic with the host’s configured time sources and normal synchronization pattern.

Indicators may change quickly. The campaign has already shifted process names, persistence techniques, and exploitation routes between September 6 and September 7.

Disable GraphQL where possible and treat detections as compromise

Until Adobe releases and administrators apply an official fix, Sansec recommends temporarily disabling GraphQL where operationally possible. This may break storefront functions or external integrations, so organizations should test the effect and consider compensating controls where GraphQL cannot be disabled.

Teams should inspect writable Magento directories, cron spool files, process trees, authentication logs, web-server records, DNS history, and outbound UDP/123 traffic. Finding any StyleSmuggler indicator should trigger host isolation and forensic preservation.

Incident response should also include rotation of Magento administrator passwords, API tokens, database credentials, payment-provider secrets, and cloud keys accessible from the server. Before restoring service, responders should search for secondary web shells, malicious records, altered templates, uploaded executables, and persistence outside cron.

A clean patch status does not protect against this campaign. Until a verified remediation is available, exposed Magento and Adobe Commerce systems should be monitored as potentially vulnerable—and systems showing related indicators should be handled as already compromised.