StyleSmuggler Magento 2 Zero-Day: How to check, mitigate and clean an affected store<

On September 5, 2026, Sansec disclosed StyleSmuggler, a Magento Open Source and Adobe Commerce zero-day vulnerability that allows unauthenticated remote code execution.

Attacks started on September 4 and exploitation is active. Sansec reproduced the complete attack chain on Magento 2.4.7, 2.4.8 and 2.4.9. Their first confirmed victim was running Magento 2.4.6-p15 with the recent July and August security patches already installed. Check more detailed information at Sansec site.

Updated September 8: Adobe has released an official emergency hotfix for StyleSmuggler. The vulnerability is now tracked as CVE-2026-75650, has a CVSS score of 10.0, and Adobe assigned APSB26-146 a Priority 1 rating. Adobe confirms that CVE-2026-75650 is being exploited in the wild.

The malware is also evolving quickly. In addition to the original [kworker/u:8:0] process, Sansec has observed variants disguised as fc-cache and chronyd. A separate attacker using the same StyleSmuggler entry point has also been observed dropping a PHP web shell into pub/media/catalog/product/cache.

The attack works in two stages. Malicious PHP is first injected into Magento-controlled data such as report or log files. Magento is then made to process that data through its template system and execute the injected code.

Official Adobe hotfix: VULN-39341

Adobe published the StyleSmuggler fix on September 7 as a hotfix rather than a full Magento release. Affected stores should apply VULN-39341 immediately. Adobe's official instructions are available in the APSB26-146 Commerce knowledge-base article.

Adobe lists Adobe Commerce 2.4.4 through 2.4.9 branches and Magento Open Source 2.4.6 through 2.4.9 branches at the August 2026 security level or earlier as affected. The hotfix was tested by Adobe against the corresponding 2026-aug releases. Older builds in those branches are affected too, but Adobe notes that hotfix compatibility has not been officially verified for every older build.

Download the hotfix

Download VULN-39341-composer-patches.zip from repo.magento.com:

curl -fSLO https://repo.magento.com/patch/VULN-39341-composer-patches.zip

You can inspect the archive before extracting it:

unzip -l VULN-39341-composer-patches.zip

Then extract it:

unzip VULN-39341-composer-patches.zip

The archive contains Composer patch files. Use the patch appropriate for your Magento or Adobe Commerce version. Adobe uses VULN-39341_Hotfix_COMPOSER.patch as the example patch name in its verification instructions.

Magento Open Source and Adobe Commerce on-premises

Test the patch in staging first and make sure you have a recent backup. From the Magento root, upload or copy the appropriate patch file and apply it:

cd /path/to/magento
patch -p1 < VULN-39341_Hotfix_COMPOSER.patch

If -p1 does not work, Adobe's Composer patch instructions recommend trying -p2:

patch -p2 < VULN-39341_Hotfix_COMPOSER.patch

After applying the patch, flush Magento cache and test storefront, checkout and Admin:

bin/magento cache:flush

Adobe Commerce Cloud

For Adobe Commerce on Cloud infrastructure, place the appropriate Composer patch in the project's m2-hotfixes directory and deploy it through Git:

mkdir -p m2-hotfixes
cp VULN-39341_Hotfix_COMPOSER.patch m2-hotfixes/
git add -A
git commit -m "Apply VULN-39341 StyleSmuggler hotfix"
git push origin

Adobe recommends Cloud merchants verify that the patch is applied with:

vendor/bin/magento-patches -n status | grep "39341\|Status"

The VULN-39341 entry should show Applied.

Also install the September 2026 security update

Adobe released its regular September 2026 Commerce security update, APSB26-138, on September 8. Adobe explicitly states that the VULN-39341 hotfix for CVE-2026-75650 must be applied in addition to the September security update.

Patching and cleanup are separate tasks. VULN-39341 closes the StyleSmuggler vulnerability, but it does not remove a backdoor, cron persistence or PHP web shell that may already have been installed before the patch was applied.

Adobe also recommends rotating the Magento encryption key and all credentials that may have been exposed, including Admin passwords, REST/SOAP/GraphQL integration tokens, OAuth secrets, payment-provider credentials, database credentials, SSH/deployment keys and third-party API credentials. Rotate credentials at their source; changing the Magento encryption key alone does not invalidate credentials an attacker may already have copied.

