Adobe has released an emergency security fix for CVE-2026-75650, the maximum-severity Magento and Adobe Commerce zero-day known as StyleSmuggler, after confirming that attackers are exploiting the vulnerability in the wild. The flaw can allow an unauthenticated remote attacker to execute arbitrary code on an affected installation, making it particularly dangerous for internet-facing e-commerce systems. Adobe’s APSB26-146 advisory applies to 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.6 through 2.4.9, including the August 2026 releases and earlier builds in those branches. Adobe has assigned the highest update priority and is urging administrators to install the VULN-39341 hotfix immediately. 

The vulnerability was first observed under active exploitation on September 4, when Sansec detected attackers abusing Magento’s template-processing functionality to achieve PHP code execution and plant a persistent Linux backdoor. The initial campaign disguised its command-and-control infrastructure as what appeared to be an ordinary NTP server and left behind indicators including suspicious processes masquerading as `kworker` or `fc-cache`, cron-based persistence, temporary files and unusual “Payment Transaction Failed Reminder” emails. Adobe’s confirmation of in-the-wild exploitation now removes any ambiguity around the urgency. This is not a theoretical flaw waiting for proof-of-concept development. Real attackers have already used it to obtain execution on production commerce servers.

The fact that StyleSmuggler affects fully patched Magento and Adobe Commerce installations is what made the original disclosure especially concerning. Sansec reproduced the exploit against clean, current installations, meaning organizations that had applied every available vendor security update could still be compromised before Adobe released the emergency fix. This is an important reminder that patch management removes known vulnerabilities, but it does not create immunity against unknown ones. Security architecture still needs monitoring, segmentation, WAF protections, least privilege and compromise-detection capabilities for exactly this reason.

The emergency patch changes the defender’s immediate task, but it does not simplify it. Adobe explicitly recommends more than simply installing the hotfix. Administrators are advised to place the site in maintenance mode, suspend cron jobs, apply the fix and rotate secrets including administrator passwords, GraphQL integration tokens, OAuth client secrets, payment gateway API credentials, database credentials, SSH keys and API keys. Only after rotation should caches be flushed, cron execution restored and the site returned to normal operation. This guidance effectively acknowledges the most important incident-response reality: if arbitrary code execution may already have occurred, every secret accessible to the application needs to be considered potentially exposed.

That broad secret rotation is especially important in an e-commerce environment. Magento does not operate in isolation. It frequently connects to payment gateways, ERP systems, shipping platforms, CRM applications, databases and third-party integrations. A server compromise can therefore expose far more than the credentials required to administer the storefront itself. Attackers who steal API keys or database passwords may preserve access even after the original Magento vulnerability is patched. This is why post-exploitation cleanup needs to address trust relationships around the application, not merely the vulnerable PHP code.

Sansec’s latest findings reinforce that concern. After the original backdoor campaign, researchers observed a second, apparently unrelated attacker exploiting the same CVE to deploy a very small PHP web shell of roughly 485 bytes. That shell collects basic server information, checks whether `pub/media` is writable and exfiltrates the results through an `oast.site` subdomain associated with Interactsh-style out-of-band interaction. The appearance of multiple independent attack sets in such a short period is exactly what defenders should expect once a zero-day becomes public: exploit knowledge spreads quickly, infrastructure changes and attacker diversity increases.

This matters because defenders cannot build their response around one malware family. The first campaign may leave `kworker`-like processes and cron entries. The next may deploy a PHP web shell. A third may simply create an administrator account or insert malicious code into the database. Detection therefore needs to focus on the underlying behavior of compromise rather than treating the initial indicators as an exhaustive checklist.

For Magento administrators, server-side integrity monitoring should become an immediate priority. Teams should review recently modified PHP files, especially under web-writable directories, inspect cron jobs and scheduled tasks, compare application files against known-good versions and examine `pub/media` for executable or unexpected content. Web servers should generally not execute PHP from upload or media directories unless explicitly required. Restricting execution in those locations can significantly reduce the usefulness of a planted web shell.

Database integrity also deserves attention. Magento attackers have a history of storing malicious JavaScript or persistence inside CMS blocks, configuration values and database-backed templates. A filesystem scan can therefore report everything as clean while the storefront continues serving attacker-controlled code from the database. Security teams should inspect unusual CMS changes, administrator accounts, configuration modifications and payment-related templates created or modified during the exposure window.

