StyleSmuggler: the Magento zero-day Adobe has not patched

How the attack works, in two stages

The attacker first gets PHP written into a file that Magento itself creates, typically an exception report under var/report. Those files are ordinary JSON stack traces, so nothing looks unusual about Magento writing one.

The second stage is the clever part, and it is why the usual defences do not help. Execution is triggered through Magento's Payment Transaction Failed Reminder email function, which runs from cron. That means the injected file never has to be reachable from a browser. Blocking direct access to var/ over HTTP, which most well-configured stores already do, does not stop it.

Successful exploitation installs a persistent backdoor disguised as a Linux kernel thread, which is why it survives a casual look at the process list.

Check your own store, whoever hosts it

This is the script we ran across our own fleet. It is read only. It changes nothing, deletes nothing and sends nothing anywhere. Run it as root on the server your store runs on. If you do not have server access, send it to whoever does.

#!/bin/bash
# StyleSmuggler IOC check. Sansec advisory 2026-09-05. READ ONLY.
HIT=0

echo "[1] Backdoor process"
ps -eo user,pid,args | grep -F 'kworker/u:8:0' | grep -v '^root' | grep -v grep && HIT=1

echo "[2] Backdoor binary"
find /home /root /var/www -maxdepth 7 -path '*/.local/share/.gvfsd/gvfsd-user' 2>/dev/null && HIT=1

echo "[3] Dropper artefacts"
ls -la /tmp/.kw_* /var/tmp/.kw_* /dev/shm/.kw_* 2>/dev/null && HIT=1

echo "[4] Live connections to known C2"
ss -tan 2>/dev/null | grep -E '99\.84\.67\.186|88\.216\.72\.181|5\.181\.86\.133' && HIT=1

echo "[5] PHP injected into Magento report files"
for D in /home/*/public_html /var/www/*; do
  [ -d "$D/var/report" ] || continue
  grep -rlE '<\?=eval\(|<\?php.*eval\(|base64_decode' "$D/var/report" 2>/dev/null && HIT=1
done

echo "[6] Hardening posture"
php -i 2>/dev/null | grep '^disable_functions' | grep -q proc_open \
  && echo "  proc_open disabled: yes" || echo "  proc_open disabled: NO"
for M in /tmp /var/tmp /dev/shm; do
  findmnt -no OPTIONS "$M" 2>/dev/null | grep -q noexec \
    && echo "  $M noexec: yes" || echo "  $M noexec: NO"
done

[ "$HIT" = "0" ] && echo "RESULT: no indicators found" \
  || echo "RESULT: INDICATORS FOUND. Do not clean or reboot. Preserve state."

What we found on our own fleet

We ran the check above on every Magento server we host, on 7 September, two days after Sansec published. No EveryHost customer store was compromised. No backdoor process, no dropper, no command and control traffic on any server.

We did find one injection attempt, on one server, and we are publishing that rather than rounding it to zero. Two files under var/report carried an injected payload. They stood out for three reasons: only two of 3,777 report files on that store matched, both carried old filenames but had been rewritten on 5 September, and both were exactly 8,832 bytes where every normal report on that store is 2,564.

It never executed. The payload carried its own 180 second self-expiry based on the file's modification time, and that window had closed long before we found it. It also required a specific secret HTTP header to run at all. We left both files in place as evidence rather than deleting them.

We are a listed Sansec partner , which is how this reached us quickly. Being the host rather than a plugin vendor is the reason we could check every store ourselves instead of emailing customers a bulletin and hoping.