If you manage a Magento server, there are four separate jobs:

Apply the official Adobe VULN-39341 hotfix.
Check whether the server was already compromised before the patch was installed.
If the hotfix cannot be deployed immediately, use temporary containment such as blocking /graphql.
If compromised, preserve evidence, remove malware and persistence, audit the Magento system account and rotate exposed credentials.

Blocking GraphQL is temporary containment. It does not replace the Adobe hotfix and does not clean an already compromised server.

1. Check whether the Magento server is already compromised

Start with read-only checks. Do not immediately reboot the machine, delete files or redeploy Magento.

StyleSmuggler has already used several different process names and persistence locations. Do not rely on a single indicator.

Quick StyleSmuggler check

Run these commands from the Magento root:

crontab -l 2>/dev/null | grep -Ei 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig'
ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc_*.lock /tmp/.fc-*/fc-cache /tmp/fc-cache /tmp/.chrony-*/chronyd 2>/dev/null
ps -eo user,pid,ppid,stat,comm,args | grep -iE '[k]worker|[f]c-cache|[c]hronyd'
grep -Rni 'crontab command not allowed' /var/log/ 2>/dev/null
grep -Ril 'x_trace_' var/report/ var/log/ 2>/dev/null
find pub/media -type f -name '*.php' -print

If you have root access, also inspect the cron spool directly:

sudo grep -RniE 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig|\.local/share/\.gvfsd' /var/spool/cron* /etc/cron* 2>/dev/null

No output from one command does not prove the server is clean. The checks below explain what each result means.

Check suspicious processes

The original implant was disguised as:

[kworker/u:8:0]

Later builds observed on September 6 and 7 used the legitimate-looking process names:

fc-cache
chronyd

Run:

ps -eo user,pid,ppid,stat,comm,args | grep -iE '[k]worker|[f]c-cache|[c]hronyd'

Do not treat every match as malware. Normal Linux servers have legitimate kernel workers, fc-cache and often chronyd.

Real kernel workers normally run as root, have PPID 2 and appear as kernel threads. For fc-cache and chronyd, the executable path is more useful than the process name.

Check running fc-cache and chronyd processes:

for PID in $(pgrep -x fc-cache; pgrep -x chronyd); do echo "=== PID $PID ==="; ps -o user,pid,ppid,args -p "$PID"; echo -n "EXE: "; readlink -f /proc/$PID/exe 2>/dev/null; done

Normal system paths may look like:

/usr/bin/fc-cache
/usr/sbin/chronyd

Known malicious paths include:

~/.cache/fontconfig/fc-cache
/tmp/.fc-<8hex>/fc-cache
/tmp/fc-cache
/tmp/.chrony-<8hex>/chronyd

Check cron persistence

Known malicious cron entries include patterns similar to:

*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user
13,43 * * * * <home>/.cache/fontconfig/fc-cache >/dev/null 2>&1
57,27 * * * * /tmp/.chrony-<8hex>/chronyd >/dev/null 2>&1

Check the current user's crontab:

crontab -l 2>/dev/null | grep -Ei 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig'

Some observed variants wrote directly into the cron spool instead of using the normal crontab command. With root access, check the spool and system cron files directly:

sudo grep -RniE 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig|\.local/share/\.gvfsd' /var/spool/cron* /etc/cron* 2>/dev/null

The September 7 chronyd variant has also been observed relaunching without any cron entry, so an empty crontab is not proof that a host is clean.

Check failed cron persistence attempts

On servers where the web user is not allowed to write a crontab, the implant may repeatedly generate messages such as crontab command not allowed.

grep -Rni 'crontab command not allowed' /var/log/ 2>/dev/null

Repeated entries for the Magento or web server user are a strong reason to investigate the server further.

Check known dropped-file locations

Run:

ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc_*.lock /tmp/.fc-*/fc-cache /tmp/fc-cache /tmp/.chrony-*/chronyd 2>/dev/null

Known locations currently include:

