Magento / Adobe Commerce “StyleSmuggler” — CVE-2026-75650

Adobe Commerce and Magento Open Source (versions 2.4.4 through 2.4.9, plus Adobe Commerce B2B 1.3.3–1.5.3) carry an unauthenticated, network-exploitable remote code execution flaw — CVE-2026-75650, CVSS 10.0, CWE-1336 (Improper Neutralization of Special Elements Used in a Template Engine) — publicly nicknamed StyleSmuggler by discoverer Sansec. The attacker's objective is straightforward: smuggle PHP into Magento's template engine via a styles property, then force the platform to render its own standard “Payment Transaction Failed Reminder” email template so the poisoned content is loaded and executed through a dependency-injection file-include path — no valid account, and no victim interaction, required. Exploitation began 2026-09-04 22:20 UTC; Adobe shipped emergency bulletin APSB26-146 and hotfix VULN-39341 on 2026-09-07, roughly three days later. Critically, Sansec's first confirmed compromised customer was already running the July and August 2026 security patches — this is a true zero-day, and "fully patched before September 7" does not mean "was never exposed."

Two independent payload families have been observed riding the same RCE: a Rust-based Linux backdoor that renames itself to blend in with legitimate system processes ([kworker/u:8:0], fc-cache, chronyd, and a gvfsd-themed variant referenced in the researcher's own hunt commands), persists via cron, and beacons every 60 seconds over UDP/123 disguised as NTP traffic to a small set of C2 hosts including 99.84.67.186; and, from an apparently unrelated actor, a 485-byte PHP web shell dropper that plants a header-gated shell inside Magento's own product-image cache directory (pub/media/catalog/product/cache/...).

The highest-value defensive angle is layered: (1) the vendor patch closes the door — apply VULN-39341 now; (2) the masquerading process names and disguised-NTP C2 beacon are distinctive and cheap to hunt on Linux endpoint telemetry even without knowing every future C2 IP; (3) the web shell's file-write location and required X-Cache-Token header make it a strong indicator once WAF/app-log visibility exists; and (4) because RCE predates public detection content by days, every internet-facing store that was reachable between 2026-09-04 and patch application needs a retrospective compromise review, not just a version check.

Defender priority: Patch first (VULN-39341), then hunt for the masquerading Linux process names and the disguised-NTP C2 beacon — these two signals catch the RCE's most-observed payload even for stores compromised before the hotfix existed, and they require no updated IOC feed to be useful.

Five sources were fetched live and saved verbatim to Magento-StyleSmuggler-CVE-2026-75650-Hunt-sources/ before any fact in this pack was written. All five were reviewed for injected/adversarial instructions directed at an AI agent — none were found; all fetched content was analyzed strictly as data. No source's content was used to override or replace the independently-corroborated C2 IP (99.84.67.186) supplied in the original tasking.

Cross-reference notes: C2 IP 99.84.67.186 is corroborated by two independent sources (Sansec, CSO Online) and matches the value supplied in the original tasking — no source suggested a different value, so no substitution risk applies. No file hashes were recovered verbatim from any fetched source despite Sansec stating hashes exist for the backdoor and dropper — those hash values are therefore shipped as labelled REPLACE_WITH_SHA256 placeholders rather than fabricated. Affected-version phrasing differs slightly between sources (Sansec: "2.4.4 through 2.4.9"; Adobe/THN: itemized "-2026-aug and earlier" branch list) — both describe the same version range and are not a real contradiction.

Gap: No public SHA256/MD5/SHA1 hash values for either the Rust backdoor or the PHP dropper were present in any of the five fetched snapshots, even though Sansec's page references their existence. Populate the placeholder hash rows in §10 from your own eComscan/YARA sweep or a direct (non-AI-agent) pull of Sansec's full IOC appendix before relying on hash-based blocking.

Hunt hypotheses

Attack chain

TTPs marked (inferred) are analyst mappings from the described behavior to the closest ATT&CK technique; the cited sources describe the behavior but did not themselves cite a technique ID for that specific line.

These are non-CQL checks — run directly on the Magento/Linux host or via your log-management tool — for the surfaces CQL cannot reach (raw HTTP content, plain-text PHP file writes, patch status). Commands are reproduced from Sansec's own published detection guidance (source snapshot 01) and are detection/hunt commands only — no exploit or weaponization code.

Patch status verification

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

Backdoor process, path, and persistence sweep

crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache /tmp/.chrony-*/chronyd 2>/dev/null
ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'

Template-injection / exploitation-attempt log review

grep -r 'crontab command not allowed' /var/log/
grep -ril 'x_trace_' var/report/

A hit on x_trace_ strings inside var/report/ or the "crontab command not allowed" string in system logs indicates the exploit chain was attempted or succeeded against this host — treat as a compromise indicator requiring the §14 containment runbook, not just a tuning note.

Web-shell drop sweep

find pub/media -name '*.php'

Any result is anomalous — pub/media/ is an asset-serving directory and should never legitimately contain executable PHP. Combine with a check of each hit's mtime against the store's last-known-clean deployment date. If the web server config change in Playbook Step 3 (§13) is already deployed, follow up by confirming these files also cannot execute (HTTP 403/404 on direct request) rather than only checking for their existence.

Application-layer / WAF log hunt (fills the §5 telemetry gap)

• Search reverse-proxy/CDN/WAF access logs for a spike in requests that trigger Magento's Payment Transaction Failed Reminder template render, especially from IPs with no matching legitimate checkout/order history.
• Search the same logs for GraphQL POST requests where the Store header contains PHP syntax (e.g. <?php, eval(, system() rather than a normal store-view code.
• Search for inbound requests carrying an X-Cache-Token header to any URL under pub/media/catalog/product/cache/ — legitimate asset requests never require this header.
• Cross-reference source IPs against the perishable recon watch-list in §4/§10 (88.216.72.181, 182.182.152.48, 76.31.99.207, 209.73.130.148, 77.239.124.107); a hit narrows the retrospective review window.

Custom IOAs fire in real time on the same behaviors Q1–Q7 hunt for historically. Start every rule in Detect mode; promote to Block only after a measured FP rate below 5% on a canary sensor group for 14+ days, per the standing prevention-promotion policy.

Grouped, one-click blocks for import or reference. Every atomic value here traces to a saved source snapshot in Magento-StyleSmuggler-CVE-2026-75650-Hunt-sources/.

type,value,action,severity,expiration,description,tags
ipv4,99.84.67.186,detect,critical,2027-03-08,StyleSmuggler Rust backdoor C2 (TCP/443),campaign:StyleSmuggler
ipv4,185.157.160.251,detect,critical,2027-03-08,StyleSmuggler C2 disguised as NTP (UDP/123),campaign:StyleSmuggler
ipv4,209.141.43.95,detect,high,2027-03-08,StyleSmuggler malware-hosting IP,campaign:StyleSmuggler
domain,windwsecurity.run,detect,critical,2027-03-08,StyleSmuggler Rust backdoor C2 domain,campaign:StyleSmuggler
domain,ntp.timesync.to,detect,critical,2027-03-08,StyleSmuggler C2 disguised as NTP time-sync domain,campaign:StyleSmuggler
domain,247.cdnflare.xyz,detect,high,2027-03-08,StyleSmuggler malware-hosting domain,campaign:StyleSmuggler
ipv4,88.216.72.181,enrich,low,2026-10-08,StyleSmuggler exploitation-attempt source IP (perishable),campaign:StyleSmuggler
ipv4,182.182.152.48,enrich,low,2026-10-08,StyleSmuggler exploitation-attempt source IP (perishable),campaign:StyleSmuggler
ipv4,76.31.99.207,enrich,low,2026-10-08,StyleSmuggler exploitation-attempt source IP (perishable),campaign:StyleSmuggler
ipv4,209.73.130.148,enrich,low,2026-10-08,StyleSmuggler exploitation-attempt source IP (perishable),campaign:StyleSmuggler
ipv4,77.239.124.107,enrich,low,2026-10-08,StyleSmuggler exploitation-attempt source IP (perishable),campaign:StyleSmuggler
sha256,REPLACE_WITH_SHA256,prevent,critical,2027-03-08,StyleSmuggler Rust backdoor sample (fc-cache/chronyd variant) -- hash not published in any cited source; populate from your own eComscan/YARA sweep,campaign:StyleSmuggler
sha256,REPLACE_WITH_SHA256,prevent,critical,2027-03-08,StyleSmuggler PHP web-shell dropper (485-byte) -- hash not published in any cited source; populate from your own file sweep,campaign:StyleSmuggler

# Masquerade process names (Rust backdoor)
[kworker/u:8:0]
fc-cache
chronyd
gvfsd

# Disguise / drop paths
~/.cache/fontconfig/fc-cache
/tmp/.chrony-<8hex>/chronyd
~/.local/share/.gvfsd/
/tmp/.gvfsd-*
/tmp/.kw_*
/tmp/.cache_*
/tmp/.fc-*/fc-cache
/tmp/fc-cache

# Cron persistence schedule
13,43 * * * *

# Web shell path pattern (independent secondary actor)
pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php

# Required header to activate the web shell
X-Cache-Token

Vulnerability:      CVE-2026-75650 ("StyleSmuggler")
CWE:                CWE-1336 (Improper Neutralization of Special
                    Elements Used in a Template Engine)
CVSS:               10.0 (Critical)
Payload A:          Unnamed Rust-based Linux backdoor
                    (masquerades as fc-cache / chronyd / gvfsd / kworker)
Payload B:          Unnamed PHP web-shell dropper (485 bytes),
                    independent/unrelated threat actor
Discoverer:         Sansec
Bulletin:           Adobe APSB26-146 (Priority 1)
Hotfix:             VULN-39341 (VULN-39341-composer-patches.zip,
                    repo.magento.com)

# 1. Confirm VULN-39341 is applied
vendor/bin/magento-patches -n status | grep "39341\|Status"

# 2. Confirm affected version is out of range
#    Adobe Commerce / B2B / Magento Open Source: 2.4.4-2.4.9
#    (fixed by the VULN-39341 hotfix, not a version bump)

# 3. Confirm credential rotation completed post-patch
#    - Magento encryption key (bin/magento encryption:key:regenerate)
#    - Admin passwords, integration tokens, API keys
#    - Payment gateway credentials, DB credentials, SSH keys

# 4. Confirm no PHP files exist under pub/media
find pub/media -name '*.php'

Primary Mitigations: M1051 (Update Software), M1040 (Behavior Prevention on Endpoint), M1037 (Filter Network Traffic), M1031 (Network Intrusion Prevention), M1022 (Restrict File and Directory Permissions), M1047 (Audit). Platforms in scope: the Linux/PHP application tier hosting Magento/Adobe Commerce, and the network egress path from that tier — this threat does not touch Windows/AD or a specific cloud IdP, so no controls are included for those surfaces.

Step 1 — Apply Adobe Hotfix VULN-39341

Prerequisites: Composer-based Adobe Commerce / Magento Open Source install with network access to repo.magento.com; a recent backup of composer.lock and the database. Reboot required: No (PHP-FPM / web-server reload only).

# Download and apply via the Magento Quality Patches Tool / composer patch package
composer require --dev magento/quality-patches
bin/magento community:catalog-events:hydrate 2>/dev/null # (no-op placeholder if not applicable to your edition)
# Or apply the composer patch bundle directly per Adobe's bulletin instructions:
curl -O https://repo.magento.com/patch/VULN-39341-composer-patches.zip
unzip VULN-39341-composer-patches.zip -d ./patches/
vendor/bin/magento-patches apply VULN-39341

Verify:

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

Rollback: Restore the pre-patch composer.lock backup and run composer install from it, then reload PHP-FPM/web server. Keep the backup until the patch has run in production for at least one full business cycle.

Step 2 — Rotate the Encryption Key and Protected Credentials

Prerequisites: Magento CLI (bin/magento) access; a brief maintenance window for cache flush and re-encryption of sensitive data. Reboot required: No — brief application-level downtime recommended during re-encryption.

php bin/magento encryption:key:regenerate --tag
php bin/magento cache:flush
# Then rotate out-of-band: admin passwords, integration tokens/API keys,
# payment gateway credentials, database credentials, and SSH keys reachable
# from the application host.

Verify: Confirm the store loads and checkout/admin login succeed post-rotation; confirm the old key is retired (not reused) in your secrets vault.

Rollback: none required — rotating a potentially-compromised key forward is the safe direction. Retain the prior key only in secure offline storage in case decryption of pre-rotation backups is later required; never revert to it for live use.

Step 3 — Block PHP Execution Under pub/media

Prerequisites: Admin/sudo access to the nginx or Apache configuration fronting Magento; ability to reload the web server. Reboot required: No (web-server reload only).

# nginx
location ~* ^/(pub/)?media/.*\.php$ {
    deny all;
    return 403;
}

# Apache (httpd.conf or .htaccess under pub/media)
<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

Verify:

curl -s -o /dev/null -w "%{http_code}\n" https://YOUR-STORE-DOMAIN/media/catalog/product/cache/x/y/test.php
# Expect 403 or 404, never 200

Rollback: Remove the added location/FilesMatch block and reload the web server. Legitimate (non-PHP) media serving is unaffected in either direction — this control never blocks anything the store legitimately needs.

Step 4 — Disable Dangerous PHP Functions on the Web-Facing FPM Pool

Prerequisites: Ability to separate the web-facing PHP-FPM pool from any CLI/cron pool that needs shell-out functions (indexers, n98-magerun); test in staging first. Reboot required: No (PHP-FPM pool reload).

# In the web pool's .conf (e.g. /etc/php/8.x/fpm/pool.d/www.conf)
php_admin_value[disable_functions] = exec,shell_exec,system,passthru,proc_open,popen,pcntl_exec

Verify:

php-fpm8.x -t && systemctl reload php8.x-fpm
# From a web-triggered diagnostic (never expose this publicly):
php -r "var_dump(function_exists('exec'));"   # expect bool(false) for the web pool

Rollback: Remove the disable_functions line from the pool config (or restore the prior pool .conf backup) and reload PHP-FPM.

Step 5 — Egress-Filter the Application Tier

Prerequisites: Host or network firewall (iptables/nftables/security-group) fronting the Magento app servers; a documented allow-list of legitimate outbound NTP servers and required destinations. Reboot required: No.

# nftables example
nft add rule inet filter output udp dport 123 ip daddr != { 192.0.2.10, 192.0.2.11 } drop
nft add rule inet filter output ip daddr { 99.84.67.186, 185.157.160.251, 209.141.43.95 } drop

Verify:

# From the app host, confirm a non-allow-listed UDP/123 destination is dropped
nc -u -w2 203.0.113.5 123 <<< "test" ; echo "exit: $?"
# Check firewall counters/logs for the added rules

Rollback: Remove/disable the added firewall rules by handle/ID (nft delete rule ...) to restore the prior egress posture.

Deploying via your RMM

The snippets above are raw shell/config. To wrap them for fleet deployment (admin check, error handling, custom-field writeback for compliance tracking), hand them to your RMM deployment tooling and ask for a deployable package.

Any internet-facing store reachable between 2026-09-04 and hotfix application is in scope for this runbook even if it currently shows no active indicators — the exploit predates public detection content, so absence of an alert does not establish absence of compromise.

Coverage Summary: 6 of 10 identified techniques have at least partial detection coverage via CQL/IOA/IOC; 3 remain GAPs.

Priority Gaps: T1190 (the initial exploitation request itself) and T1595 (GraphQL header-based recon) are invisible to Falcon endpoint telemetry — Falcon does not inspect raw HTTP request content. Close these via WAF/CDN log ingestion and the §7 native application-log hunts, not CQL. T1552 (credential exposure) is not directly observable after the fact via EDR and must be handled as a blanket rotation requirement (§13 Step 2, §14 Recover) for any store confirmed or suspected exposed during the zero-day window.

Validation gates: see §11 for the telemetry-readiness, benign-baseline, positive-test, and promotion gates each query must pass before being relied on operationally or promoted to Prevent/Block.

Generated 2026-09-08 by HuntPack. All fetched source text was reviewed for injected/adversarial instructions before use; none were found. This pack is defensive-only: detection logic and hardening guidance, no offensive or exploit code.