Payment security is the most obvious downstream risk. A compromised Magento application can potentially be modified to inject skimming code into checkout pages and steal payment information directly from customers. This is more dangerous than an attacker simply downloading existing database records because it turns the legitimate store into an ongoing collection point for future transactions. Customers continue shopping normally while the attacker passively collects data in the background.

This is why successful compromise of an e-commerce platform should trigger a review of page integrity and client-side JavaScript. Organizations should compare checkout templates against known-good versions, inspect third-party scripts and Content Security Policy violations, and monitor unexpected outbound browser connections from payment pages. A web shell on the server is damaging, but a hidden skimmer operating for weeks can create a much larger customer-impact event.

The emergency fix also highlights an operational challenge. Adobe says the hotfix has been tested against the August 2026 releases of affected product branches, while compatibility with other builds has not been fully confirmed. Organizations on heavily customized or older Magento environments therefore face the usual unpleasant choice between rapid patching and compatibility risk. In this case, however, the vulnerability is already being exploited. That should move the balance firmly toward emergency validation and deployment rather than waiting for a convenient maintenance window.

Administrators should also verify that the patch is actually active after installation. It is not enough for a deployment pipeline or change ticket to report success. The running application version and hotfix state should be validated directly, and external testing should confirm that the vulnerable behavior is no longer reachable. Security teams should retain evidence of the pre-patch state so they can establish which systems were exposed during the exploitation period.

Organizations should also review historical logs beginning before September 4 where possible. Sansec only identified exploitation beginning on that date, but that does not guarantee earlier activity did not occur. Web-server logs should be searched for suspicious GraphQL requests, unusual template-related parameters, spikes in failed-payment email generation and unexpected requests leading into PHP execution. Egress logs should be reviewed for connections to unusual external infrastructure, especially from the PHP or web-server process.

The fact that the first backdoor disguised its C2 as an NTP server is a useful reminder that port and protocol labels do not establish trust. An outbound connection to something that looks like a time service may still carry malicious traffic. Servers should not be allowed arbitrary outbound connectivity simply because a destination uses a familiar port. Egress controls should restrict communication to approved payment services, update servers and external APIs whenever operationally possible.

Magento and Adobe Commerce merchants should also review whether GraphQL is exposed and whether every enabled API is actually required. Sansec had previously recommended disabling GraphQL as a temporary mitigation before Adobe’s fix became available because the exploit chain relied on that interface. Now that a patch exists, disabling functionality is no longer the primary remediation, but reducing unnecessary API exposure remains good security hygiene. Every endpoint that does not need to be public is one less attack surface to defend.

The StyleSmuggler incident also demonstrates the value of virtual patching. Sansec was able to deploy mitigation rules while Adobe was still preparing the official fix. Organizations with application-aware WAF or IPS capabilities can use similar protections to buy time during zero-day events. These controls are not substitutes for vendor patches, but they can reduce exploitability during the dangerous gap between vulnerability discovery and official remediation.

The broader vulnerability-management lesson is that zero-days require a different workflow from ordinary CVEs. In a conventional vulnerability, the organization often learns about the flaw at roughly the same time as the patch. With StyleSmuggler, exploitation was already occurring while administrators had no vendor fix to install. Once Adobe released the hotfix, the response had to transition immediately from mitigation to patching and forensic validation.

That transition matters because organizations sometimes treat patch release as the end of the incident. For an actively exploited RCE, it is often only the midpoint. The sequence should be: identify exposure, preserve evidence, apply mitigation, patch, rotate secrets, hunt for persistence and verify that the system is clean. Skipping the compromise-hunting steps risks leaving behind the attacker while proudly reporting that the vulnerability scanner now shows green. 

CVE-2026-75650 ultimately demonstrates why active exploitation changes the meaning of patch management. Before exploitation, patching prevents compromise. After exploitation, patching only closes the original door. It does not tell you who already walked through it, what they touched or whether they left another door open. For Magento and Adobe Commerce administrators, that is now the real security problem.

Adobe has released an emergency fix for CVE-2026-75650, an actively exploited max-severity zero-day vulnerability dubbed StyleSmuggler, that impacts multiple versions of Magento and Adobe Commerce. [...]

Source: Adobe fixes critical Magento zero-day exploited to backdoor servers via Bleeping Computer — published 08 Sep 2026.