~/.local/share/.gvfsd/gvfsd-user
~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
~/.cache/fontconfig/fc-cache
/tmp/.kw_<random>
/tmp/.cache_<random>
/tmp/.gvfsd-*
/tmp/.fc_<8hex>.lock
/tmp/.fc-<8hex>/fc-cache
/tmp/fc-cache
/tmp/.chrony-<8hex>/chronyd

An important detail is that the implant is installed outside the Magento document root. A malware scan limited to pub, public_html or the Magento project directory can therefore report the store as clean while the implant continues to run from the user's home directory or /tmp.

Check Magento report and log files

Observed variants used Magento's own files during the first stage of exploitation.

Check both var/report and var/log:

grep -Ril 'x_trace_\|<?php' var/report/ var/log/ 2>/dev/null

To inspect the surrounding content:

grep -Rni -B5 -A10 'x_trace_' var/report/ var/log/ 2>/dev/null

Finding X_TRACE_ in system.log, exception.log or a Magento report does not mean that the log file itself is malware. These are normal Magento files. However, the marker is evidence that the StyleSmuggler exploitation path may have been reached, so the server should be checked for processes, persistence and dropped files. Preserve the matching logs before cleaning them.

Check for PHP web shells in media

On September 7, Sansec reported a second attacker using StyleSmuggler to drop a PHP web shell into Magento's product image cache.

Check the entire media directory:

find pub/media -type f -name '*.php' -print

One observed pattern was:

pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php

Do not restrict the search to this exact filename. Attackers can change filenames and locations. Any unexpected PHP file under pub/media should be investigated.

Latest Sansec indicators

Sansec's September 7 update added several useful network and file indicators. Treat these as investigation leads and correlate them with timestamps, processes and request logs.

Current command-and-control indicators include:

99.84.67.186:443
185.157.160.251:123
windwsecurity.run:443
ntp.timesysnc.net:123
time.microsft.run:123
pool.microsft.studio:123
ntp.timesync.to:123
ntp.synctime.to:123
ntp.syncstime.to:123

Additional attacker-source IPs reported by Sansec include:

88.216.72.181
182.182.152.48
76.31.99.207
209.73.130.148
77.239.124.107

New file hashes include:

sha256 1a3374ffac5b0a62467612f264c49792d206304d4514409c982325c91231375d  chronyd variant
sha256 d61217ca0bca83204302fa7b41935ce36f73764559c156d5c980f2fedddffb6e  PHP dropper

The second attacker's PHP web shell requires this header value and otherwise returns a 404:

X-Cache-Token: fced27f6d57702565353ecc11722533b

Campaign markers observed in the attack chain include:

ss5_457cfa2fb7
ss6_457cfa2fb7_

You can search Magento and web server logs for these markers:

grep -RniE 'fced27f6d57702565353ecc11722533b|ss5_457cfa2fb7|ss6_457cfa2fb7_' var/log/ var/report/ /path/to/access.log 2>/dev/null

And check current connections against the two published C2 IPs:

ss -tunap 2>/dev/null | grep -E '99\.84\.67\.186|185\.157\.160\.251'

Check web server access logs

Adjust the path to the access log for your server:

grep -acE 'styles(\[|%5B)|generatorClass|with_resolved|cdnflare|ss5_457cfa2fb7|ss6_457cfa2fb7_|88\.216\.72\.181|182\.182\.152\.48|76\.31\.99\.207|209\.73\.130\.148|77\.239\.124\.107' /path/to/access.log

You can also inspect matching requests:

grep -aE 'styles(\[|%5B)|generatorClass|with_resolved|cdnflare|ss5_457cfa2fb7|ss6_457cfa2fb7_|88\.216\.72\.181|182\.182\.152\.48|76\.31\.99\.207|209\.73\.130\.148|77\.239\.124\.107' /path/to/access.log

Sansec lists malicious requests to /graphql with styles[...] parameters among the observed indicators.

Unexpected bursts of Magento's Payment Transaction Failed Reminder emails are another useful signal. The victim does not have to open the email—the malicious code executes while Magento renders it.

2. If you find a suspicious process, inspect it before killing it

Do not immediately run kill -9.

First record what the process is doing.

Assume the suspicious PID is 7908:

PID=7908

Inspect it:

ps -fp "$PID"

Check the executable:

ls -l /proc/$PID/exe
readlink -f /proc/$PID/exe

Check its current working directory:

