Adobe released an emergency security update on September 7 for a critical Adobe Commerce and Magento Open Source zero-day that attackers are already using to break into online stores. The flaw, tracked as CVE-2026-75650 and nicknamed StyleSmuggler by Sansec, can let an unauthenticated attacker execute arbitrary code on affected installations.
The issue matters because Magento and Adobe Commerce stores often sit directly in payment, account, inventory, and order-management workflows. A successful compromise is not just a website-defacement risk. It can give attackers a foothold near customer data, admin accounts, payment integrations, shipping tools, ERP connections, and the credentials merchants use to run the store.
Adobe’s APSB26-146 bulletin gives the vulnerability its highest priority rating and says Adobe is aware of exploitation in the wild. The affected list covers Adobe Commerce versions 2.4.4 through 2.4.9 in the August 2026 release line and earlier, Adobe Commerce B2B 1.3.3 through 1.5.3 in the August 2026 line and earlier, and Magento Open Source 2.4.6 through 2.4.9 in the August 2026 line and earlier.
What Adobe Released
Adobe is distributing the fix as a hotfix rather than a full platform release. Its Commerce knowledge-base article, last updated September 8, lists version-specific VULN-39341 patch downloads for current and earlier Adobe Commerce and Magento Open Source builds.
For many recent builds, including 2.4.9-2026-aug, 2.4.8-2026-aug, 2.4.7-2026-aug, 2.4.6-2026-aug, 2.4.5-2026-aug, 2.4.4-2026-aug and several July or patch-release versions, Adobe points merchants to VULN-39341-composer-patches.zip. Older supported branches have separate patch packages. Admins should match the patch to the installed Commerce or Magento version instead of assuming one archive covers every deployment.
Adobe also recommends confirming that the hotfix has actually applied. For Adobe Commerce on Cloud, that means installing the Quality Patches Tool when needed and checking for the VULN-39341 patch status with vendor/bin/magento-patches -n status | grep "39341\|Status". The expected result is an applied status for the relevant hotfix.
How StyleSmuggler Is Being Used
Sansec, which specializes in e-commerce threat research, reported that attacks began on September 4, three days before Adobe’s hotfix was published. The company says StyleSmuggler abuses Magento’s template system through styles properties, first injecting PHP code and then getting Magento to execute it during failed-payment email handling.
That path is important for defenders because a failed payment email may look like ordinary store behavior. Sansec notes that unexpected bursts of Magento’s standard failed-payment reminders should be investigated, but the absence of a suspicious email in an inbox is not enough to clear a store. The code can run while Magento renders the message, even if delivery itself fails.
Sansec says it reproduced the unauthenticated chain on clean Magento Open Source 2.4.7, 2.4.8, and 2.4.9 installations. It also observed attacks against a store running 2.4.6-p15 with July and August 2026 patches applied, which is why merchants should treat current patch-level confidence carefully until VULN-39341 is in place.
Successful compromises have deployed Linux backdoors. Sansec described variants disguised as processes such as [kworker/u:8:0], fc-cache, and chronyd. One variant hides command-and-control traffic inside NTP-shaped UDP packets, making it easy to miss in environments that broadly trust time-sync traffic. Sansec also reported a separate PHP dropper writing a web shell under the product media cache on some affected stores.
Patch First, Then Assume Patch Is Not Cleanup
The immediate step is to apply Adobe’s hotfix for the exact deployed version. But patching only closes the route in. It does not remove an implant already running on the host, and it does not invalidate secrets that may have been read before the patch landed.
Merchants should inspect hosts for suspicious background processes, cron entries, temporary directories, and PHP files under media paths. Sansec’s latest indicators include process names, file paths, domains, IP addresses, hashes, and request patterns; defenders should use the live Sansec advisory rather than relying on a static copy of indicators because the campaign has changed quickly.
At minimum, administrators should look for unfamiliar cron jobs, check process listings for names that do not match expected binaries and paths, review web server and Magento logs for odd failed-payment, GraphQL, and media-cache activity, and search for PHP files where product images and generated media should live. Any suspicious finding should be treated as a possible compromise, not as a patching ticket.
Credential Rotation Is Part of the Fix
Adobe’s remediation guidance is unusually direct about credential rotation. After applying the hotfix, merchants should rotate the Commerce encryption key and also rotate credentials that may have been encrypted or exposed through it. That includes admin passwords, REST, SOAP, and GraphQL integration tokens, OAuth client secrets, payment gateway API credentials, database credentials, SSH and deployment keys, cron or service-account credentials, and third-party extension API keys.
The distinction matters. Rotating the Magento encryption key alone does not revoke a payment processor key, an OAuth client secret, a shipping API token, or a database password that an attacker may already have copied. Those credentials have to be regenerated at the original service and then updated in Commerce.
Adobe recommends a sequence that includes enabling maintenance mode, disabling cron execution, rotating keys and credentials, flushing the cache, re-enabling cron, disabling maintenance mode, and redeploying on Commerce Cloud when database credentials change. Stores with high transaction volume should coordinate that work carefully, but delaying rotation after suspected exposure leaves the store dependent on secrets that may already be outside the environment.
Who Should Move Now
Any organization running Adobe Commerce, Adobe Commerce B2B, or Magento Open Source in the affected 2.4.x branches should treat this as an urgent maintenance window, especially if the store is internet-facing and handles live checkout traffic. Agencies and managed hosting providers should also audit client fleets, because the same exploit path can hit many similar deployments before individual merchants realize they are exposed.
The clearest short checklist is: identify the exact Commerce or Magento version, apply the matching VULN-39341 hotfix, confirm the patch status, review Sansec’s current indicators, scan for backdoors and unexpected PHP files, rotate the encryption key and connected credentials, then monitor outbound traffic and logs for follow-on activity.
For store owners, the practical message is simpler: ask whoever manages the Magento or Adobe Commerce environment whether CVE-2026-75650 has been patched, whether the patch was verified, whether the host was checked for compromise, and whether payment, admin, integration, and deployment credentials were rotated after the fix.
Sources: Adobe APSB26-146 security bulletin, Adobe Commerce hotfix guidance, Sansec StyleSmuggler research, and SecurityWeek coverage of Adobe’s September security updates.
