Zero-day in Adobe Commerce and Magento: emergency patch released
Adobe published an emergency patch on 7 September 2026 for CVE-2026-75650, a flaw that lets an unauthenticated attacker run code on Magento based installations. According to Sansec, attacks were already running days before the fix, and compromised servers received a backdoor written in Rust.
What happened?
Adobe released security bulletin APSB26-146 on 7 September 2026, shipping the VULN-39341 emergency patch for CVE-2026-75650, a vulnerability affecting Adobe Commerce and Magento Open Source installations. In its own knowledge base announcement the company confirmed that the flaw has been exploited in the wild against Adobe Commerce merchants.
The ecommerce security firm Sansec found and reported the issue. Sansec named the vulnerability StyleSmuggler and dated the start of exploitation to 4 September 2026 at 22.20 UTC. BleepingComputer covered the fix on 8 September 2026 under the headline 'Adobe fixes critical Magento zero-day exploited to backdoor servers', while SecurityWeek documented how the attack chain works.
The details
Per Adobe's list, the flaw affects Adobe Commerce and Magento Open Source releases from 2.4.4 through 2.4.9, plus Adobe Commerce B2B from 1.3.3 through 1.5.3, meaning the August 2026 releases and everything before them. Adobe describes the issue as a vulnerability that could allow an unauthenticated attacker to execute arbitrary code on an affected installation. Sansec reproduced it on Magento Open Source 2.4.7, 2.4.8 and 2.4.9 and reported that every release in the 2.4.4 to 2.4.9 range is affected. Sansec scores it at CVSS 10.0, while Adobe's knowledge base page carries no CVSS figure at all. The fix is distributed as VULN-39341 in the file VULN-39341-composer-patches.zip, flagged by Adobe at Priority 1; Sansec records the patch as landing on 7 September 2026 at 20.20 UTC.
The mechanics are documented as well. According to SecurityWeek, attackers deliberately trigger Magento's standard Payment Transaction Failed Reminder email to execute PHP code. Compromised servers receive a backdoor written in Rust that hides behind the process names [kworker/u:8:0], fc-cache and chronyd, with Sansec observing versions 2.1.4 and 2.1.5. Command and control traffic goes to 99.84.67.186, and later variants dress that traffic up as NTP time synchronisation, sending 48 byte packets over UDP port 123 every 60 seconds. SecurityWeek reports that the backdoor exfiltrates the agent identifier, hostname, username, memory and disk usage, operating system version, uptime and root access status. SecurityWeek also notes a second backdoor variant surfacing on 6 September, and BleepingComputer reports that a separate 485 byte PHP web shell was found afterwards. Beyond the patch, Adobe requires rotating the encryption key along with every server, API and integration credential protected by it, and its knowledge base page walks through a 15 step procedure that includes enabling maintenance mode and flushing the cache at the end.
Why it matters
This case shows why patch management on commerce infrastructure has to run on events rather than on a calendar. Three points stand out. First, exploitation preceded the fix: on Sansec's timeline the attacks were live on the evening of 4 September while the patch arrived on 7 September. Applying the patch is therefore necessary but not sufficient, because a backdoor planted during that window stays in place afterwards. Second, Adobe's own cleanup instruction confirms this: asking merchants to rotate the encryption key and the server, API and integration credentials protected by it means the incident has to be treated as a leaked secrets problem. Third, a backdoor that masquerades as system processes and wraps its traffic in NTP can lead ordinary server monitoring to classify the activity as normal. That assessment is ours.
In short, for a company running a store on Magento based infrastructure the question is not only whether the version is current, but what happened on that server over the past few days. Where payment gateway and integration keys are involved, the blast radius does not stop at the store boundary.
What it means for businesses in Türkiye
The sources carry no data specific to Türkiye, no count of affected local stores and no local advisory; the steps below follow directly from the scope of the vulnerability itself. If you run a store on Magento or Adobe Commerce, the order of work is clear: verify your version, apply the VULN-39341 patch if you sit anywhere between 2.4.4 and 2.4.9, then review server logs, the process list and outbound connections dated after 4 September 2026. The process names published by Sansec and the regular packet pattern on UDP 123 give you concrete things to search for.
Once the patch is in, the key and credential rotation procedure Adobe describes should not be skipped, especially for payment gateway and third party service keys, because those credentials remain valid in systems outside the store. For stores whose maintenance sits with an agency or a hosting provider, confirming in writing who applies the patch and who reviews the logs keeps responsibility from falling through the gap. That reading is ours.
The UNALSOFT take
Incidents like this do not show that packaged commerce platforms are a bad choice; they show that choosing a platform comes with a maintenance obligation. When a flaw lands in widely deployed infrastructure, the attacker targets the whole installed base rather than one store, and never having touched your own code does not put you outside the scope. On the UNALSOFT side, version tracking, logging and key management are part of the job when we build an ecommerce panel. The approach is described on our ecommerce panel page.
Is your store patched, and is your server clean?
If you want a second pair of eyes on version tracking, logging and key management for your commerce stack, talk to the UNALSOFT team.