ls -l /proc/$PID/cwd

Check files opened by the process:

lsof -nP -p "$PID"

Check its network connections, including UDP:

ss -tunp | grep "pid=$PID,"

or:

lsof -nP -i -a -p "$PID"

The newer fc-cache and chronyd variants disguise command-and-control traffic as NTP over UDP port 123. A suspicious process communicating repeatedly over UDP/123 deserves closer inspection. Do not assume traffic is legitimate only because the process is called chronyd.

Don't look only for external connections

This became particularly important during our own investigation.

On one affected server the suspicious kworker process did not expose an obvious external command-and-control connection. Instead, the process had several established connections to the Magento server's own Redis instance.

We identified the Redis endpoint with:

lsof -nP -iTCP:21113

The same Redis process was listening on that port while the suspicious kworker process was connected to it.

You can also identify what is listening on a suspicious port with:

ss -ltnp | grep ':21113'

Replace 21113 with the port found in your connection output.

This matters because an infected server may show no suspicious outbound connection at all. The malware may communicate through services already available to the Magento account, including Redis.

3. Preserve evidence before cleaning the server

If the previous checks indicate compromise, save the state before changing it.

Create a private incident directory:

Q=~/incident-$(date +%Y%m%d-%H%M)
mkdir -p "$Q"
chmod 700 "$Q"

Save the running process list:

ps -eo pid,ppid,user,lstart,rss,args > "$Q/processes.txt"

Save the suspicious process information:

ls -l /proc/$PID/exe /proc/$PID/cwd > "$Q/proc-links.txt" 2>&1
ls -l /proc/$PID/fd/ > "$Q/proc-fds.txt" 2>&1
cat /proc/$PID/status > "$Q/proc-status.txt" 2>&1

If the executable has already been deleted from disk, /proc/$PID/exe may still contain the running binary.

Copy it before killing the process:

cp /proc/$PID/exe "$Q/implant.bin" 2>/dev/null

Hash it:

sha256sum "$Q/implant.bin"

Save cron:

crontab -l > "$Q/crontab.txt" 2>&1

Save network connections:

(ss -tanp 2>/dev/null || netstat -tanp 2>/dev/null) > "$Q/connections.txt"

Save relevant Magento and web server logs before modifying them:

cp -a var/log "$Q/magento-log"
cp -a var/report "$Q/magento-report"
cp -p /path/to/access.log "$Q/access.log"

Do this before running Composer or redeploying Magento. A deployment can replace modified files and timestamps that would otherwise help establish what happened.

Also avoid rebooting at this stage. /proc/<pid>/exe can be the only remaining copy of a malware binary that deleted its original file after starting.

4. Block new StyleSmuggler attacks

The official Adobe VULN-39341 hotfix is now the primary remediation. Use GraphQL blocking only as temporary containment if you cannot deploy the hotfix immediately, or while you are preserving evidence and preparing the patch.

Before disabling GraphQL, verify whether the store actually uses it.

Headless and PWA storefronts depend on it. Some Magento themes and third-party integrations may also use GraphQL.

Check recent traffic:

grep -c '"POST /graphql' /path/to/access.log

A zero does not absolutely prove GraphQL is unused, but it is a useful first check.

Option 1: Cloudflare

If the store uses Cloudflare, an edge rule is usually the quickest option.

Create a WAF/custom rule matching:

http.request.uri.path eq "/graphql"

and set the action to:

Block

If your setup also accepts a trailing slash, block both:

/graphql
/graphql/

Blocking at Cloudflare has the advantage that malicious GraphQL requests never reach the Magento server.

Option 2: Nginx

For a Magento installation that does not need GraphQL:

location ^~ /graphql {
return 403;
}

Validate the configuration before reloading:

nginx -t

Verify:

curl -I https://YOURSTORE/graphql

You should receive 403.

Option 3: Apache

For Apache with rewrite rules:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/graphql/?$ [NC]
RewriteRule ^ - [F,L]

Verify afterwards:

curl -I https://YOURSTORE/graphql

Again, the expected result is 403.

Option 4: Magento CLI — least recommended

You may also see advice to disable GraphQL using Magento's module system.

First inspect GraphQL modules:

bin/magento module:status | grep -i GraphQl

The obvious command would be:

