Skip to content
HACKTECH
Exploited vulnerabilitiesReported Published 7 sources

Magento StyleSmuggler zero-day exploited before patch; BlockStrap bypass followed

Sansec reported on 5 September 2026 that attackers had been exploiting StyleSmuggler (CVE-2026-75650), an unauthenticated code injection flaw in the Magento and Adobe Commerce template system, since 4 September to install a Rust-based Linux backdoor, including on stores running the July and August 2026 patches. Adobe released hotfix VULN-39341 under bulletin APSB26-146 on 7 September, and the flaw is rated CVSS 10.0. On 13 October Adobe fixed a related CVSS 10.0 template injection, CVE-2026-103849, in APSB26-153; Sansec, which calls it BlockStrap and published its analysis on 15 October, says the September hotfix alone does not stop it.

  • Magento
  • Adobe Commerce
  • zero-days
  • CVE-2026-75650
  • CVE-2026-103849
  • backdoors
  • e-commerce

What the sources report

  • Affected, per Adobe's knowledge base notice and BleepingComputer: Adobe Commerce 2.4.4 to 2.4.9, Adobe Commerce B2B 1.3.3 to 1.5.3 and Magento Open Source 2.4.6 to 2.4.9, including the August 2026 releases and earlier versions in each branch.
  • The two-stage chain plants PHP code, for example by generating a failure report, then has Magento execute it while rendering a 'Payment Transaction Failed Reminder' email; nobody needs to open the email and no user interaction is required (SecurityWeek, Sansec).
  • The Rust backdoor ran as '[kworker/u:8:0]', later as 'fc-cache' copied to ~/.cache/fontconfig/fc-cache, persisted through a cron job and disguised command-and-control traffic as NTP on UDP port 123 (BleepingComputer, Sansec).
  • A second actor with unrelated tooling sent a reconnaissance probe that checked whether pub/media was writable and reported back through an oast.site subdomain, and used a 485-byte PHP dropper that writes a web shell into the product image cache (Sansec; BleepingComputer).
  • BleepingComputer reported on 8 September that the hotfix had only been tested against the August 2026 releases; Adobe's notice, last updated 21 September, lists hotfix packages for earlier 2.4.4 to 2.4.9 patch levels and tells merchants to rotate the encryption key, admin passwords, integration tokens, OAuth client secrets, payment gateway, database and SSH credentials.
  • For BlockStrap, Adobe assigned priority 2 (a 30-day window); Sansec reproduced four code-execution routes within 24 hours, had not seen exploitation at publication, and says both fixes are required.

What it means for your organisation

Stores on the latest available patches were compromised because the attack began before any fix existed, so patch level alone could not show whether a store was safe. Adobe and Sansec both said remediation meant checking for compromise and rotating the encryption key and the credentials it protected, not only installing the hotfix. Sansec says the September hotfix alone does not stop BlockStrap, for which it reproduced four code-execution routes, so a store that applied only the first emergency fix stayed exposed until it installed the 13 October fix; retest after an emergency patch instead of treating it as the end of the incident.

What we check

  • Verify both the VULN-39341 hotfix and the APSB26-153 fix are installed, using Sansec's published check that the BlockStrap fix is present in Magento's template filter.
  • Look for processes named [kworker/u:8:0], fc-cache or chronyd, cron entries pointing to ~/.cache/fontconfig/fc-cache, and outbound UDP 123 traffic to hosts such as ntp.timesysnc.net or ntp.timesync.to.
  • Review mail logs for unexplained bursts of 'Payment Transaction Failed Reminder' emails since late August 2026.
  • Search pub/media and other writable directories for unexpected PHP files.
  • If compromise cannot be ruled out, rotate the encryption key, admin passwords, integration and OAuth tokens, and payment gateway, database and SSH credentials at their source.
  • A review of a public website's TLS and security headers, third-party scripts, CMS and plugin versions, forms, authentication and hosting configuration. Every check is marked pass, fail or not applicable with the evidence attached, so the result doubles as a compliance artefact.

    Duration: 3 to 6 working days

  • Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Authenticated, role-aware testing of your application and its API surface, with an account for every role. We chain small findings into the access they lead to, such as a sequential invoice ID and a missing tenant check that together let one customer read another's invoices.

    Duration: 5 to 10 working days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.