- What: Adobe patched CVE-2026-75650, a CVSS 10.0 unauthenticated remote code execution flaw in Adobe Commerce and Magento Open Source that Sansec codenamed StyleSmuggler and observed being exploited as a zero-day from September 4, 2026.
- Impact: Attackers get code execution as the web server with no credentials, and observed payloads include a Rust based Linux backdoor that beacons to an external server plus a PHP dropper that writes an arbitrary-PHP web shell on the checkout host.
- Fix / mitigation: Apply Adobe's VULN-39341 hotfix from repo.magento.com and rotate your encryption keys, which Adobe lists as a required second step, not an optional one.
- Who's at risk: Every Adobe Commerce 2.4.4 through 2.4.9, Adobe Commerce B2B 1.3.3 through 1.5.3, and Magento Open Source 2.4.4 through 2.4.9 install running the 2026-aug builds or earlier.
Adobe released an out of band patch on September 8, 2026 for CVE-2026-75650, a CVSS 10.0 unauthenticated remote code execution flaw in Adobe Commerce and Magento Open Source. Attackers got there first. Sansec, which codenamed the bug StyleSmuggler, dates zero-day exploitation to September 4, giving attackers a four day head start on every merchant running the platform. Payloads seen in that window include a Rust based Linux backdoor and a PHP web shell.
Adobe's own wording is unambiguous: it is "aware that CVE-2026-75650 has been exploited in the wild targeting Adobe Commerce merchants." If you run a storefront on this platform, treat the patch as urgent and the cleanup as mandatory.
Inside the exploit chain
The flaw lives in Magento's template system. An attacker injects PHP through the template path used to generate the "Payment Transaction Failed Reminder" email. When the platform renders that template, the injected code executes. No credentials, no admin session, no victim interaction, no phishing step. A single request to an internet facing storefront is the whole delivery mechanism.
Disrex, the Dutch e-commerce development platform that investigated one of the compromises, described it plainly: "StyleSmuggler turns Magento's own template-processing and dependency-injection code into an unauthenticated remote-code-execution chain." That is the worst possible shape for an e-commerce bug. The vulnerable code path is core platform functionality, not a third party extension you can rip out, and it sits on the same host that processes card data.
Adobe's advisory tells merchants to apply the VULN-39341 patch and rotate encryption keys. That second instruction is vendor shorthand for assume the attacker read your secrets. Magento's encryption key protects stored payment configuration, integration tokens and API credentials. A patched store with the original keys still hands an attacker everything they collected during the zero-day window.
Fifty minutes from disclosure to compromise
The number worth carrying into your change advisory board meeting is 50. The first confirmed StyleSmuggler exploitation was reported on September 4, 2026 at 10:20 p.m. UTC. According to Disrex, a Magento server it manages was compromised 50 minutes later. That is not a targeted operation against a specific brand. That is automation sweeping a fingerprintable platform, and Magento installs are trivial to fingerprint from static asset paths and response headers.
Fifty minutes is shorter than most emergency patch approval processes. It is shorter than the average on call escalation. Plan your response on the assumption that any internet facing store unpatched between September 4 and today was reachable by someone running this exploit at scale.
What lands on a compromised store
Two distinct payloads have been reported so far, which suggests more than one actor working the same bug:
- A Rust based Linux backdoor that connects out to an external server and waits for instructions. Rust compiled ELF payloads sidestep most detection content written for PHP malware on this platform, and a generic implant with remote tasking means the operator can decide the endgame later.
- A PHP dropper that writes a web shell capable of executing arbitrary PHP. This is the cheap, durable option: it survives your patch, it lives in a directory the web server is already allowed to write, and it blends into a codebase that contains tens of thousands of legitimate PHP files.
Neither payload is described in the source reporting as a payment card skimmer. Do not read that as reassurance. A web shell on a checkout server is one file write away from becoming one, and the operator behind a remote tasking backdoor has not shown you their objective yet.
Affected versions
The flaw affects the 2026-aug builds and everything earlier across three product lines:
- Adobe Commerce 2.4.9, 2.4.8, 2.4.7, 2.4.6, 2.4.5 and 2.4.4 (2026-aug and earlier)
- Adobe Commerce B2B 1.5.3, 1.5.2, 1.4.2, 1.3.4 and 1.3.3 (2026-aug and earlier)
- Magento Open Source 2.4.9, 2.4.8, 2.4.7 and 2.4.6 (2026-aug and earlier)
The fix ships as a hotfix bundle, VULN-39341, downloadable as a composer patches archive from repo.magento.com. Note that Magento Open Source users are getting the same patch on the same day, so there is no paid tier advantage to wait for.
Current exploitation volume, and why it will climb
Telemetry from Previdian shows 12 exploitation attempts against its honeypots since September 7, 2026, from two unique IP addresses geolocated to China and Romania. Founder and CEO Ryan Dewhurst reports all of them failed. Twelve attempts from two addresses is reconnaissance scale, not campaign scale.
That is a snapshot of the pre-patch period, and it is the most favorable number you will see. A published hotfix is a published diff. Once commodity operators finish reversing VULN-39341, the exploit stops being the property of whoever found it first and starts appearing in mass scanning kits. The gap between a patch landing and unsophisticated exploitation following is usually measured in days.
Bottom line
Apply VULN-39341, rotate the encryption key, then hunt. Order matters, and the third step is the one teams skip. If your store was internet facing and unpatched at any point after September 4, 2026, a clean version string tells you nothing about whether a web shell or a Rust implant is already resident. Look at file modification times under your writable web directories, look at what php-fpm has been spawning, and look at outbound connections from a host that should only ever talk to your payment gateway and your CDN.
php bin/magento --version
composer show magento/product-community-edition | head -5
find ./pub ./generated -name '*.php' -newermt '2026-09-04' -lsFix It Yourself
Everything above is what happened. This is what to run. The check commands change nothing.
Check whether you are exposed
Print the installed Magento or Adobe Commerce version to compare against the affected 2026-aug builds
php bin/magento --versionShow the exact installed package version from composer, which is more reliable than the CLI banner on customized builds
composer show 'magento/product-*-edition' 2>/dev/null | grep -E 'name|versions'List PHP files under the web writable directories modified since exploitation began on September 4, 2026, which is where the PHP dropper writes its web shell
find ./pub ./generated ./var -type f -name '*.php' -newermt '2026-09-04 00:00:00' -printf '%T+ %s %p\n' 2>/dev/null | sortClose it
Take the storefront offline first if you have any indication of compromise, so cleanup does not race live exploitation
php bin/magento maintenance:enableDownload Adobe's VULN-39341 hotfix bundle and verify the archive before applying it per Adobe's instructions for your version
curl -fSLO https://repo.magento.com/patch/VULN-39341-composer-patches.zip && unzip -l VULN-39341-composer-patches.zipRotate the encryption key, which Adobe lists as required alongside the patch (this can also be done in Admin under System, Manage Encryption Key)
php bin/magento encryption:key:changePrompts for the agent you already run
Paste this before patching, to find out whether this store is exposed and whether anything already landed
Paste this when you are ready to remediate and want the steps staged rather than executed blind
What to alert on
The single highest value observable is process lineage under the web server. A healthy Magento host effectively never has php-fpm spawn an interactive shell, so alert on any auditd EXECVE record whose ppid resolves to php-fpm, php or httpd and whose comm is sh, bash, dash, curl, wget, python3 or an unsigned ELF path in /tmp, /var/tmp or under pub/; in EDR terms that is parent_process_name php-fpm with child_process_name in that set, and it fires on both the PHP dropper stage and the Rust backdoor launch. Pair it with two supporting signals. First, file integrity monitoring on writes to *.php under pub/, pub/media/, pub/static/ and generated/ outside a known deploy window, which is where the dropper stages its web shell; on a stock install those paths change only during setup:static-content:deploy. Second, egress: in Zeek conn.log or your firewall flow logs, alert on any outbound TCP session originating from a storefront host to a destination outside your payment gateway, package repository and CDN allowlist, since the reported Rust implant connects to an external server and idles waiting for instructions, producing a long lived, low byte count connection that stands out against normal storefront egress. For pre-exploitation visibility, keep the nginx or Apache access log field for request URI and status under review for POST traffic to checkout and order email endpoints immediately preceding any of the above process events, which gives you the correlating request that started the chain.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us