bin/magento module:disable Magento_GraphQl

We consider this the least recommended approach.

Magento_GraphQl is a base Magento module and many GraphQL modules depend on it. Depending on the Magento version and installed extensions, Magento may refuse to disable it because of dependencies.

Do not solve that by blindly running:

bin/magento module:disable Magento_GraphQl --force

on a production store.

For emergency containment, blocking /graphql at Cloudflare, Nginx or Apache is simple and reversible. Once VULN-39341 is installed and verified, review whether this temporary block is still required for your store.

5. Apply and verify the official Adobe hotfix

If you have not already applied VULN-39341 using the instructions at the beginning of this article, do it before returning the store to normal operation.

Download and inspect the archive:

curl -fSLO https://repo.magento.com/patch/VULN-39341-composer-patches.zip
unzip -l VULN-39341-composer-patches.zip
unzip VULN-39341-composer-patches.zip

For Magento Open Source and Adobe Commerce on-premises, apply the appropriate Composer patch from the Magento root:

patch -p1 < VULN-39341_Hotfix_COMPOSER.patch
bin/magento cache:flush

If -p1 does not work, Adobe recommends trying -p2. For Adobe Commerce Cloud, place the patch in m2-hotfixes and deploy it through the normal Git workflow.

Cloud merchants can verify application with:

vendor/bin/magento-patches -n status | grep "39341\|Status"

Adobe's regular September 2026 security release APSB26-138 does not replace this hotfix. Adobe says to apply VULN-39341 in addition to the September security update.

What about the community StyleSmuggler mitigation?

The DISREXM community mitigation was useful before Adobe released an official fix. It should no longer be treated as the primary remediation. If you installed it, test the official Adobe hotfix in staging and review the community workaround as part of that deployment rather than assuming it replaces VULN-39341.

6. Clean an infected server

Mitigation stops another attack. It does not remove an existing implant, cron persistence or PHP web shell.

The cleanup order matters.

6.1 Remove cron persistence first

Check the current user's crontab:

crontab -l 2>/dev/null

Remove suspicious entries referring to known malware locations such as:

.local/share/.gvfsd/gvfsd-user
.cache/fontconfig/fc-cache
/tmp/.chrony-*/chronyd

Verify:

crontab -l 2>/dev/null | grep -Ei 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig'

If you have root access, inspect the cron spool and system cron files directly:

sudo grep -RniE 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig|\.local/share/\.gvfsd' /var/spool/cron* /etc/cron* 2>/dev/null

Do this before killing the malware process. Otherwise persistence may simply start another copy. Remember that the chronyd variant has also been observed running without cron, so cleanup must include the process and files as well.

6.2 Kill the malicious process

Once persistence has been removed and evidence preserved:

kill "$PID"

Check:

ps -p "$PID"

If the process refuses to exit:

kill -9 "$PID"

Then repeat the process check:

ps -eo user,pid,ppid,stat,comm,args | grep -iE '[k]worker|[f]c-cache|[c]hronyd'

Investigate the executable path of any remaining unexpected fc-cache or chronyd process before taking action against it.

6.3 Remove known malware files

Only remove files after preserving copies and confirming that they are malicious.

Known malicious paths currently include:

~/.local/share/.gvfsd/gvfsd-user
~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
~/.cache/fontconfig/fc-cache
/tmp/.kw_*
/tmp/.cache_*
/tmp/.gvfsd-*
/tmp/.fc_*.lock
/tmp/.fc-*/fc-cache
/tmp/fc-cache
/tmp/.chrony-*/chronyd

Do not blindly remove legitimate system binaries such as:

/usr/bin/fc-cache
/usr/sbin/chronyd

Check the executable behind a suspicious process with:

readlink -f /proc/PID/exe

After cleanup, repeat:

ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc_*.lock /tmp/.fc-*/fc-cache /tmp/fc-cache /tmp/.chrony-*/chronyd 2>/dev/null

6.4 Remove poisoned Magento files

Find suspicious files again:

grep -Ril 'x_trace_\|<?php' var/report/ var/log/ 2>/dev/null

Do not delete Magento logs simply because they contain X_TRACE_. The files themselves are normal Magento logs. Preserve them as incident evidence and inspect the matching content first.

