A flaw that ignored patch levels
For three days this month, the security patches merchants had already installed didn't matter. A previously unknown flaw in Magento Open Source and Adobe Commerce, nicknamed StyleSmuggler, let an attacker run code on a store's server without logging in at all, and the first confirmed victim was running a build with July and August 2026 security patches fully applied. Dutch e-commerce security firm Sansec, which found the flaw, later assigned it CVE-2026-75650 with the maximum CVSS severity score of 10.0.
The bug sat in core Magento and Adobe Commerce code, not a third-party extension, so it reached a wide swath of the platform's install base: Magento Open Source and Adobe Commerce versions 2.4.4 through the newly released 2.4.9, plus Adobe Commerce B2B 1.3.3 through 1.5.3.
How the attack worked
StyleSmuggler ran in two stages. First, an attacker sent a manipulated "styles" property through Magento's GraphQL layer that bypassed input sanitization, letting them plant PHP code inside a file Magento itself generates during normal operation, such as a payment failure report. On its own, that planted code just sat there.
The second stage triggered it. Magento's built-in "Payment Transaction Failed Reminder" email pulled in the poisoned file when it rendered, and the store executed the attacker's code at that moment. The chain also touched Magento's dependency-injection compiler code, using a log-poisoning technique to get the malicious file into a path the system would trust.
Once in, the payload installed a compact, statically linked Rust binary, about 1.9 megabytes, built for both x86-64 and ARM64 servers. It disguised itself as a routine background process with names like [kworker/u:8:0], fc-cache, or chronyd, hid in paths such as /tmp/.fc-<8hex>/fc-cache and ~/.cache/fontconfig/fc-cache, and persisted through cron jobs. It phoned home over UDP traffic dressed up as ordinary NTP time-sync requests, which is the kind of traffic most firewalls wave through without a second look.
Timeline
- September 4, 22:20 UTC: Sansec confirms the first exploitation attempts.
- September 5: Sansec publishes an early advisory and ships blocking rules, warning that stores are being compromised as it writes. "Sansec is publishing early because stores are being compromised right now," the firm said.
- September 6: Adobe's public security bulletin remains unchanged, with no patch, workaround, or CVE identifier yet issued.
- September 7, 20:20 UTC: Adobe ships an emergency composer patch, VULN-39341, under advisory APSB26-146, rated priority 1, and CVE-2026-75650 is formally assigned.
That is roughly three days between confirmed in-the-wild attacks and an official fix, during which store owners had no vendor guidance beyond community advisories.
What merchants had to do in the gap
Because there was no patch for the first two days, responders leaned on stopgaps instead. Sansec recommended temporarily disabling GraphQL entirely on stores that don't run a headless front end, since that's the interface the exploit rides in on. Community Magento specialists, including consultancies ProxiBlue and Graycore, pushed out web application firewall rules blocking template-injection patterns and recommended locking down admin panels behind IP allowlists or a VPN in the meantime.
Rick Bouma, co-founder of Magento hosting firm Disrex Group, summed up why the usual advice fell short here: "Patch status was irrelevant here, which is the part merchants most need to hear." A fully updated store was exploited just as easily as a neglected one, because the flaw lived in code every current version shared.
What it means for store owners now
Adobe's fix is a composer patch rather than a full point release, so applying it takes a manual step beyond a routine update, and Adobe is telling merchants to rotate encryption keys and related credentials afterward, not just install the patch. Given that fully patched stores were compromised before the fix existed, any Magento or Adobe Commerce operator should also check now, not just patch now: look for the disguised processes and cron entries described above, review admin user lists for accounts nobody recognizes, and watch outbound traffic for UDP flows to unfamiliar hosts. A store that shows any of those signs should be treated as compromised even if the patch has since been applied, since the patch closes the door but doesn't remove anyone already inside.
Sources
This article draws on reporting and technical advisories from Sansec, The Hacker News, CyberSecurityNews, and Security Arsenal, listed below.