Once copies have been saved, remove affected report files or rotate/clean injected log content as appropriate for the installation.

6.5 Remove PHP web shells

Check again for PHP files under media:

find pub/media -type f -name '*.php' -print

Unexpected PHP files under pub/media, especially inside catalog/product/cache, should be treated as possible backdoors. Preserve a copy and hash before removing a confirmed malicious file.

7. Check for other persistence and backdoors

Removing one known StyleSmuggler implant does not prove the server is clean.

The attacker had code execution as the Magento system user and could write anywhere that user had permission.

Check other cron mechanisms

crontab -l 2>/dev/null

sudo crontab -l 2>/dev/null

Check user and system cron files directly:

sudo grep -RniE 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig|\.local/share/\.gvfsd' /var/spool/cron* /etc/cron* 2>/dev/null

Also inspect system cron directories:

ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/ /etc/cron.monthly/ 2>/dev/null
cat /etc/crontab 2>/dev/null

Check timers:

systemctl list-timers --all 2>/dev/null
systemctl --user list-timers --all 2>/dev/null

Check user systemd units:

ls -la ~/.config/systemd/user/ 2>/dev/null

Check SSH access

Inspect:

cat ~/.ssh/authorized_keys

Every key should be accounted for.

Also check timestamps:

ls -la ~/.ssh/

Check shell startup files

Search for obvious downloaders and persistence:

grep -nE 'curl|wget|base64|/tmp/\.|gvfsd|kworker|fc-cache|chronyd|\.chrony-' ~/.bashrc ~/.bash_profile ~/.profile ~/.zshrc ~/.bash_login 2>/dev/null

Check PHP persistence

Look for PHP configuration that automatically executes another file:

grep -rn 'auto_prepend_file\|auto_append_file' .user.ini .htaccess /etc/php*/ 2>/dev/null

Look for PHP files uploaded into media:

find pub/media -type f -name '*.ph*' -print 2>/dev/null

And recently modified PHP files:

find app vendor pub -type f -name '*.php' -newermt '30 days ago' 2>/dev/null

Check suspicious UDP/123 traffic

The fc-cache and chronyd variants use custom traffic shaped to look like NTP over UDP port 123.

Check current UDP connections:

ss -uapn | grep ':123'

If you have root access and need to inspect traffic:

sudo timeout 70 tcpdump -ni any -nn 'udp port 123'

Legitimate NTP traffic also uses UDP/123. The process, destination and traffic pattern must be considered together. Do not whitelist a process solely because it is called chronyd.

8. Compare the Magento filesystem with known-good code

If the project is stored in Git:

git status --short

Then:

git diff --stat

Find untracked PHP/PHTML files:

git ls-files --others --exclude-standard \
| grep -E '\.(php|phtml)$'

Anything unexpected in:

app/code
vendor
pub
setup

needs investigation.

Do not assume that reinstalling vendor/ alone solves the problem. The malware process runs as the Unix site user and is not limited to Magento PHP code.

9. Check Magento database content

The attacker could access the same database credentials available to Magento.

Check Admin users:

SELECT
user_id,
username,
email,
created,
logdate,
is_active
FROM admin_user
ORDER BY created DESC;

Look for unknown or recently created accounts.

Check integrations:

SELECT
integration_id,
name,
created_at,
status
FROM integration;

Check recent OAuth tokens:

SELECT *
FROM oauth_token
ORDER BY created_at DESC
LIMIT 20;

Check configuration for obvious JavaScript injection:

SELECT
config_id,
scope,
scope_id,
path,
LEFT(value, 300)
FROM core_config_data
WHERE value LIKE '%<script%'
OR value LIKE '%eval(%'
OR value LIKE '%atob(%'
OR value LIKE '%fromCharCode%';

Check recently modified CMS blocks:

SELECT identifier, update_time
FROM cms_block
WHERE update_time > NOW() - INTERVAL 30 DAY
ORDER BY update_time DESC;

And CMS pages:

SELECT identifier, update_time
FROM cms_page
WHERE update_time > NOW() - INTERVAL 30 DAY
ORDER BY update_time DESC;

These queries are not StyleSmuggler signatures. They are simply useful places to look for persistence or injected storefront JavaScript after a server compromise.

10. Check Redis and invalidate sessions

Redis deserves special attention in this incident.

First check Magento's Redis configuration:

grep -nA40 "'cache'" app/etc/env.php
grep -nA30 "'session'" app/etc/env.php

Identify:

Redis host
port or socket
cache database
page-cache database
session database

Then inspect connections:

lsof -nP -iTCP:<REDIS_PORT>

or:

ss -tnp | grep ':<REDIS_PORT>'

If you found a suspicious PID earlier:

ss -tpn | grep "pid=$PID,"

If Redis is used for customer/admin sessions, invalidate the session database after containment.

For example:

redis-cli -h <HOST> -p <PORT> -n <SESSION_DB> FLUSHDB

Use FLUSHDB against the specific Magento database rather than blindly running:

redis-cli FLUSHALL

especially on shared hosting or a Redis instance used by multiple applications.

Flushing the Magento session database logs out customers and administrators. After a server compromise, that is desirable because existing authenticated sessions must be treated as potentially exposed.

11. Rotate encryption key and credentials

Adobe now explicitly recommends rotating the Magento encryption key and all credentials that may have been encrypted or exposed after applying VULN-39341. If the server was compromised, first remove active malware and persistence so the attacker cannot simply capture the new credentials.

At minimum review and rotate:

Magento Admin passwords
database credentials
Magento integration/API tokens
OAuth tokens
SSH keys accessible to the site user
deployment keys
payment-provider credentials
SMTP credentials
ERP, CRM and fulfillment API credentials
CDN and third-party service credentials
secrets stored in deployment configuration

Rotate credentials at their source whenever possible. For example, payment gateway credentials should be regenerated with the payment provider, and third-party API keys should be regenerated with the corresponding service. Rotating Magento's encryption key alone does not invalidate credentials that an attacker may already have copied.

Inspect app/etc/env.php carefully.

Do not simply replace Magento's crypt/key value manually on a production store. Magento uses this key to encrypt stored configuration values. If the key is considered exposed, encrypted secrets need a controlled rotation/re-encryption procedure.

Also invalidate active Admin sessions after changing Admin credentials.

Credentials should be rotated after containment. Changing passwords while the attacker still has active execution on the server can simply expose the new credentials as well.

12. Verify that the server stays clean

Repeat the compromise checks after cleanup.

Processes

ps -eo user,pid,ppid,stat,comm,args | grep -iE '[k]worker|[f]c-cache|[c]hronyd'

For any unexpected fc-cache or chronyd process, check the executable path:

for PID in $(pgrep -x fc-cache; pgrep -x chronyd); do echo "=== PID $PID ==="; ps -o user,pid,ppid,args -p "$PID"; echo -n "EXE: "; readlink -f /proc/$PID/exe 2>/dev/null; done

Cron

crontab -l 2>/dev/null | grep -Ei 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig'

With root access:

sudo grep -RniE 'gvfsd|fc-cache|chronyd|\.chrony-|\.cache/fontconfig|\.local/share/\.gvfsd' /var/spool/cron* /etc/cron* 2>/dev/null

Malware files

ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc_*.lock /tmp/.fc-*/fc-cache /tmp/fc-cache /tmp/.chrony-*/chronyd 2>/dev/null

Magento reports and logs

grep -Ril 'x_trace_\|<?php' var/report/ var/log/ 2>/dev/null

Old X_TRACE_ entries may remain in preserved Magento logs after cleanup. Their presence alone does not prove that the implant is still active. Check timestamps and correlate them with processes, cron and dropped files.

PHP files in media

find pub/media -type f -name '*.php' -print

Cron permission errors

grep -Rni 'crontab command not allowed' /var/log/ 2>/dev/null

Network connections

lsof -nP -i -a -u "$USER" 2>/dev/null

Also review UDP port 123:

ss -uapn | grep ':123'

Look for unexpected long-running processes communicating with Redis or external hosts. For NTP-shaped traffic, check which executable owns the connection rather than trusting the process name.

GraphQL

If GraphQL was disabled:

curl -sk -o /dev/null -w '%{http_code}
' 'https://YOURSTORE/graphql'

Expected:

Storefront

curl -sk -o /dev/null -w '%{http_code}
' 'https://YOURSTORE/'